Help me understand ssh...

[cleverhandle]

So now that I've finally got DSL (w00t!), I'll be setting up some simple services on one machine, using openssh for remote adminstration. I understand how to use it, but I was hoping someone could give me a little background on how it works under the hood, just because I like to understand these kinds of things. Specifically, how is it that a client can securely transfer a password to a server without any prior knowledge of encyption keys? It seems to me like the first connection has to be untrusted and vulnerable to man-in-the-middle attacks (not that anyone would bother with me... ), since both machines do not yet have knowledge of both keys. Any good articles or nutshell descriptions of this? I searched a bit and found this article from IBM, which does a nice job of explaining how to use RSA/DSA keys for passwordless authentication, but I still don't really understand how the initial handshaking between hosts works in the first place.

 

[mjquilly]

Specifically, how is it that a client can securely transfer a password to a server without any prior knowledge of encyption keys?

It doesn't. The public key is known before transmitting the password.

 

[cleverhandle]

Hmm... OK, so it works something like this, then? The client knows the server's public (encryption) key, uses it to encrypt the password, which is decrypted by the server's private key. And presumably, the client sends it's own public key (encrypted again with the server pubkey?) along with the password, so that the server knows how to encrypt the data it sends back to the client? So as long as the local user checks the server's public key fingerprint against a reference (web page, email, letter, etc.), it's all good?

 

[mjquilly]

Originally posted by: cleverhandle
Hmm... OK, so it works something like this, then? The client knows the server's public (encryption) key, uses it to encrypt the password, which is decrypted by the server's private key. And presumably, the client sends it's own public key (encrypted again with the server pubkey?) along with the password, so that the server knows how to encrypt the data it sends back to the client? So as long as the local user checks the server's public key fingerprint against a reference (web page, email, letter, etc.), it's all good?

indeedy. i'm not sure if the public key is encrypted or not, it doesn't need to be since it's only used for encrypting, but the rest of what you typed I belive is correct.

 

[n0cmonkey]

openssh.com probably has some good information on it. If I was thinking better Id try to write a little something.

 

[cleverhandle]

Originally posted by: n0cmonkey
openssh.com probably has some good information on it.

Indeed, that would seem logical, but I couldn't find anything. Lots of more advanced discussion of features and algorithms, but nothing I saw that just layed out the basics of how the authentication works.

 

[n0cmonkey]

Originally posted by: cleverhandle

Originally posted by: n0cmonkey
openssh.com probably has some good information on it.

Indeed, that would seem logical, but I couldn't find anything. Lots of more advanced discussion of features and algorithms, but nothing I saw that just layed out the basics of how the authentication works.

http://www.openssh.com/txt/draft-ietf-secsh-architecture-12.txt


Probably a little rougher than you wanted. Ill keep my eyes open.

 

[Barnaby W. Füi]

that series of 3 ibm articles explained it great for me.

 

[Buddha Bart]

one thing,

public key cryptography is only used for authentication and then sending a third symetric key. That third key is used for all further traffic. The asymetric keys in PKI take a lot of system resources to work with, so they're only used for the first part. A symetric key does not take anywhere near as much, however if someone were able to get it they would be able to decrypt the whole conversation. Thats why you use PKI to do the initial setup and transfer of the symetric key.

You're right in that the first/initial contact is vulnerable to a man-in-the-middle attack. People who are really serious about it don't even let the client just grab the key, they burn it to a little CD and carry it around with them. If the public key of the server you're connecting to ever changes your client will flip out and make sure you're ok with that before proceding. (at least putty and the openssh client do).

Here's a link you should like (best site ever):
http://www.howstuffworks.com/encryption.htm

bart

 

[cleverhandle]

Thanks n0c and Bart for the links - between those and what's been said here, I'm pretty sure I get it now.