2

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:


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.

0

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. In most cases the default configuration of agent forwarding is highly vulnerable to mitm attacks!

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
  • using agent forwarding

Which method is better and more secure depends on the used client, the configuration and the operating system.

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

Agent Forwarding

When using agent forwarding, you must always protect your keys with ssh-askpass or a fido2 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 a 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 fido2 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 fido2 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.

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 fido2 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.2, you should not use agent forwarding, because those versions does not support forwarding different agents.

When using OpenSSH >= 8.2, you must configure 2 agents and only add the necessary key, which is used to access the remote servers. Let's call them "agent1" and "agent2".

You must also use different keys for each server!

Agent1 is used to login to the first remote server. This agent has only access to the key, which is necessary to login to the server. That key can be protected with ssh-askpass or fido2 token.

Agent2 is used to be forwarded to another server. That agent must only contain keys which are used to login to remote server and the key which is used to login to the first server must not be included. All keys in the second agent must be protected with ssh-askpass or a fido2 token.

Release notes of OpenSSH 8.2:

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

With this setup the attacker is not able to do a full man in the middle server to the first remote server, because the necessary kay is not forwarded. If the attacker tries to connect to another server, you will be prompted with a confirmation dialog and you are noticed, that a malicious server tries to abuse your forwarded agent.

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 PuTTY on a Linux machine in combination with OpenSSH's agent and keys protected by a fido2-token or ssh-askpass.

When you need OpenSSH, you must use 2 agents, but I don't recommend this setup, because it's error prone and complicated.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.