Cannot use ssh-agent/ always need to enter passphrase

[toufikswar]

Hello,

I like this tool a lot. I just have a question, i don't know if this is an issue, or something I am not doing well.

I would like to connect to a remote folder via SSH without having to enter my passphrase.
I am in Mac, i start a terminal, execute the ssh-add command, and then from the same terminal launch vscode via code command.
In my ssh config file in vscode, i have select $SSH_AUTH_SOCK in Agent.
I am asked to enter the passphrase each time, even though i selected the Agent as mentioned.

Could you please assist? Is there something I am not doing well?

Many thanks,

[SchoofsKelvin]

Could you post your ssh configuration and log here? Mind that you probably want to censor your credentials, hostname, ... first.

Is the $SSH_AUTH_SOCK environment variable actually available to vscode? I'm not well versed on how environments work on Mac (or linux for that matter), but e.g. on Windows, changing the environment after vscode started doesn't retro-actively change vscode's environment.

[nrser]

@toufikswar do you have a private key path in the config? I'm on Mac, and when I had a path to my Private key in the config the extension would ask for a passphrase regardless of the Agent setting.

This works for me with no passphrase:

{
    "sshfs.configs": [
        {
            "agent": "$SSH_AUTH_SOCK",
            "host": "somehost",
            "name": "somehost",
            "username": "$USER"
        }
    ]
}

Note that you seem to need to fill out Username, but the env vars do work for me. Didn't need anything else:

[jayennis22]

I am having the same problem on MacOS 10.15.6, VSC 1.48 and SSH FS 1.18.3. I'm happy to help if you need more info/testing.

[SchoofsKelvin]

Can you paste your logs (Output > SSH FS) here? Make sure to check all sensitive data is censored. The extension should censor passwords/passphrases, but just those.

[jayennis22]

Thanks, see below... It works fine if I ask it to prompt for the passphrase. In the first attempt below, I have asked it not to prompt for the passphrase, expecting it will use the ssh agent. [INFO] Created output channel for vscode-sshfs [INFO] Loading configurations... [DEBUG] Added configuration somelabel from 1 [INFO] Found 1 configurations [INFO] Extension activated, version 1.18.3 [INFO] [createConnection(somelabel,config)] Creating a new connection for 'somelabel' [INFO] Calculating actual config [DEBUG] Read private key from /Users/someuser/.ssh/id_rsa [DEBUG] Final configuration: { "agent": "/private/tmp/com.apple.launchd.He1L0zDWNc/Listeners", "host": "host.domain", "label": "SomeLabel", "name": "somelabel", "privateKeyPath": "/Users/someuser/.ssh/id_rsa", "root": "/home/someuser/proj/someproject", "username": "someuser", "_location": 1, "_locations": [ 1 ], "_calculated": { "agent": "$SSH_AUTH_SOCK", "host": "host.domain", "label": "SomeLabel", "name": "somelabel", "privateKeyPath": "$HOME/.ssh/id_rsa", "root": "/home/someuser/proj/someproject", "username": "$USER", "_location": 1, "_locations": [ 1 ] }, "privateKey": "Buffer(1766)" } [INFO] [createSocket(somelabel)] Creating socket [DEBUG] [createSocket(somelabel)] Connecting to host.domain:22 [INFO] [createSSH(somelable)] Creating SSH session over the opened socket [ERROR] Error while connecting to SSH FS somelabel: Cannot parse privateKey: Encrypted OpenSSH private key detected, but no passphrase given [ERROR] Cannot parse privateKey: Encrypted OpenSSH private key detected, but no passphrase given JSON: {} In this second attempt, I also removed the path to the private key, hoping the agent could provide it. INFO] Created output channel for vscode-sshfs [INFO] Loading configurations... [DEBUG] Added configuration somelabel from 1 [INFO] Found 1 configurations [INFO] Extension activated, version 1.18.3 [INFO] [createConnection(somelabel,config)] Creating a new connection for 'somelabel' [INFO] Calculating actual config [DEBUG] Final configuration: { "agent": "/private/tmp/com.apple.launchd.He1L0zDWNc/Listeners", "host": "host.domain", "label": "SomeLabel", "name": "somelabel", "root": "/home/someuser/proj/someproject", "username": "someuser", "_location": 1, "_locations": [ 1 ], "_calculated": { "agent": "$SSH_AUTH_SOCK", "host": "host.domain", "label": "SomeLabel", "name": "somelabel", "root": "/home/someuser/proj/someproject", "username": "$USER", "_location": 1, "_locations": [ 1 ] } } [INFO] [createSocket(somelabel)] Creating socket [DEBUG] [createSocket(somelabel)] Connecting to host.domain:22 [INFO] [createSSH(somelabel)] Creating SSH session over the opened socket [ERROR] [createSSH(somelabel)] All configured authentication methods failed [ERROR] Error while connecting to SSH FS somelabel: All configured authentication methods failed [ERROR] All configured authentication methods failed JSON: {"level":"client-authentication"}

