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, if agent forwarding is save to use or should not be used because of known security issues.
I know, there are some othere questions, where this topic is discussed, but those questions are a few years old and ssh clients and attacks have improved over time.
- Secure way to set up GitHub repository in shared remote machine
- How can I run ssh-add automatically, 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 copy 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: https://matrix.org/blog/2019/05/08/post-mortem-and-remediations-for-apr-11-security-incident#ssh
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. Sice 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: CVE description is wrong! Please read the this statement: https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/reject-trivial-auth.html and https://docs.ssh-mitm.at/CVE-2021-36367.html
OpenSSH has no option to disable tivial 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 an 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 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 shoud be used, if the client is not able to protect the keys with ssh-askpass or fido2?