search cancel

Visual Studio Code Remote - SSH integration with PAM

book

Article ID: 214420

calendar_today

Updated On:

Products

CA Privileged Access Manager (PAM)

Issue/Introduction

Visual Studio Code (VSC) with the Remote - SSH extension installed can be used to connect to remote SSH servers and do development on those servers from the local desktop. Can the access be routed through PAM with auto-login and session recording?

Environment

Release : 3.4

Component : PRIVILEGED ACCESS MANAGEMENT

Resolution

The following is based on testing by PAM Support with Visual Studio Code 1.55.2 with extensions Remote - SSH 0.65.4 and SSH Terminal 0.0.4 added, and with PAM release 3.4.3.

In order for PAM to support an SSH connection from a local SSH client to a target server with auto-logon, a TCP/UCP service with Application Protocol SSH needs to be defined, so that the SSH proxy on the PAM server can handle authentication. Since the PAM user would launch the SSH connection from within VSC, the PAM service would not have a Client Application string defined. We did not see a way to define a custom port for the VSC connection and therefore just used port 22. Note that we have the file transfer options checked in the service. These are new in 3.4.3, which added support of file transfers in the SSH proxy. This is needed for VSC to work.

With no client application defined to be launched, when the user selects the service from the PAM client access page, the PAM client will only popup a message showing which local IP the local SSH client should connect to in order to be routed to the target device.

The user then uses the F1 key in VSC, select "Remote SSH: Connect to Host..." and then picks the local IP configured in the service, assuming that was defined already as an SSH Host.

The PAM SSH proxy will handle the auto-login, if a credential was configured in the access policy for this user and service.

The SSH connection does not land directly in the regular user shell prompt, but runs the vscode-server application that gets installed on the first connection. The application then presents a shell to the remotely connected user. This is at the root of the following observations that may make this integration unattractive for you:

(1) The session recording only captures the initial login and stdout from the VS Code login scripts, such as the environment settings. It does not capture what the user is doing inside the application. This is consistent with general behavior of CLI recordings. E.g. CLI recordings will not capture in a readable format what a user is typing while editing a file using vi. If all you need to have recorded is the user logon and the fact that this is a VS Code session, the recording would cover it. If you don't need the sessions recorded, this would not be a concern for you.

(2) The VSC application keeps the session alive and active, even after you close the SSH connect window. This keeps the PAM access session alive until the user exits VS Code completely on the laptop/desktop, or explicitly logs out of the PAM client. The PAM applet timeout does not kick in, because PAM cannot distinguish between internal VSC communication and actual user input, and with this the PAM user session can remain active indefinitely. This is a behavior of the application that cannot be avoided with configuration settings in PAM.

We are not using VSC ourselves and did not do actual development work to see whether the PAM SSH proxy interferes with any special features, but basic tasks like running commands or executing scripts on the remote server worked.

Attachments