How do SSH keys work? [duplicate]

Question

I'm just looking for a simplified explanation of the mechanics of SSH authorization.

Basically, what makes it better then a really long password? And how does the public key play into things?

I understand how to use it, but I want to know how/why it works.

Edit: As mentioned in the comment I made right after I posted this, that other question does not answer mine. Stop marking it as a duplicate please. Or if you insist, post an answer over there that also answers my question.

Answer 1

Basically, what makes it better then a really long password?

They are not transfered over to the server (as even the very long password have to be transferred). It is not insecure in the ssh case (the channel is encrypted unless you use broken ciphers), but in theory it can be intercepted by Man In the middle or malicious (super)user on the remote server.

And how does the public key play into things?

This is the point of asymmetric cryptography. Private key creates signature and public can verify that the signature was made by the respective public key. You send the public key and signature of data offered by the server and this is enough for the server to allow you the access (if the public key matches the one in authorized_keys).

Answer 2

I'm not sure what you're comparing SSH with the "very long password". SSH provides a secure means to send your user login and password to a remote server. Or you can use a client's public key. Asymmetric keys are generally harder to break because they're not subject to users creating bad passwords. Public Key Based Authentication is preferred for that reason. You can white-list specific public keys for your user (and IP) so that not just anyone can login with your username, and from any computer. This white list is contained in /home/<user>/.ssh/authorized_keys.

Basics of SSH:

1. Server presents its RSA public key to the client. The client manually verifies that it trusts this key before continuing.

2. SSH uses Diffie Hellman to establish a shared secret value.

3. The shared secret along with lots of key exchange data is hashed together and signed using the server's private key.

4. The client can verify this signature using the server's previously trusted public key.

5. Both sides now have all the information needed to generate session keys.

From section 7.2 of RFC4253

7.2.  Output from Key Exchange

   The key exchange produces two values: a shared secret K, and an
   exchange hash H.  Encryption and authentication keys are derived from
   these.  The exchange hash H from the first key exchange is
   additionally used as the session identifier, which is a unique
   identifier for this connection.  It is used by authentication methods
   as a part of the data that is signed as a proof of possession of a
   private key.  Once computed, the session identifier is not changed,
   even if keys are later re-exchanged.

   Each key exchange method specifies a hash function that is used in
   the key exchange.  The same hash algorithm MUST be used in key
   derivation.  Here, we'll call it HASH.

   Encryption keys MUST be computed as HASH, of a known value and K, as
   follows:

   o  Initial IV client to server: HASH(K || H || "A" || session_id)
      (Here K is encoded as mpint and "A" as byte and session_id as raw
      data.  "A" means the single character A, ASCII 65).

   o  Initial IV server to client: HASH(K || H || "B" || session_id)

   o  Encryption key client to server: HASH(K || H || "C" || session_id)

   o  Encryption key server to client: HASH(K || H || "D" || session_id)

   o  Integrity key client to server: HASH(K || H || "E" || session_id)

   o  Integrity key server to client: HASH(K || H || "F" || session_id)

   Key data MUST be taken from the beginning of the hash output.  As
   many bytes as needed are taken from the beginning of the hash value.
   If the key length needed is longer than the output of the HASH, the
   key is extended by computing HASH of the concatenation of K and H and
   the entire key so far, and appending the resulting bytes (as many as
   HASH generates) to the key.  This process is repeated until enough
   key material is available; the key is taken from the beginning of
   this value.  In other words:

      K1 = HASH(K || H || X || session_id)   (X is e.g., "A")
      K2 = HASH(K || H || K1)
      K3 = HASH(K || H || K1 || K2)
      ...
      key = K1 || K2 || K3 || ...

   This process will lose entropy if the amount of entropy in K is
   larger than the internal state size of HASH.

Once the encrypted channel is established the SSH protocol begins the client authentication based upon parameters you've given it. All of this is performed securely through the encrypted channel.

Answer 3

Let me provide a high level picture. Clearly, you understand the need for secure communications, be it SSH or HTTPS. Secure communications mean that the channel is encrypted.

Generally speaking all encryption algorithms fall into one of two categories:

• Symmetric encryption. One key. Same key is used to encrypt and decrypt. Fast. E.g. AES.
• Asymmetric encryption. Two keys. Either may be used to encrypt, but only the other one can decrypt. Much slower than symmetric algorithms. E.g. RSA.

Symmetric encryption is fast and therefore suited for communications involving a lot of data between two parties. It uses the same key for encryption and decryption - this key is analogous to your concept of a very long password. Problem: how do you share your key/password in the first place? Turns out you cannot use a secure channel that is built solely on a symmetric encryption algorithm without figuring out a way to first share your key/password.

This is where asymmetric algorithms come in, but are considerably slower than symmetric algorithms. Impractical to transmit large amounts of data, but fine if you transmit or exchange something small like a symmetric encryption key/password. Once that's done you can now use symmetric encryption for communications.

One of the two keys for asymmetric encryption is designated the public key and the other the private key. The public key may be distributed to everyone, but private key must be kept secret.

You (has pub)                             Server (has prv + pub)
asym-encrypt(pub, sym-key/pwd) ---->  asym-decrypt(prv, encrypted-data) => sym-key/pwd

pub = public key, prv = private key

In any case this explanation is a simplification of what SSH actually does. Two other things worth highlighting:

• Diffie Hellman is the typical key exchange asymmetric algorithm. With Diffie Hellman you don't actually need to create a symmetric key. Both parties create the symmetric key together during the key exchange, which is a nice security feature. See "Diffie-Hellman Key Exchange" in plain English.

• In my explanation I assumed that you found the server's public key, and that you trust it is the correct one. But you really should be careful about which public keys you trust. To trust a public key, it should be digitally signed. A signed public key is also known as a certificate.

Hopefully this clears up the questions about long password and public keys, and has enough information for you to dig deeper in a more meaningful fashion.