…

On Fri, Sep 4, 2020 at 12:27 PM Kelvin Schoofs ***@***.***> wrote: Can you paste your logs (Output > SSH FS) here? Make sure to check all sensitive data is censored. The extension should censor passwords/passphrases, but *just* those. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#198 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFTR2NEEH435IPEGN3RCF3SEEIPDANCNFSM4NI62HPA> .

[SchoofsKelvin]

It seems like the extension (or more precisely, the underlying ssh2 library) isn't using the agent, or encounters an error and silently discards it. I'll try adding some debug/logging to it, I remember it having some kind of logging facilities. The All configured authentication methods failed means it ran out of methods before one succeeded.

It's been a long-standing issue that ssh2 doesn't play nice when using agent and privateKeyPath at the same time: #120
I'll take another look at whether I can make ssh2 try the agent first. I do remember there being a way to tell the library to try the agent first, but if I remember from back then, giving that "hint" would actually result in private key authentication breaking when there's no agent running.

In this case, there's also another issue of the agent authentication failing. I assume your agent works fine when you try ssh ... in a regular terminal in VSCode? I'm mentioning the "in VSCode" to double-check it's not a permission issue where the VSCode can't access the socket file.

[jayennis22]

I assume your agent works fine when you try ssh ... in a *regular* terminal

in VSCode? Yes, I just re-verified that. Thanks for looking into this issue.

…

On Fri, Sep 4, 2020 at 3:08 PM Kelvin Schoofs ***@***.***> wrote: It seems like the extension *(or more precisely, the underlying ssh2 library)* isn't using the agent, or encounters an error and silently discards it. I'll try adding some debug/logging to it, I remember it having some kind of logging facilities. The All configured authentication methods failed means it ran out of methods before one succeeded. It's been a long-standing issue that ssh2 doesn't play nice when using agent and privateKeyPath at the same time: #120 <#120> I'll take another look at whether I can make ssh2 try the agent first. I do remember there being a way to tell the library to try the agent first, but if I remember from back then, giving that "hint" would actually result in private key authentication breaking when there's *no* agent running. In this case, there's also another issue of the agent authentication failing. I assume your agent works fine when you try ssh ... in a *regular* terminal in VSCode? *I'm mentioning the "in VSCode" to double-check it's not a permission issue where the VSCode can't access the socket file.* — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#198 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACFTR2JT2FKECUFMO2GYYHLSEE3LNANCNFSM4NI62HPA> .

[tngraessler]

Hi...

I also have problems when using an SSH connection as a workspace folder. I have to enter my password everytime, no matter if I configured:

• using a putty session
• using pageant
• using a private key (with and without passphrase)
• even when saving my password in the config

Nothing works, VS Code is asking for my password each time I restart VS Code or add the connection as a workspace folder.

Kind regards

[SchoofsKelvin]

Can you post your configuration (from your settings.json) and add "debug": true to it? That last step adds some extra logging that involves e.g. which authentication it tries and how it goes.

After that, can you post the SSH FS log? It is available under Output > SSH FS. While it should censor passwords/passphrases, I recommend checking it for (other) sensitive data first.

[tngraessler]

@SchoofsKelvin: I just found out what the problem is. When I use something like "root@myserver.net" as name of the config, it works. When I use "root@myserver.net/my/workdir" it keeps asking for the password, but when I enter the correct password, I'm in the specified directory, even if I didn't specify the Root option in the config. It seems like the name mixes up with the Root option somehow. Looks like the name of the config has an impact on the ssh connection, which shouldn't be, it should just be a name. – I hope that helps. :-)

[SchoofsKelvin]

