What is the RSA Key Fingerprint actually?

[Jorge Fabregas]

Hello everyone,

I'm trying to understand the initial process when I connect to a server using ssh. When I connect for the first time I get the server RSA Key fingerprint. I do understand a bit about public cryptography.

In order to ask my question let me first give you an example: I use PGP for email encryption and signing. When I sign an email the process is this (just signing, not encrypting)

1> My PGP will calculate a hash value of the BODY of the message.

2> That value is then encrypted with my private key.

3> I then send the recipient the encrypted hash value (my sign) along with the rest of the email. Note: The recipient has my public key.

4> The recipient, before looking at my signature, will perfoms a hash operation on the incoming email body obtaining value XX. THEN, the recipient will decrypt my signature (using my public key) so that it will reveal my original hash value YY. The recipient compares this value (YY) with the one he first calculated (XX). If both are the same, message was signed by me.

The steps above were very simplified (just for an example)

My point here is: the signature I sent to the recipient is the encrypted hash value obtained from the hash operation on the msg body. It was encrypted with my PRIVATE key.

All right, when I connect to the SSH server. The server sends me his signature, his host id (key fingerprint). What is this value? Is it a hash value calculated on his public key? Did the server encrypt this value WITH his private key?

It the signature the servers sends me is a hash value on his public key...If this key is not encrypted then anyone can calculate the same hash because anyone can have the server public key. So ...is the server sending me:

first: his public key
second: a hash value of the public key encrypted with his private key?

I'll be glad if anyone can clarify me this.

Thanks in advance,
Jorge

[Steven E. Protter]

I'm surprised people who really know what they are doing have not responded.

My pea brain molecules say.

Public key encryption involved the exchange of an encryption key prior to the transaction. The best example i can provide is exchanging public ssh keys in advance for password free login.

Private key encrption involved encrypting the message with a key that can be calculated on both ends.

An example is those little RSA cards that generate random numbers every 15 minutes.

I've never been able to figure out how to use PGP. I've been told by HP once to send some encrypted config files. I eventually sent them clear text but when they asked for them encrypted, they gave me the encryption key they wanted to use.

This would have, had I known how to do it made the data unreadable as it passed through the public Internet. Because they gave me the key, they would use the same key to decrypt when they got the message.

The hole in this scenario is they sent me the encryption key in a clear text email. So it could have been intercepted. For good private key encryption, you need a secure method of generating a key and getting it to the third party.

All an RSA key is, is a long random letter/number combination that would take the NSA a long time with brute force to break.

Hope this helps.

If it doesn't there are smarter people than me who will respond later I'm sure. Also HP has a very nice underutilized course called Internet Security. I highly recommend it.

SEP

[Chris Vail]

I'm with Clay, as far as the pea-sized-brain molecules go. There are those who understand this confusing stuff a lot better than I. The definitive reference for this--if you HAVE to know whats going on under the covers--is _Practical Unix and Internet Security_ from O'Reilley. http://www.oreilly.com/catalog/puis3/
This is supplied as part of the Security course that Clay mentions.

Quite frankly, I'm mathemagically challenged, despite the pointy hat. I haven't had a requirement to know how the key exchanges work. I've looked at it a few times, and after a while all the numbers start to run together. Since its all under the covers anyway, I just accept that it does work.


Chris

[Steven E. Protter]

Chris,

I think you are confusing me with a person I really admire, respect and wish I could emulate. A. Clay Stephenson.

Just me and my lowly pea brain molecules though.

Good book recommendation.

:-)

SEP

[Jorge Fabregas]

Hello Steven,

Thanks for your help. I really appreciate it. You're always out there.

> Because they gave me the key, they would
> use the same key to decrypt when they got
> the message

I think that when the HP guys told you to send them the config files (encrypted) they sent you their PUBLIC key. You then would encrypt the files with this PUBLIC key. You send it to them and then they will decrypt the files with their PRIVATE key (a key that no one else should have, except them).

> The hole in this scenario is they sent
> me the encryption key in a clear text
> email. So it could have been intercepted.

Sending the key in clear text is very common. You only had to make sure that the key you got is really their key. About interception..it really doesn't matter because it is a public key. Many people publish them on their websites. What you need to make sure is that you got the ORIGINAL public key (it wasn't tampereed)For that reason, when someone sends you their public key, you should call them by phone (or better in person) and ask them for the public key fingerprint. That's a hash value based on the key itself. They will perform this operation and tell you the value. You can then do the same to the key (it's like a checksum) and if both values are equal you are sure you got your friends public key.


Jorge

[Jorge Fabregas]

Hi Chris,

Thanks for the link!

You know... I really don't want to get into much detail about it (key encryption). Let's say I don't want to see the trees at all...but I'm tired of looking at planet earth. At least I'd like to see the wood. :)

Jorge

[Andrew Cowan]

Hi Jorge,

You also asked about the host-key in SSH. This something completely different than the PKI used for session transfers in GPG and SSH conversations.

Whilst it is generated in much the same ways as your user key-pair, the host's public key is used primarily to prevent another host from impersonating it. The floor here is that the first time you connect, you are asked if you will accept this key as the de-facto identifier for the remote host, then every time you attempt to connect again, the key is compared, and if different, the alarm is raised. (SSH prevents you from just knicking this key and putting it another system because it back checks that you also have the matching private-key during the connection validation stage).

If a host-key change is detected, you get a message like "POSSIBLE BREAKIN ATTEMPT...".

I have been doing research into how companies could publish these host-keys on a service such as LDAP, and thus close this initial hole (accepting this is the right key/host), but as yet have had little luck.
The host-key is also used to help seed a random session key for when SSH switches to symmetrical encryption after the link has bee n established.

I hope this clarifies things a bit.

[Jorge Fabregas]

Hi Andrew!

Thanks for the nice info!

> SSH prevents you from just knicking this
> key and putting it another system because
> it back checks that you also have the
> matching private-key during the
> connection validation stage

This is very interesting. I always asked myself: What if I take that public key and put it on another server (since it is a public key everyone has access to it). I tried it...I took one server public key and put it on another server. I couldn't start the SSH Daemon! I know that eventually it wasn't going to work..but I wanted to know if I created a connection to this server (the one with the other's public key) I wanted to know if I was going to get the same RSA fingerprint.

So, can we say this RSA fingerprint is like a checksum of the public key? And that the SSH mechinism you mention prevents another server of taking that public key and use it as if it were theirs (it won't work because they don't have the correspondig private key)?

When I look at my $HOME/.ssh/known_hosts...What is actually there? The public key itself of the server, or just the fingerprint?

Thanks
Jorge

[Andrew Cowan · Accepted solution]

I think you're still getting your wires crossed a bit here?

The public key is the "id_rsa.pub" file, and the corresponding private key is in "id_rsa". You should never publically divulge your private-key, however it is still vulnerable if someone has root access to your machine and can read the "id_rsa" file. Thats where the pass-phrase comes in. If you encrpyt your private key with a pass-phrase then it cannot be used unless an attacker can guess the pass-phrase that decrypts it.

When you mentioned earlier about copying a host key, you can, and it will work, so long as you copy all three pairs of keys from the "/etc/ssh" directory. So long as you stop sshd on the target before doing the copy. In fact this has to work otherwise a cluster that fails over would have a different set of keys and that would cause problems for anyone trying to login using SSH.

The RSA signature is a hash generated as part of the creation of an X.509 certificate. The actual mechanics are quite complicated, but it ensures that the certificate has not been tampered with. SSH does much the same thing again with it host keys to ensure they are valid.