3

I know this question was asked several times in several ways, for example:

Can an SSH server fingerprint be spoofed?

What stops an SSH server from MITMing logins?

However, none provided the answer I was hoping to find (I think...).

I'm working with a specific cloud provider where I generate a private/public key for SSH authentication . I upload the public key to the cloud instances store the private key on the client side. When I want to SSH to the cloud instances, I use the private key to open the SSH connection. By doing so, the server authenticates the client.

What prevents from a MITM attacker, that knows the public key to hijack my connection and spoof the server? All he needs is the public key, right?

I don't understand how the fingerprint validation helps in this case. Unless, there is another pair of public/private keys which can be used solely for the purpose of the server's authentication by the client.

Thanks

Community
  • 1
Lior Ohana
  • 133
  • 3

1 Answers1

4

Short answer: No. The attacker needs the private key too.

The SSH protocol uses encryption to secure the transmission. So, it will employ a public and private key. It's possible to someone to send you a spoofed public key, but without the corresponding private key, they will not be able to decrypt the communication, the handshake will fail and your client will disconnect.

But if the attacker have both the public and private keys, they can intercept every communication between you and the server.

ThoriumBR
  • 53,925
  • 13
  • 135
  • 152
  • Thank you but please note that in my case, the private key is held by the client and not the server since the client is the one that needs to be authenticated. If you'll look on how AWS and Google Cloud work; they ask you to upload only the public key to the VM instances in the cloud. – Lior Ohana Nov 11 '15 at 14:02
  • 2
    @LiorOhana, both client and server have public and private keys. The server always has a key pair, unrelated to the key pair a client must have to perform key-based auth. The server's key pair is what drives the fingerprint which identifies the server. – gowenfawr Nov 11 '15 at 14:15
  • @LiorOhana If you log onto your server, you can see the server keys on /etc/ssh/ssh_host_*... – ThoriumBR Nov 11 '15 at 14:22
  • Perfect! that covers the last sentence in my question. Thank you very much. – Lior Ohana Nov 11 '15 at 14:25
  • @ThoriumBR So does it mean that a SSH client sends the public key it has to the SSH server before opening a connection? And if the public key sent by the SSH client matches with one of the authorized public key of the SSH server, then only the server will send a challege to the client? –  Apr 11 '22 at 08:54
  • No, the SSH server have the public key already (it's on the authorized_keys file in the userś home). It sends a challenge, the client signs it with the private key, server checks the signature against the public key it already have. The key isn't transmitted during authentication. – ThoriumBR Apr 11 '22 at 12:38
  • @ThoriumBR So how does the server knows which public key to use to encrypt the challege? –  Apr 13 '22 at 14:08
  • I've read the RFC, and the client supplies the public key he will use in the challenge. The server looks at .ssh/authorized_keys to check if the key is authorized, and checks if the signature on the challenge matches. – ThoriumBR Apr 13 '22 at 16:04
  • @ThoriumBR So does it mean that the client sends the public key again to the server for authentication purpose only? For example, clients sends the public key to server, then server checks the public key in it's .ssh/authorized_keys to conform whether it is authorized or not. Then if the public key is the authorized one, it will send the challege to the client encrypted by the public key.

    Is this how it works?

     –  Apr 14 '22 at 00:21
  • 1
    Yes, basically it's how it works. There are some other ways to authenticate and send the challenge, but this is what is done most of the time. – ThoriumBR Apr 14 '22 at 00:43
  • @ThoriumBR Thanks mate for carification. I was confused because most of the articles on the web didn't mention it. –  Apr 14 '22 at 04:58