Test SSH agent forwarding

[roblourens]

Testing #16

Complexity: 5

• [x] Windows @sbatten
• [x] Linux @joaomoreno
• [x] Mac @octref

This feature lets your SSH remote access keys stored in the local SSH agent. There are a few ways that you could test this but here is a simple one that I've been using.

If you don't have a VM handy you can use this one

First to make sure your SSH agent is set up correctly on your local machine

• In a local vscode window terminal:
• ssh-add -l - should list one or more keys. Add your keys using ssh-add if needed.

If this doesn't work, see https://code.visualstudio.com/docs/remote/troubleshooting#_setting-up-the-ssh-agent.

General troubleshooting tip, the ssh agent's socket is found using the $SSH_AUTH_SOCK environment variable. If you have trouble, check whether it is set to a file that exists in the local and the remote environments. And include this info with any bugs you file.

Test initial connection:

• Install the nightly SSH extension and uninstall the stable one
• Have SSH auth for github configured for your account
• Have a VM that does not have its own ssh key for github
  • You can verify that this is the case by sshing into the VM and running ssh -T git@github.com, you should get "Permission denied"
• In your ssh config, add ForwardAgent yes to your config for this VM
• Set "remote.SSH.enableAgentForwarding": true in vscode
• Connect to this VM through vscode
• In a terminal, run ssh -T git@github.com, now you should get "Hi ! ..."

Test reconnection:

• (optional) Add this to your remote .bashrc alias rs='SSH_AUTH_SOCK=`cat $SSH_AUTH_SOCK_LOCATION`' and start a new session
• Trigger reconnection
• Once reconnected, running this test again in previously existing terminals should fail, but if you create a new terminal, it should work in that terminal
• In a terminal that went through reconnection, if you configured the alias, run rs. After this, the ssh agent should be accessible from the terminal. If you didn't configure the alias, run SSH_AUTH_SOCK=`cat $SSH_AUTH_SOCK_LOCATION`. The point of this is to update SSH_AUTH_SOCK to the new tunnel that was established during reconnection.

Note - the reconnection user experience is not great right now since the user must often manually update the SSH_AUTH_SOCK variable in existing terminals. But we will be able to do a better job when we use dynamic port forwarding. That is also just an experiment this month.

[weinand]

@roblourens ssh-add -l does not list any keys (because linux is not my normal environment and I'm using a more-or-less clean Parallels ubuntu VM).

What keys should I add by using ssh-add? (I've never used the ssh agent and I do know for what it is good for...)

Where do I find the nightly SSH extension?

[sbatten]

not working in windows for me

$SSH_AUTH_SOCK on remote

key in ssh-agent:

setting enabled:

ssh config

Host az-vm-vscode-4
   HostName az-vm-vscode-4.westus2.cloudapp.azure.com
   User sbatten
   IdentityFile C:\Users\stbatt\.ssh\id_rsa
   ForwardAgent yes
   Port 22
     LocalForward 5901 localhost:5901

[octref]

Once reconnected, running this test again in previously existing terminals should fail,

After reconnection, I'm still able to connect to git@github.com My $SSH_AUTH_SOCK is properly set on remote. And with ssh-add -l I see the same output as my local ssh fingerprints.

[roblourens]

@weinand You will have to add an ssh key that is authorized for github. If you don't want to do that you can also test that you can access some other machine using that key, or even just test that it's returned by ssh-add -l and don't add it anywhere.

@sbatten was that after reconnection? And does it work from a local vscode window?

@octref sometimes when reconnection happens, the old connection doesn't die, and in that case, it will automatically work after reconnection. That just means you got lucky.

[weinand]

After discussion in the Standup we have moved the linux assignment to @joaomoreno because he has actually the problem that was fixed through by "SSH agent forwarding".

[joaomoreno]

The first set of steps worked great, so I'll mark it as tested.

But I don't understand what you mean by test reconnection. I have paused the VM I'm connected to, saw the connection dropping, resumed the VM, resumed the connection and everything still works... is that it? I guess not since I can still run ssh -T git@github.com on the same terminal and it works.

I also don't understand what this means or why I would do it:

(optional) Add this to your remote .bashrc alias rs='SSH_AUTH_SOCK=cat $SSH_AUTH_SOCK_LOCATION' and start a new session

[roblourens]

It sounds like you saw the same thing that @octref did

sometimes when reconnection happens, the old connection doesn't die, and in that case, it will automatically work after reconnection. That just means you got lucky.

[sbatten]

@roblourens I tested reconnection and now all SSH commands hang in any terminal, other commands work without issue

[roblourens]

We found that reconnection actually doesn't work right after all and it will be fixed in tomorrow's insiders 😬