SFTP as root in WinSCP for remote debugging (PyCharm)

This post is primarily intended for those new to development who are first faced with the need to run scripts as root, interacting with resources / devices that can only be accessed from an application server behind NAT. A frequent situation in the telecom.

Given: a personal account on the application server, ssh access to this server and passwordless rise to root for a personal UZ. Root access is disabled, scripts function from under the service user and are called by various services and applications.

Task: you need to create a new script / fix bugs in the existing script / expand the functionality of the script with 755 rights.

Activities carried out: changing the rights to the directory / file, running the script from the console, editing in Vim (exit Esc: q!), Debugging with prints, denial, anger, bargaining, depression, acceptance. Acceptance that debugging is vital in a normal debugger of your beloved IDEA.

Solution: get the files visible via sftp as root and run remote debugging.

First, let’s ask the server where the installation path of the sftp server is located, if there is no utility, then we will first install it:

sudo apt install mlocate
locate sftp-server

In response, we get many paths, the names of which contain the mention of sftp-server. We are interested in the final file, in the name of which there is nothing else.

For example:

/usr/libexec/openssh/sftp-server

Next, go to the WinSCP settings. Advanced connection settings -> Environment -> SFTP and write the path found above in the protocol parameters in the “SFTP Server” field.

Then we specify our IDEA as the default application for opening files with the * .py extension. By double-clicking, a copy of the script will be saved to the temporary connection directory, and the script itself will be opened, for example, in PyCharm.

We forward ports from a remote server to our local one.

For this we need:

  • unpopular port on the server, let it be 50005 (it will have to be changed every time the connection is broken, when the VPN falls, it remains busy for several more hours).

  • unpopular port on the local machine, let it be 555.

  • username, let it be user

  • ipv4-address of the server, let it be 192.250.225.62

ssh -f -N -R 50005:127.0.0.1:555 user@192.250.225.62

Go to the Run / Debug Configuration Templates settings (alt + shift + F9 -> Edit Configuration … -> Edit Configuration Templates) and select the Python Debug Server there.

We register host name: 127.0.0.1 in the IDE. You can leave localhost as well, but sometimes PyCharm cannot match this value.

We register in Port: 555 (unpopular port on the local machine to which we did port forwarding from the remote server above)

In the Path mapping, we specify the mapping between the path of the script on the server and its copy on the local machine.

Fill in the fields IDE host name: 127.0.0.1 (or localhost), Port: 555 and map paths between the local copy of the script and its path on the server.

In order to find the path to the temporary directory where WinSCP saved a copy of the experimental script, you can select Open in … -> File explorer in the properties of the file context menu

Next, install on the remote server the version specified in the tips to Run / Debug Configuration

In this example, these are:

pip install pydevd-pycharm~=212.5457.59

Add the lines specified in the second paragraph to the entry point of the script (on the remote server) (they should also be updated in our local copy). By changing the port to the unpopular port on the server that we indicated above, 50005

import pydevd_pycharm

#классы скрипта

if __name__ == “main”:
    pydevd_pycharm.settrace('127.0.0.1', port=50005, stdoutToServer=True, stderrToServer=True)
    #тело скрипта

We launch the debugger in PyCharm on the created configuration, arrange breakpoints, wait for the lines

Waiting for process connection...

Starting debug server at port 555

Use the following code to connect to the debugger:

import pydevd

pydevd.settrace('localhost', port=555, stdoutToServer=True, stderrToServer=True)

We run the script on the server as we did it before and enjoy remote debugging.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *