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

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

---

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 used client, the client 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 publickey authentication is possible and which key will be used for authentication. This is neccesary 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, error during script execution can be avoided. Interactive sessions are also possible, but it's more likely that the users detects the honeypot.

Agent forwarded:

If you are using agent forwaring, it's likely that you are vulnerable to mitm attacks, even if you are only using publickey authentication.

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

Using agent forwarding does not mean, you are vulnerable to mitm attacks. If 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!

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. 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 - if agent forwarding is secure 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 setups 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 token. 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 save 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 and when you are using 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 a vesion <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 "agent restriction" was implemented to mitigate phishing attacks on SSH-ASKPASS and FIDO protected keys.

https://www.openssh.com/agent-restrict.html

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

Video explaining the phishing attack: https://vimeo.com/showcase/9059922/video/651517195