SSH Key Impersonation: Is it Possible?

TL;DR

A malicious SSH server can successfully pretend to know a client’s public key, but only if the client has previously connected to that server (or one controlled by the attacker) and the server stored the key. This is because SSH uses a challenge-response system based on pre-shared keys. Without prior connection data, impersonation isn’t possible.

How SSH Key Authentication Works

Before diving into impersonation, let’s quickly recap how SSH key authentication works:

1. Key Pair Generation: A client generates a public/private key pair.
2. Public Key Distribution: The client copies the public key to the ~/.ssh/authorized_keys file on the server they want to access.
3. Connection Attempt: When the client connects, the server sends a challenge (random data).
4. Signing the Challenge: The client uses its private key to digitally sign the challenge.
5. Verification: The server uses the stored public key to verify the signature. If it matches, authentication succeeds.

Can a Malicious Server Impersonate?

Yes, under specific circumstances. Here’s how:

Step 1: The Server Already Knows Your Key

The most important condition is that the malicious server (or a server it controls) has previously seen your public key. This happens when you connect to it legitimately and SSH stores your key in its authorized_keys file.

Step 2: The Attack Scenario

1. Compromised Server/Man-in-the-Middle: An attacker compromises a server you’ve connected to before, or sets up a man-in-the-middle attack.
2. Challenge Generation: The malicious server generates the same challenge that a legitimate SSH server would create.
3. Signature Verification (with your key): Because it has your public key stored in authorized_keys, it can verify any signature you send using that key.
4. Authentication Success: The attacker gains access as if you’ve authenticated correctly.

Demonstration (Simplified)

This is a conceptual example to illustrate the process. It doesn’t cover all security aspects of SSH.

Step 1: Client Connects to Legitimate Server

ssh user@legitimateserver

(The server stores your public key in ~/.ssh/authorized_keys)

Step 2: Malicious Server Takes Over (or MITM)

Assume the attacker now controls the server or intercepts connections.

Step 3: Client Connects to Malicious Server

ssh user@maliciousserver

The malicious server, having your key from the legitimate server, can verify your signature and grant access. It’s essentially ‘replaying’ a successful authentication.

How to Protect Yourself

1. Key Management: Be careful about where you distribute your public keys. Only add them to servers you trust.
2. SSH Agent Forwarding (Caution): Avoid using SSH agent forwarding unless absolutely necessary, as it can expose your private key.
3. Two-Factor Authentication (2FA): Enable 2FA for SSH whenever possible. This adds an extra layer of security even if your key is compromised.
4. Regular Key Rotation: Rotate your SSH keys periodically. Generate new key pairs and remove old ones from servers.
5. Monitor Authorized Keys: Regularly review the contents of your ~/.ssh/authorized_keys file on all your servers to identify any unexpected or unauthorized keys.
6. Host Key Verification: Always verify the host key when connecting to a new server for the first time. This helps prevent man-in-the-middle attacks.

Important Note

This explanation focuses on the core principle of SSH key authentication and impersonation. Real-world SSH implementations include various security measures that make successful impersonation more difficult, but not impossible.