How do SSH keys work?

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.

Read RFCs if you want more details, run ssh client and server in debug mode to find out what is going on under the hood. — Jakuje, Jun 15 '16 at 16:29

score 2 · Answer 1 · edited Oct 07 '21 at 08:14

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:

Server presents its RSA public key to the client. The client manually verifies that it trusts this key before continuing.
SSH uses Diffie Hellman to establish a shared secret value.
The shared secret along with lots of key exchange data is hashed together and signed using the server's private key.
The client can verify this signature using the server's previously trusted public key.
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.

score 2 · Answer 2 · answered Jun 15 '16 at 16:28

2

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).

answered Jun 15 '16 at 16:28

Jakuje

5,389
17
31

So it sends the public key, if it matches then the data going back is encrypted with that public key, which the private key can then decrypt? And vice versa with the private encrypting and the public decrypting? – amflare Jun 15 '16 at 16:44
*encrypted with that public key, which the private key can then decrypt* -- signed with private key, which public key can verify. – Jakuje Jun 15 '16 at 16:56
What does "signed" mean? What prevents something decrypting something even if the signature does not check out? – amflare Jun 15 '16 at 17:16
@amflare : https://en.wikipedia.org/wiki/Digital_signature If anything, then the would-be decryptor's own code. – Jun 15 '16 at 17:21
Right, I get that. Hence my (apparently flawed) assumption that the keys enabled the encryption and decryption. But it seems like if I was a malicious party, I could intercept the data, and ignore the authenticity of the signature and try to decrypt it anyway. I was under the impression that the keys served as a means of also preventing third-parties from doing that. – amflare Jun 15 '16 at 17:24
@amflare This is about *authentication*. The real server checks that you sent it a correctly-signed message that corresponds to a public key the server knows is yours. An attacker cannot generate such a signature, as they lack your private key. Simultaneously, you are using the *server's public key* (the server also has its own key pair) to encrypt all messages you send to the server. True, someone else could use the server's public key to send arbitrary encrypted messages to the server, but they could not craft a valid authentication message for you, which requires access to your private key. – apsillers Jun 15 '16 at 17:29
So SSH isn't about keeping the data safe, as it is about keeping the server safe? – amflare Jun 15 '16 at 17:32
You are going somewhere else with your question. SSH keeps communication safe. Pubkey authentication keeps your "key" safe even for compromised server. This is only think I wanted to point out (when said very simply). – Jakuje Jun 15 '16 at 17:39
@amflare Authentication is about keeping the server safe (i.e., the server is safe from unauthorized users); confidentiality is about keeping the data safe. SSH does both. In particular, your key pair helps perform authentication, and the server's key pair helps ensure confidentiality. (Consider that when you use a pasword for authentication instead of a key pair, the server's key pair is still at play as part of the confidentiality-encorfing encryption scheme.) – apsillers Jun 15 '16 at 18:14
So my key pair lets the server know I'm not bad data, and the server key par lets me know that it is not bad data? What's to stop a MIM from tampering with the data, and just copying the signature without messing with it? – amflare Jun 15 '16 at 18:55
1) You checking the server public key (fingerprint) during the first connection to the host. 2) [The key exchange](https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange). Server creates part of secret, your client creates the other part, the public parts are exchanged, over the network and the shared secret is derived from them. The signatures go through this encrypted end-to-end channel when you are authenticating. – Jakuje Jun 15 '16 at 19:21
@amflare : That would make the signature verification algorithm reject. (Unless your reference to "data" includes the signature verification key, in which case there would be no point in "copying the signature without messing with it".) – Jun 15 '16 at 22:59

score 1 · Answer 3 · edited Mar 17 '17 at 10:46

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.

How do SSH keys work?

3 Answers3

Linked

Related