Remote debugging of microservice via SSH under VPN in 4 turns

There is a situation when you need to otdebazhit complex case on a remote machine, but access to the server is only for VPN with restrictions on open ports. In this article I want to share with my colleagues a small “survey” on the subject of remote debugging via SSH under a VPN, in order to save valuable setup time. I will consider the mission accomplished if this mana is useful to someone.

Introductory

So, there is a remote server behind a protected circuit. On the server in the docker, microservice is raised with xdebug enabled. There is access from the outside only via SSH and via VPN.

purpose

Purpose: run remote debugging of microservice locally via xdebug.

Go…
')

1. Configure sshd on a remote server

The first thing you should pay attention to is that you need to configure sshd on the server so that it allows accepting connections from any IP, and not just from 127.0.0.1. This option is off by default.

This is where root is needed. We assume that you have it :-)

sudo echo "GatewayPorts yes" >> /etc/ssh/sshd_config sudo service ssh restart 

2. Find out the address of the host machine in the docker network

Since xdebug runs in the docker and connects itself to the local machine (and in my case this IP does not resolve, because the connection is under a VPN), it is useful to know the IP of the host machine on the docker network. This can be done using the command (execute on the server):

 ip -4 addr show docker0 | grep -Po 'inet \K[\d.]+' 

Suppose the team issued "172.17.0.1"

3. We register the remote host IP in the xdebug settings in the container

An example of a replacement is through sed, but it is also possible with pens in the editor, for whom it is more convenient:

 sed -i 's/xdebug.remote_host=.*/xdebug.remote_host=172.17.0.1/' /usr/local/etc/php/conf.d/xdebug.ini 

Without departing from the cash register, we prescribe the "correct" port for debugging. In my case, microservice is raised on a bunch of nginx & php-fpm and usually port 9000 is busy under php-fpm , and therefore I use port 9001 for debugging.

 sed -i 's/xdebug.remote_port=.*/xdebug.remote_port=9001/' /usr/local/etc/php/conf.d/xdebug.ini 

Here it is worth checking that remote debugging is, in principle, enabled: "xdebug.remote_enable = 1"

 grep xdebug.remote_enable /usr/local/etc/php/conf.d/xdebug.ini 

Usually these settings are stitched in the Dockerfile or mounted through the volume.

Everything is ready on the server. Now we are transferred to the local machine to build a tunnel.

4. We forward the SSH tunnel to the remote server

The tunnel is raised by the command (we execute it on the local machine):

 SSH -R 9001:0.0.0.0:9001 user@remote_server 

Magical music is played in this place. The basic setup is done, only the debugging environment is next.

IDE settings

I usually use vscode, so the port listening debugger runs without problems. I’ll give an example config for vscode (just add a node to launch.json):

  { "name": "Listen for XDebug", "type": "php", "request": "launch", "port": 9001, "cwd": "${workspaceFolder}", "pathMappings": { "/repo": "${workspaceRoot}" } }, 

“PathMappings” is a rule for mapping local and remote machine directories, where “/ repo” is a directory with debugged code in the docker. It is necessary that the debugger can navigate through files and breakpoints.

PS Well, potest?

We run the netcat on the local machine and listen:

 nc -l 9001 

We launch a single-line script in the docker and print:

 php -r 'print("Hi!" . PHP_EOL);' 

On the local machine, we should see the callsign xdebug:

 <?xml version="1.0" encoding="iso-8859-1"?> <init xmlns="urn:debugger_protocol_v1" xmlns:xdebug="https://xdebug.org/dbgp/xdebug"... 

Hooray! All is ready.

Now you can debug your favorite code in the IDE on a remote machine. In the described method there is an obvious disadvantage: reconfiguration of sshd on the server. Perhaps there is a quieter way. In any case, I will be happy for your comments and suggestions.

Thanks for attention!