2

I do not fully understand SSH. I was hoping someone could fix my confusion.

When you generate an ssh key pair, you create four files.

authorized_keys, id_rsa, id_rsa.pub and known_hosts

My confusion comes from that fact that RSA is an encryption tool, you release a public key pair (n,e) but in the id_rsa.pub file, there is no pair, it's just one gigantic string, where does it split?

Furthermore, how does SSH create a server side password check, RSA is used for encrypting messages, how does them having my public key, combining with my private key create some sort of password confirmation, RSA is used for encrypting messages not password authentication?

  • 1
    Those are files not folders; RSA can do both encryption and signing, but client keys in SSH are used only for signing for authentication. In practice host static keys are also only used for signing for auth, and the keyexchange is done with ephemeral DH (Diffie-Hellman) or the elliptic-curve variant ECDH. – dave_thompson_085 Mar 9 '18 at 2:47
2

known_hosts has nothing to do with public key authentication. It's a list of servers you've previously connected to and fingerprints of their SSH keys to help verify the connection to the server is not being man-in-the-middled.

authorized_keys is a file stored on the server containing the SSH public keys of users authorized to log in to the server.

id_rsa is the private key. id_rsa.pub is the public key. The public key is encoded according to the format in RFC 4253, but basically it's a PEM-encoded blob that contains the key type, length, and the values n and e.

Public key authentication does not involve passwords at all. There's no "password confirmation" step at all. When the client connect, it offers the keys it has to server. If the server can use one of those to connect, it asks the client to sign metadata about the request, including data provided by both the client and server. The client takes the request data, signs it with the private key, and then sends it back to the server. The server verifies the signature of the blob, which shows that the client possess the correct private key (matching one of the public keys in authorized_keys) and grants access.

  • I would like a more in-depth explanation of how the process works when the client wants to ssh into a server that holds his public key. Could you provide a link? Thanks, I don't fully understand from your explanation yet. – J. Doe Mar 9 '18 at 0:59
  • Almost. OpenSSH pubkey blobs are base64 but not PEM which is base64 with linebreaks plus header and trailer. Client offers one key at a time, using actual key not fingerprint; if acceptable, for SSHv1 which is broken and obsolete it decrypts and keyed-hashes a challenge while for current SSHv2 it signs its own request info plus the 'exchange hash' which covers all significant kx data from both sides including 'cookies' (nonces) from both. I don't know where this 'sign challenge' trope comes from. – dave_thompson_085 Mar 9 '18 at 3:22
  • @dave_thompson_085, it was a poor attempt to simplify what is obviously a complex topic. I guess the trope comes from that, sorry, I've tried to correct a few things. – David Mar 9 '18 at 5:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.