SSH Agent Forwarding - What are the best practices and current security issues?

Question

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-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 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.

Answer 1

The recommended method depends on the client used, the client's configuration, and the operating system.

The SSH client sends all public keys to the server (CVE-2016-20012). Those keys are used to spoof the login process against the remote server, and the attacker knows if public key authentication is possible and which key will be used for authentication. This is necessary for spoofing attacks (CVE-2021-36367, CVE-2021-36368, CVE-2021-36369) against the login process.

Agent was not forwarded

If you are not using agent forwarding, the attacker can redirect the session to a honeypot. On the honeypot, the attacker is able to collect information (entered passwords, filenames, …), which can be used for other attacks. If the connection was established by a script, the script does not recognize that the connected server is only a honeypot. If the honeypot can react properly on the input, errors during script execution can be avoided. Interactive sessions are also possible, but it's more likely that the users detect the honeypot.

Agent was forwarded

If you are using agent forwarding, it's likely that you are vulnerable to MitM attacks, even if you are only using public key authentication.

Agent forwarding allows the remote server to access your local agent and perform key operations with your private keys. Private keys never leave the client, as long as the client is not vulnerable to the roaming bug CVE-2016-0777.

Using agent forwarding does not necessarily mean you are vulnerable to MitM attacks. Whether you are vulnerable depends on the client configuration and version. In most cases the default configuration of agent forwarding is highly vulnerable to MitM attacks!

Should you use agent forwarding or password-protected keys on the remote server?

There are some use cases where you need to work on a remote server and access another server (e.g. a Git repository). To access the Git repository over SSH you need a private key.

You have 2 options:

• Password-protected private key stored on the remote server – insecure and should not be used!
• Using agent forwarding – agent forwarding security depends on the client.

Password-protected private key stored on the remote server

If the server is compromised, the attacker is able to read the password for the private key. You should only use a stored private key if it's not possible to configure agent forwarding to be secure (details explained in agent forwarding).

You should not store private keys on a remote server. Compromising those keys is very easy – even password protected keys!

Agent Forwarding

When using agent forwarding, you must always protect your keys with ssh-askpass or a FIDO token. If the private key is used, you have to confirm this usage, and abusing a forwarded agent becomes harder.

WARNING! The described setup does not protect you from MitM attacks! It only reduces the implications if you are affected by a MitM attack. You must always verify the server fingerprint against a trusted source!

Windows

Most users are using PuTTY for SSH connections, but with Windows 10, OpenSSH can be installed as an extra feature.

PuTTY has it's own agent (pageant) which can be forward to another server. Pageant does not support ssh-askpass or FIDO tokens. When using PuTTY on Windows, it's not secure to use agent forwarding. The Windows version of PuTTY is not able to use the Windows version of OpenSSH's agent. (There are some tools, which allows to use the OpenSSH agent with PuTTY, but I had no time to test them.)

The Windows version of OpenSSH is < 8.2. This is important, because with OpenSSH 8.2 a lot of security features are implemented. It's not possible to use a FIDO token. Even if you are using ssh-askpass in combination with agent forwarding, the authentication process can be spoofed and you are vulnerable to a full MitM attack.

When using PuTTy or OpenSSH under Windows, it's not safe to use agent forwarding.

When using Windows and you must access another remote server, you should use a password protected private key stored on the server.

At the moment (March 2022) there is no easy and secure way when using Windows to access remote servers. When using agent forwarding, your keys are not protected. When you use a password-protected private key on the remote server, the password can be logged.

Linux & PuTTY

When using Linux, you should use PuTTY>0.71 in combination with the OpenSSH agent. Since version 0.71, PuTTY is able to detect spoofing attacks.

When using version <0.76, you can detect spoofing attacks with the trust sigils. Since 0.76, PuTTY has a new option to close the session if a spoofing attack was detected.

When using PuTTY>=0.76, you should use Disable "trivial" authentication (SSH-2 only). This option can be found under "Connection -> SSH -> Auth".

All keys which are managed by the OpenSSH agent must be protected with a FIDO token or ssh-askpass.

With this setup, PuTTY is able to detect spoofing attacks and closes the session. This is the most secure setup and even better than stored private keys on the remote server.

Linux & OpenSSH

If you have an OpenSSH version < 8.9, you should not use agent forwarding, because those versions does not support "agent restrictions.

With OpenSSH 8.9, a new feature called "agent restriction" was implemented to mitigate phishing attacks on ssh-askpass and FIDO protected keys. I have not tested this feature, but it seems to mitigate most phishing attacks.

Conclusion

When agent forwarding is not used, you can only be redirected to a honeypot.

If you need agent forwarding on a Windows machine with PuTTY or the Windows version of OpenSSH, it's not possible to mitigate MitM attacks. Perhaps you can use another client (e.g. Cygwin), but I have not tested this at the moment.

The most secure option is to use OpenSSH>=8.9 or PuTTY on a Linux machine in combination with OpenSSH's agent and keys protected by a FIDO token or ssh-askpass.

PuTTY is a bit more secure than OpenSSH, because PuTTY has phishing detection with trust sigils and is able to close the session if the "trivial authentication" attack is detected. When combined with the OpenSSH's agent restriction and FIDO protected keys, it's safe to use agent forwarding, because it's nearly impossible to abuse forwarded keys.

Watch a video explaining the phishing attack.

Update 2024-07-05: When to use ProxyJump vs. AgentForwarding

ProxyJump (and ProxyCommand) are used to pass an SSH session through another SSH server, called a jump host. This is useful when direct access to a destination server is restricted. If you need to use an SSH server as a jump host, do not use agent forwarding. This is because agent forwarding can expose your SSH agent to the jump host, which can be risky. The jump host could potentially use your agent for malicious operations, as explained in this post.

Use agent forwarding only if you need the agent for tasks like signing Git commits on a remote server or accessing a Git repository via SSH from the remote server. Agent forwarding allows your SSH keys to be available on the remote server for cryptographic operations, which is necessary in these scenarios. However, in such cases, ProxyJump cannot be used because it does not provide the agent forwarding functionality.

In summary:

• Use ProxyJump to securely tunnel through an intermediate SSH server without exposing your SSH agent.
• Use agent forwarding when you need your SSH keys for cryptographic operations on the remote server, but be aware of the security risks involved.