[Feature]: Allow ssh agent forwarding

[greaber]

Problem

Our devs normally ssh to servers using ssh -A so that they can authenticate Gitlab and perhaps other services using their local ssh keys, which we don't want to copy to remote servers (and in fact they cannot be copied to remote servers since they are yubikey-protected). In dstack, however, this does not work for some reason. (I am not an ssh expert and am not sure what blocks it from working.)

Solution

Figure out why ssh agent forwarding doesn't work and fix it. This might just involve a one-line change to .dstack/ssh/config, but I'm not sure

Workaround

Agent forwarding to the host (using ssh -A <dstack-instance>-host) does work, so we can have our devs do git operations from the host. Another possible workaround would be to use a different ssh key that doesn't require forwarding (not yubikey protected)

Would you like to help us implement this feature by sending a PR?

Yes

[un-def]

Thanks for the issue, we'll investigate if this can be fixed

[greaber]

Thanks. I guess I said that I would help by sending a PR, but at least at the moment, we're not sure how to fix it

[peterschmidt85]

Thanks. I guess I said that I would help by sending a PR, but at least at the moment, we're not sure how to fix it

@greaber
Question #1 - As a workaround is it possible to use SSH keys that don't require a passphrase - until we support SSH agent forwarding?
Question #2 - Is it correct that SSH keys with passphrases are only required for Git?
Question #3 - It is correct that you only plan to use SSH keys that require passphrase only for dev environments?

[greaber]

Hi, Peter. For us it is more about yubikeys than passphrases, but some the issues are similar since both cases would be solved by ssh agent forwarding.

We require all our employees to use ssh keys secured by yubikeys because this mostly ensures that it is impossible to authenticate as the employee without physical access to their yubikey. Ssh forwarding is an asterisk on this because if an attacker can gain access to the remote socket connected to the yubikey through ssh forwarding, they could authenticate as the user (although, depending on how the yubikey is configured, the user may be prompted to touch their yubikey and could become suspicious because of this). Using yubikey-secured ssh keys helps security because it is impossible for anyone to make a copy of the ssh key.

So yeah, we could tell everyone that they should make a new ssh key with no yubikey protection or passphrase and add that to Gitlab, but this would be an inconvenience and undermine the security we get with yubikeys. Maybe the more likely workaround we would try is telling people to ssh to the host since agent forwarding to the host does work and they could git pull from the host.

Most of our employees only have one ssh key, and it is protected by a yubikey. The main things they use it for are logging in to remote servers and accessing Gitlab.