Understanding SSH login with public key

[ref]

http://www.unixwiz.net/techtips/ssh-agent-forwarding.html

http://mah.everybody.org/docs/ssh

[Notes]

1. use ssh-keygen to generate a public-private key pair.
2. The public key is stored in id_rsa.pub (or id_dsa.pub). This need to be copied to the server YOU ARE CONNECTING TO, into the ~/.ssh/autherized_keys
3. the private key is stored in id_rsa (or id_dsa). To connect to the same server from another remote machine, copy this file to that machine’s ~/.ssh/ folder
4. The security mechanism of the public-private key pairs are still unclear to me (I get some part by reading online). Somehow the security aspect is related to the fact that during the process of the authentification, the private key itself is NEVER sent via the network. Instead, the local ssh program use the private key to compute a message, sometimes called digital signature, which is sent to the server. The signature is related to the key pair such that anyone who knows the public key can use the signature to verify the identity of the other party. But because the private key itself is never sent, and that the signature is only one-time generated, will change the next time, no one should be able to guess your private key based on the signature and/or the public key.

   I found this site gives a relatively clear explanation:

   [ref]

   http://www.unixwiz.net/techtips/ssh-agent-forwarding.html

   How Key Challenges Work

   

   One of the more clever aspects of the agent is how it can verify a user’s identity (or more precisely, possession of a private key) without revealing that private key to anybody. This, like so many other things in modern secure communications, uses public key encryption.

   When a user wishes access to an ssh server, he presents his username to the server with a request to set up a key session. This username helps locate the list of public keys allowed access to that server: typically it’s found in the $HOME/.ssh/authorized_keys file.

   The server creates a “challenge” which can only be answered by one in possession of the corresponding private key: it creates and remembers a large random number, then encrypts it with the user’s public key. This creates a buffer of binary data which is sent to the user requesting access. To anybody without the private key, it’s just a pile of bits.

   

   When the agent receives the challenge, it decrypts it with the private key. If this key is the “other half” of the public key on the server, the decryption will be successful, revealing the original random number generated by the server. Only the holder of the private key could ever extract this random number, so this constitutes proof that the user is the holder of the private key.

   The agent takes this random number, appends the SSH session ID (which varies from connection to connection), and creates an MD5 hash value of the resultant string: this result is sent back to the server as the key response.

   The server computes the same MD5 hash (random number + session ID) and compares it with the key response from the agent: if they match, the user must have been in possession of the private key, and access is granted. If not, the next key in the list (of any) is tried in succession until a valid key is found, or no more authorized keys are available. At that point, access is denied.

   Curiously, the actual random number is never exposed in the client/agent exchange – it’s sent encrypted tothe agent, and included in an MD5 hash from the agent. It’s likely that this is a security precaution designed to make it harder to characterize the properties of the random number generator on the server by looking at the the client/agent exchange.

   More information on MD5 hashes can be found in An Illustrated Guide to Cryptographic Hashes, also on this server.