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?

Anders
  • 64,406
  • 24
  • 178
  • 215
Minaj
  • 1,536
  • 2
  • 14
  • 23

1 Answers1

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
techraf
  • 9,141
  • 11
  • 44
  • 62
  • 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 '16 at 00: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 '16 at 00: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 '16 at 00:38
  • I will check it, but basically whatever. It's the client that initiates connection and it can say: "hey server, encrypt 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 '16 at 00:42
  • [Here](https://www.cisco.com/c/en/us/about/press/internet-protocol-journal/back-issues/table-contents-46/124-ssh.html) 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 '16 at 01:11
  • why doesnt SSH use a third party to sign the server's public key? Or stated differently, why doesnt SSL use the server-verification approach used by SSH given that it eliminates the third party and is hence more efficient? – Minaj Jun 12 '16 at 01:12
  • That's a totally different topic. Please post it as a new question. – techraf Jun 12 '16 at 01:13
  • @techraf "On the client side the message is decrypted using the public key and its content is verified". How does this work? How does the client know what message to expect? Shouldn't it be like the following: 1. Client generates a message and encrypts this message using the server's public key and sends this encrypted message to the server. 2. Server decrypts this message using its private key and sends the decrypted message to client. 3. Client compares the received message with the message it initially generated. It they match, then server has the private key and it is authenticated. – Utku Mar 24 '17 at 14:47
  • @Utku You basically rephrased [my comment](https://security.stackexchange.com/questions/126779/verifying-ssh-fingerprint-of-a-public-server/126781?noredirect=1#comment233702_126781). Not sure why... But even that would not be necessary -- it's enough that the client side expects the message meets certain criteria. Let's say it must start with `AB` and ends with a 2-byte checksum (that's not what . If the message wasn't encrypted with the legitimate private key, the decryption with the public key would result in garbage and not meeting the criteria. – techraf Mar 24 '17 at 15:06
  • _"a message encrypted with its private key (which exists only on the legitimate server)"._ Do you mean "a message **signed** with the server's private key"? I've read that you encrypt with public key, sign with private key. – wisbucky May 24 '18 at 23:04