SSH Agent Forwarding – What are the best practices and current security issues?
Using agent forwarding comes with a risk, but stored private keys can also abused if the attacker has compromised the remote machine.
In this thread I want to discuss whether agent forwarding is safe to use or should not be used because of known security issues.
I know, there are some other questions, where this topic is discussed, but those questions are a few years old and SSH clients and attacks have improved over time.
Related Questions:
- Secure way to set up GitHub repository in shared remote machine
- How can I run
ssh-addautomatically, without a password prompt? (does not consider ssh-askpass and fido2) - Are there any risks associated with SSH agent forwarding?
SSH agent forwarding can be a security risk but there are same use cases where it comes handy.
If you need to work on a development machine and checkout a Git repository, forwarding the agent is easier than creating new keys for each dev machine. Another use case is using rsync or copying a file with scp/sftp from one server to another server.
OpenSSH 8.3 has added support for agent forwarding to scp and sftp, which allows remote copy operations with a forwarded agent.
The Matrix developers suggest using dedicated keys, which are stored on the remote server. They also recommend using HTTPS instead of SSH if you only need to checkout a repository. If the repository is private, credentials are needed to checkout the repo.
But if the attacker has compromised the server and gained root privileges, he has access to the SSH sessions and is able to read entered passwords. So the attacker is able to abuse password protected keys or entered credentials to connect to the Git repo over HTTPS.
Recent OpenSSH versions can be configured to forward a different agent to the remote server. So you can use one agent to login to the remote server and the other to login from the remote server to another remote server. The keys from the forwarded agent can be protected with ssh-askpass/fido2 and abusing the keys needs a confirmation from the user.
Release Notes of OpenSSH 8.2:
ssh(1): allow forwarding a different agent socket to the path
specified by $SSH_AUTH_SOCK, by extending the existing ForwardAgent
option to accepting an explicit path or the name of an environment
variable in addition to yes/no.
PuTTY's Pageant is not able to protect the keys with ssh-askpass. When using Linux, PuTTY can use OpenSSH agent. This allows PuTTY to use ssh-askpass protected keys and FIDO2 protected keys, but PuTTY is not able to forward a different agent. Since version 0.71, PuTTY is able to detect spoofing attacks and with 0.76 PuTTY mitigates such attacks by closing the session (disable "trivial" authentication) which makes it harder to abuse ssh-askpass protected keys (CVE-2021-36367). Important: The CVE description is wrong! Please read the this statement from PuTTY and this one from me.
OpenSSH has no option to disable trivial authentication (CVE-2021-36368). My suggested patch was not merged and the OpenSSH devs have not implemented another usable mitigation strategy.
The only possible configuration is limiting the auth methods on the client side to only allow publickey authentication. This disables all auth methods except "none" and "publickey". This is an improvement but only makes it harder for an attacker to spoof the authentication process and abuse ssh-askpass/fido2 protected keys.
PuTTY is not compatible with the OpenSSH version provided with Windows, because the Windows version is using Named Pipes instead of sockets. Windows uses OpenSSH version < 8.2. So there are no options to use different agents and FIDO2 Tokens. I don't know if the agent works with ssh-askpass. (I have no Windows system to test.)
So, what are the best practices to work on a remote server and connect to another server like a Git repository?
- Is it better to use a private key, which is stored on a remote server?
- Is agent forwarding secure enough, when using Linux and a recent OpenSSH version with ssh-askpass/fido2 protected keys?
- What should be used if the client is not able to protect the keys with ssh-askpass or fido2?
Disclosure: I'm the author of SSH-MITM and the patch for PuTTY to disable trivial authentication. I want to provide more information on how to protect ssh sessions and avoid security problems.