Recently I added "instant connections", as can be seen in the README. The extension internally differentiates between a pure config-based setup and an instant connection setup based on the presence of @ in the name. This even goes as far as converting instant connections for myserver.net to @myserver.net.

Are you actually using root@myserver.net/my/workdir as the whole config name? If so, the extension sees it as an instant connection (user root for the host/config myserver.net). While I accounted for people using user@host as config names, apparently I didn't account enough for more advanced stuff like adding :port and/or /path behind it. I'll check this later.

[tngraessler]

Cool, thank you! :-) Yes, I was using something like "root@myserver.net/my/workdir" as config name, so it makes sense for the plugin to recognize it as an instant connection. I did that because I wanted to have a "convenient" connection pointing to /my/workdir instead of /, but I also wanted a "root" connection pointing to /, so I thought I just add the workdir path to the config name to make it clear which connection points to which directory. I'm now using another syntax for the config name and it's working.

[SchoofsKelvin]

What might help you is just setting your Root to /, but adding a workspace folder for e.g. ssh://ConfigName/my/workdir. All the ssh://URIs are relative to Root, and it does support directories, so you can totally add "subdirectories" as workspace folders. The UI/commands just add ssh://ConfigName/ as a workspace folder (which resolves to Root), but it can be anything.

I'm thinking about, at some point, making ssh://ConfigName/ always resolve to / on the remote server. If I keep the Root config field, it would just make it that the "Add as Workspace Folder" command/buttons would just add ssh://ConfigName/Root as folder instead. Makes it a lot easier (for me and users) to work with, although it means URIs will be longer if you want to mount /a/very/long/path, but oh well. That's not for right now, though.

[tngraessler]

Your suggestion works really well! This way, I don't even have to save two different configs. This is great, thank you!

[adicrescenzo]

@toufikswar do you have a private key path in the config? I'm on Mac, and when I had a path to my Private key in the config the extension would ask for a passphrase regardless of the Agent setting.

This works for me with no passphrase:

{
    "sshfs.configs": [
        {
            "agent": "$SSH_AUTH_SOCK",
            "host": "somehost",
            "name": "somehost",
            "username": "$USER"
        }
    ]
}

Note that you seem to need to fill out Username, but the env vars do work for me. Didn't need anything else:

I've the same issue on macos. My ssh-agent is configured and the ssh private key is added to the agent.
I noticed that the environment variable $SSH_AUTH_SOCK is not equal to the one I can see in the bash console (outside VS Code). It seems that the extensions isn't using the running agent.

[SchoofsKelvin]

I noticed that the environment variable $SSH_AUTH_SOCK is not equal to the one I can see in the bash console (outside VS Code). It seems that the extensions isn't using the running agent.
@adicrescenzo commented

Did you start VS Code after your SSH agent? This seems like an OS-level issue with how process environments are inherited. You could try restarting VS Code (from a shell or some MacOS Explorer process) that does already have the proper environment.

[adicrescenzo]

I noticed that the environment variable $SSH_AUTH_SOCK is not equal to the one I can see in the bash console (outside VS Code). It seems that the extensions isn't using the running agent.
@adicrescenzo commented

Did you start VS Code after your SSH agent? This seems like an OS-level issue with how process environments are inherited. You could try restarting VS Code (from a shell or some MacOS Explorer process) that does already have the proper environment.

Sure. I also tried to run Visual Studio Code from the shell but I get the error:

Cannot parse privateKey: Encrypted OpenSSH private key detected, but no passphrase given

[SchoofsKelvin]

You're not using Private Key, only Agent?

This issue would be easier to solve with debug logs, so please follow these steps:

• Add DEBUG_SSH2 to the sshfs.flags array in VS Code's User Settings (settings.json)
  e.g. "sshfs.flags": ["DEBUG_SSH2"]
  • See this issue for more information about adding flags
• If you already have a connection open, close it completely (or even reload the window)
• Go to Output > SSH FS and copy the log from there after replicating your bug
• While it should censor passwords/passphrases, I recommend checking it for (other) sensitive data first.
  (especially since DEBUG_SSH2 activates some internal logging, which is less likely to be censored)

[adicrescenzo]

I found the issue! In the host configuration file I've specified the Private Key path and also the Agent but these settings are not compatibile with each other.

Leaving empty the Private Key field and setting the Agent filed with the vale $SSH_AUTH_SOCK it works perfectly!

Hoping that this could help someone else and @SchoofsKelvin many thanks for your support