3

I have read somewhere that servers which have SSH access for users in the public can have their public key posted publicly (e.g., on a website), so that people who access such a server using SSH can use this key to verify the server's fingerprint.

My question: If the public key is accessible to the public, cant a malicious user get it and exploit it to man-in-the-middle people who try to connect to this server?

Also, what exactly is in this SSH fingerprint? Is it just a public key that has been hashed? Or is it server-specfic information that has been encrypted (or signed) by the server's private key?

Improve this question
2

1 Answer 1

Reset to default
5

A malicious user cannot exploit a publicly known fingerprint of a public key, because verification is not limited to comparing the fingerprint to a fixed value.

Server presents two pieces of information to a client:

  • a public key
  • a message encrypted with its private key (which exists only on the legitimate server)

On the client side the message is decrypted using the public key and its content is verified.

User is given an option to manually compare the fingerprint of the public key to a known value.

By comparing the public key fingerprint, user ensures it belongs to the server they want to connect. By decrypting the message, client application ensures the server "holds" the corresponding private key.

Knowledge of the public key or its fingerprint does not give an attacker any information about the server's private key (that's the most basic principle of public key cryptography).

If attacker planted a malicious server, it still would need to use a private key to encrypt communication with the client. Communication encrypted with this private key would require decryption with a corresponding public key (different to the legitimate one).

User can then compare the fingerprint of the public key used with the one of the legitimate server as published.

Of course if an attacker altered the information about the server's public key and replaced it with their own, that attack would work. Thus user must evaluate the trustworthiness level of the medium they learnt the fingerprint from. In simple words: if the fingerprint information is provided on an unencrypted HTTP site or through a compromised channel it cannot be trusted.

Historically default fingerprint was presented as 128-bit MD5 hash in the form of colon-separated hex values:

 43:51:43:a1:b5:fc:8b:b7:0a:3a:a9:b1:0f:66:73:a8

The default was later changed to SHA-256 written as:

xrcV3g7R6sp8DVZGDEAhCL9s4TD9GFyrCbLCzHXi5iA

An OpenSSH client allows asking for a specific hash using the option FingerprintHash specified either in .ssh/config or directly in command:

ssh -o FingerprintHash=md5 example.com
Improve this answer
10
  • So basically the ECDSA fingerprint is a combination of the server's public key and some info encrypted using the server's private key? Any ideas on what info exactly is encrypted with the private key? To determine that the decryption has worked correctly, the client would have to know what information exactly was encrypted at the server. What info is this; and how does the client get to know about this info in advance?
    – Minaj
    Jun 12, 2016 at 0:31
  • No, it's not a combination. ECDSA fingerprint is a hash (fingerprint) of a public ECDSA key. For compatibility reasons SSH servers have several keys, like: RSA, DSA, ECDSA, ED25519 (you can ls /etc/ssh/*.pub on a *nix machine to see different server's public keys). On connection client says ECDSA key fingerprint is SHA256:... that reads: the SHA256 fingerprint of the ECDSA key.
    – techraf
    Jun 12, 2016 at 0:34
  • Thx. This means the other info encrypted by the server's private key is sent separately from the fingerprint (which could be ECDSA, RSA, etc). You know what information is encrypted by the server's private key and how the client determines that the decryption has worked successfully?
    – Minaj
    Jun 12, 2016 at 0:38
  • I will check it, but basically whatever. It's the client that initiates connection and it can say: "hey server, encrypt <this> for me with your private key, so that I can later decrypt it with your public key that I verified using its fingerprint I got from the source I trust".
    – techraf
    Jun 12, 2016 at 0:42
  • Here is a good explanation of the connection process, but it still does not explain how exactly is identification string generated. Doesn't really matter that much, a random number, I guess. It doesn't need to be kept secret for the process to work.
    – techraf
    Jun 12, 2016 at 1:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .