Remote SAS 9.4 not usable with encrypted private keys.

[cstotzer]

I'm currently testing the vscode-sas-extension at a clients site. This client has automated processes for generating SSH key pairs and the private keys come with a passphrase by default. The users are not permitted to remove the passphrase from their private keys by a user agreement. However, the new support for remote SAS 9.4 does not allow to use private keys and or a SSH-agent. The use of unprotected SSH private keys is strongly discouraged and companies usually don't permit the use of passphrase-less keys.

Solutions:

• Prompt for the passphrase upon detection of an encrypted private key file (and set the passphrase property of SSH2 Client.connect() method)
• Allow the user to specify the agent socket in the configuration options (and set the agent property of SSH2 Client.connect() method)

The latter being the preferred solution.

[smorrisj]

@cstotzer thanks for logging this issue. See attached PR for a proposal on how I think we can solve this. Essentially we can look at the ssh-agent's SSH_AUTH_SOCK env variable and pass this value to the ClientConnect agent property as you mentioned. Typically SSH_AUTH_SOCK gets set on agent startup for linux/macOS environments. Additionally the user would specify the IdentityFile in the global ssh config for the host entry, also using ssh-add to add the private key. Based on this we could remove it from the connection profile altogether and just let the global ssh config drive the auth pieces.

The reason I propose to look at SSH_AUTH_SOCK is is that depending on how ssh-agent is set to start we could get different socket values on restarts unless they specify -a to bind to a static value for linux, macOS clients. I noticed on windows, the OpenSSH client optional feature uses a named pipe instead of a file descriptor in /tmp. The named pipe value did not change in between restarts. A side effect on windows is that the user might have to define this user env variable once, set to this static named pipe value( //./pipe/openssh-ssh-agent in my testing with a post build 1809 windows install). Thoughts?

It would probably be wise to also test this behavior out on the openssh that git can optionally install to measure behavior.

[cstotzer]

Hi Joe, I'm all for having the agent sort out the environment variables on Linux/MacOS as this is how I would expect it to work intuitively. I'll have to test things out on Windows though, but your proposal seems to be a viable solution. I'll get back to you after the easter holidays.

[Becky-Williamson]

Leaving open so the reporter can test the fix in his environment (per Joe)

[gro1m]

@smorrisj @scottdover We are working together with @cstotzer and maybe I can provide you already with some feedback from my side:

1. The connection to the SAS server works - that's great. The testing documentation for Windows here has been very helpful for us in this respect: https://github.com/sassoftware/vscode-sas-extension/pull/202.
2. No Library/Table View for Base SAS - would be nice to have!

What is a real pain for us and makes the extension unfortunately unusable for now is the fact that we did not manage to load already existing files from the remote host. Of course, local code submission to the remote SAS server works, but actually we really would like to develop on the remote SAS server within VS Code (like for example when using the Azure Machine Learning VS Code extension). This is a MUST for us, as a good Git integration is very important, which unfortunately does not work reliably in SAS Enterprise Guide.

Before opening an issue, @cstotzer will look if we can do something here with the Remote-Host extension. But even if that works, it is still unsure if we can then install the VS Code extension on the SAS server. So if you have any possibility to help us here this would be tremendously important for us.

Keep up the great work!

[scnwwu]

Additional requests can be in separate issues. Closing this one.