What are possible implications of ignoring the ssh host key warning?

Question

With password authentication you're basically giving your password to the attacker. At least that is my understanding. What about public key authentication? I hear that a private key never leaves your side, and that it's not possible to perform a man-in-the-middle attack with public key authentication. Is that so? Is there anything else I'm missing here?

Answer 1

Publickey authentication does not mitigate man in the middle attacks, but the risk of compromising other servers can be reduced, depending on the client configuration.

Sorry for the long answer, but there are a lot of answers and articles, which does only explain a specific part of mitm attacks on ssh.

Definiton of a man in the middle attack:

Network Layer: If you talk about a man in the middle attack on the network layer, this attack is very easy. If the attacker has access to the network, is possible to redirect the traffic to a different server using arp spoofing or BGP route injection. There is not much you can do against such attacks, if you are only in control of your client.

When talking about this layer, most connections are vulnerable to mitm attacks and you are able to intercept ssh connections.

Application Layer: To mitigate the risk of a man in the middle attack on the application layer, the connection must be encrypted. This is the reason, why a lot of protocols like HTTPS are using certificates to make sure, that they are connecting to the right server and the traffic is encrypted.

The certificates which are used for HTTPS connections are signed by a Certificate Authority (CA) and the public keys are distributed with the operating systems or the browsers. As long as the CAs are trusted, a man in the middle attack is not possible, because they does not establish the connection if the certificate is not signed by a known CA.

OpenSSH also supports certificates, but those are not compatible with the certificates used by webservers and administrators has to setup their own CA. Another problem is, that most ssh clients does not support certificates.

When using publickeys without certificates, you must verify the fingerprint. This is the part you mentioned. The server fingerprint must be compared against a trusted source to make sure, you are connecting to the right destination server. It's the only step which guarantees, that you are not affected by a man in the middle attack (as long as the destination server is not compromised or malicious).

If the connection to a malicious server is established, the attacker has full control over the session and has access to a lot of information and depending on the configuration of the ssh client, it's possible to connect to other servers. This is what most people understand as a mitm attack on ssh.

Implications of ignoring ssh host key warnings:

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

Proof of Concept MitM Attack

If you want to test your configuration, you can use SSH-MITM, which is an audit server for ssh connections.

Install SSH-MITM on linux:

python3 -m venv ~/sshenv
source ~/sshenv/bin/activate
pip install ssh-mitm

Start SSH-MITM and redirect session to a honeypot if publickey authentication failed:

ssh-mitm server --remote-host target --remote-port 22 --fallback-host honeypot --fallback-username honeypotuser --fallback-password honeypotpasswd 

This configuration checks, if the user is allowed to login with publickey authentication. If the user is not allowed, password authentication is used.

If the user is allowed to login with publickey authentication, but no agent was forwarded, SSH-MITM redirects to the honeypot.

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.

Disclosure: I the author of SSH-MITM, which is a mitm server for SSH connections. This server is used to verify if the described mitigation strategies can reduce the risk of mitm attacks on ssh. I have also written the patch for PuTTY to mitigate trivial authentications without the trust sigils.

Answer 2

The ssh host key warning means that the public key that your ssh client now sees for the server is not the same as the public key that your client saw for this server previously. This means that you could be connecting to a malicious server being run by an attacker - either in an attempt to spoof the 'real server', or in an attempt to MITM the connection to the real server. If that's the case, and you ignore the warning, then you will be enabling the attacker to proceed with the attack.

One benefit to public key authentication over password authentication in this case is that if the attack succeeds, the attacker does not come away with anything useful for authenticating with the real server. With public key authentication, the client only divulges his public key (which is public anyway), instead of divulging his password.