3

The server does not know any secrets that can be used to authenticate itself.

Also, what good is a fingerprint if it is based on the public key if it is basically the hash of some known public key.

What protection is there from an "ssh server spoofing"?

SUMMARY AND REFLECTIONS: I have already seen the duplicate question before posting this one up. The part that for me was not clear, is that the server too has a private key. And when you attempt to connect to sshd, it will send you the fingerprint of the sshd public key (this will probably be found in the /etc/sshd, different that the ones found in the /home/<users>/.ssh).

This is why ssh keys asks about authorizing a fingerprint on first connect. This is also why the fingerprint changes if you do a new sshd install (new public-private key pair has been generated).

aiao
  • 409
  • 5
  • 7

2 Answers2

3

Typically, SSH clients will keep track of the fingerprint of the public key that they saw the first time you connect to the machine. In fact, often the first time you connect to a machine over SSH, the client will show you the fingerprint and ask you to validate that it is correct.

This validation should take place out of band. In other words, the system administrator should give you the correct fingerprint in a secure manner. Then you can compare the fingerprint the server is presenting you with and the known good fingerprint.

On subsequent connections, as long as the presented public key from the server has the same fingerprint, most SSH clients will accept it and let the connection proceed. On the other hand, if the fingerprint has changed, the SSH clients I've used will actually deny the connection, tell you that the fingerprint has changed and that you may be the victim of an attack.

If, you do not verify the initial fingerprint properly, and someone is actively attacking you on that first connection, they will be able to spoof the connection and possibly steal credentials (depending on the authentication mechanism being used).

mikeazo
  • 2,827
  • 12
  • 29
  • 2
    But posession of the public key does not proof that you are the authentic sever. Nor is the ability to produce the fingerprint – aiao Sep 29 '15 at 14:28
  • I need you to answer one question for me. If the answer is yes, then that solves my problem... Does the sshd (ssh server) have yet another private key that is used in establishing the connection? .i.e. the fingerprint that is sent is the hash of a public key that the server has the matching private key for.? – aiao Sep 29 '15 at 14:35
  • 1
    Yes, for the public key, there is a corresponding private key. There are [two ways](https://tools.ietf.org/html/rfc4253#section-7) you can ensure that the server has the corresponding private key, implicit and explicit. Which one is used depends on the key exchange (kex) algorithm. In both cases, however, we are guaranteed that the server must have the corresponding private key. – mikeazo Sep 29 '15 at 15:01
2

SSH server authentication is essentially up to the user. But what you have to remember is that all of this information is passed after the secure key exchange has taken place.

Summary

Yes an encrypted channel can be established to an unknown server. No the server can't spoof the host-key because the client produces the fingerprint of the public key used to establish the connection. The fingerprint that is shown to you on connection is generated separately, and cannot be influenced by the server.

You're given an opportunity to reject the connection before any credentials are passed if the fingerprint is different from the fingerprint that is cached on the client.

Details

SSH establishes a secure channel, at which point the server provides its public key fingerprint. This is all fully encrypted. During the key exchange (RFC4253) the server signs several pieces of data with its private key for the client to authenticate. This proves that the server has the private key for which the client has the public key.

Every client should display the fingerprint for which the tunnel was established with. The server authentication is completely up to the user at this point. If you don't recognize the fingerprint then you shouldn't login. If the fingerprint has changed since you last logged into that IP address then the client should notify you before any credentials are sent to the server. Which allows you to double check with a server admin before proceeding.

I say every client should because this is completely implementation dependent and there are too many implementations of SSH to count. Generally though most popular SSH implementations (PuTTY, OpenSSH, WinSCP) take these precautions.

Community
  • 1
RoraΖ
  • 12,317
  • 4
  • 51
  • 83