How to prevent SSH host impersonation attacks?

Question

I have an SSH server, where users can login to with their username and password. I want to prevent attacks that try to steal the user's passwords.

Is there a way to prevent an impersonation attack on my SSH server?

The attack scenario:

1. User connects to my SSH server for the first time or from a new PC (from public/compromised network).
2. An attacker in the network impersonates my SSH server.
3. The attacker sends his public key instead of the real server key to the user.
4. The user accepts the key, assuming it is the real key.
5. The user sends the attacker his password in the authentication stage.

I know that my SSH server can use a certificate, but the attacker can still do the same attack since users don't know that they aren't supposed to get a key and they are used to accept the key in the first connection.

So I'm wondering what method to use to prevent the attack.

Answer 1

I have SSH server, where users can login to with their username and password

Here's the obvious way to fix the problem. Don't use passwords. Instead of letting users choose a password (or generating a password for them) let them upload a public key (or generate a key pair for them). With key authentication, an adversary who can intercept communications can impersonate the server to the client, but cannot obtain the credentials to impersonate the client to the server.

To completely prevent the risk of impersonation, you can provide the server's public key out of band and instruct users to add it to their known hosts file. Using certificates for this makes management easier if you control multiple servers, but it doesn't simplify the initial client provisioning.

Answer 2

The only reliable thing your users can do is to verify the server fingerprint.

Password authentication can be intercepted without problems, because passwords are transferred in plaintext only protected by the encrypted ssh channel. This only protects you, when an attacker is reading the network traffic, but in your case you are sending the password to the attackers server.

Public key authentication does not protect you from a man in the middle attack.

There are some options how to intercept the session. If your users use agent forwarding the attacker can login to your server and has full access to the ssh session.

Without agent forwarding the attacker can redirect the session to a fake terminal and wait for user input. If your users entered sensitive information (password for sudo) the attacker can use this password to authenticate against other servers or accounts.

There are some options, how your users can verify the fingerprint:

• compare the fingerprint with a known value, shared accross a trusted channel (website over https, phone call, ...) Example: SSH Fingerprints for Github https://docs.github.com/en/github/authenticating-to-github/githubs-ssh-key-fingerprints
• if your server has a domain name, publish the fingerprint as a SSHFP Record in dns, but dnssec must be used to protect this channel (https://en.wikipedia.org/wiki/SSHFP_record)
• use a certificate authority (https://docs.github.com/en/github/setting-up-and-managing-organizations-and-teams/about-ssh-certificate-authorities)

More information on how to intercept ssh sessions, when public keys are used, can be found in the documentation of ssh-mitm. https://docs.ssh-mitm.at/advanced-usage.html

Disclosure: I'm the author of ssh-mitm