SSH / Asymmetric Key Cryptography Basics
 

Hi all, I'm a little bit confused about asymmetric key cryptography, particularly the use of RSA keys with SSH.

I have used ssh keys successfully in the past, but only after much headache and not much understanding. My comprehension is this: there is a public and private key, which when combined, allow a user to login.

My question is essentially which key goes where?

I have tried reading several posts and articles online, but they are mostly way above my head and the jargon does not make sense to me. I believe the private key is carried with the user, as in a "license" or fingerprint that is individually owned by a user. I think the public key stays on the remote server (the machine that is connected to during ssh 168.x.x.x ??), and the private key is on the local machine from which you are initiating the ssh session.

If that is true, then how does the private key stay private? Doesn't that schema mean the private key is transmitted over the network to the remote server, to be checked against the public key and accepted/rejected? or is the public key transmitted by the remote server to the local machine? In that case, how can the remote machine verify the local machine is authorized to connect?

I am sure I am missing something simple here.

The public key goes onto the remote server you are going to connect to.

The private key stays on the local client you are going to connect from.

During authentication, the actual private key never leaves the client. Instead, the client takes some identifying session data and signs it with the private key. The server then checks using the public key to see if the signature is valid.

The keys never need to be combined. The private key stays only readable and usable by you. The public key may be given to anyone to whom you need to prove your identity. The way it works is that nobody without the private key can sign a message that the public key will verify.

Thanks Turbocapitalist, that makes sense. One question regarding the signature- how does the server know what a valid signature looks like? The link you provided (great resource btw thank you for that) makes it sound like there must be some information that is shared plain text over the network in order to do the signature verification.

I think this has what you are looking for (under the section "Asymmetrical Encryption")

https://www.digitalocean.com/communi...ection-process

and (harder to read, but the section '7 Public Key Authentication Method: "publickey"'
https://www.ietf.org/rfc/rfc4252.txt

Just FYI, the asymmetric encryption and signing keys are two different keys, they have to be because using a key for both gives away info about it.

A signature scheme is basically a MAC with non-repudiation. It basically hashes the message using a hash function and then applies a keyed asymmetric signing transform (decryption). Whoever receives the message and the signature can check it by encrypting the signature and checking the hash.

As said above, think of the public key as a lock (only for encryption) and the private key as a key (only for decryption).

The signature verification comes after the encrypted connection between the machines is already established. So no clear text is transmitted. Here's a description of the SSH connection process (if the link works)
http://www.linuxjournal.com/article/9566

For key-based authentication, the server has a priori the public part of the public/private key pair. In other words, that type of authentication cannot take place if the keys are not already in place first. Then if a private key was used to sign something then the matching public key, and only the matching public key, works to verify the signature (public key cryptography).

This is incorrect according to the article: the signature verification is used to establish the encryption keys in the first place, so the signature itself can't be encrypted.

However, reading a signature will not reveal the private key (provided the thing signed was correctly padded), so encryption is not needed.

My reading of that is rather than the user's key it would be the server's key, the one(s) in /etc/ssh/, where the initial connection is established before authentication. However, I've not studied the transport layer protocol at all.

According to RFC 4251 (https://www.ietf.org/rfc/rfc4251.txt) section 9.4,

So user authentication is done AFTER the encrypted session is set up.