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. Commented Mar 9, 2018 at 2:47

3 Answers 3


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
    Commented Mar 9, 2018 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. Commented Mar 9, 2018 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
    Commented Mar 9, 2018 at 5:49

With regard to ...but in the id_rsa.pub file, there is no pair, it's just one gigantic string, where does it split?:

First and foremost, the private key file contains the pair of large primes, the public key file contains the product of these two large primes (this is called the 'modulus').

Although the private key and public key files produced by ssh are not PEM files per se (as pointed out by dave_thompson_085), you can use openssl to read these files and see the underlying pair of large primes in the private key file, and see the modulus in the public key file. Furthermore, you can verify that the modulus in the public key file is in fact the product of the pair of large primes in the private key file. See my answer at https://crypto.stackexchange.com/questions/45151/anatomy-of-an-rsa-private-key/78460#78460 for the steps. (Although this answer is written in the context of RSA private and public key files produced by openssl, the same steps can be used with RSA private and public key files produced by ssh).

  • 1
    Mostly incorrect. The publickey files produced by OpenSSH are never readable by OpenSSL. The privatekey files produced by OpenSSH before 7.8 by default (excepting ed25519 and the long obsolete ones for SSHv1) are readable by OpenSSL because they actually are OpenSSL formats; files for ed25519 (always) and other algorithms since 6.5 (2014-01) if you specify -o and since 7.8 (2018-08) unless you specify -m pem are in 'OpenSSH new format' and not readable by OpenSSL -- even though they are (superficially) PEM. Commented Aug 11, 2020 at 5:52

Ignore authorized_keys and known_hosts for now.

I don't think the "pair of big primes" is in the public digest, it's more akin to a hashed scramble, irreversible and asymmetric. The split you speak of is done with the private key (somehow).

RSA is not used for symmetric decryption of your (ssh) state channel, new, ephemeral AES-128/AES-256 type keys are used (actually Chacha now?), modern stream cyphers rolling one byte per time. Every new ssh connection probably has new ephemeral stream cyphers generated, and long running sessions maybe shift keys each hour!

Apart from the SSL wrapping the entire connection, the ephemeral keys are sent somehow using a blend of a portion of the (presumed) prime number that only a certain person could hold? Dunno how this part works, say your challenge is the number 2 and the public key 4162.574257426 only the owner could deduce the ephemeral authenticate magic phrase maybe is 840840 because (420420 / 101) * 2 = 840840.

It is immune to a replay attack because a new challenge number or nonce is generated at the server side: lets say the new nonce is 3, your secret primes (oops, 420420 is not a prime my bad) will produce the answer 12487.722772277 that being 420420 / 101 but multiplied by 3 in this case, changing maybe called a nonce (nonsense).

The old RSA private key files are specially formatted. The two large primes are extracted from this file an agent on your machine similar to:

openssl rsa -noout -text -inform PEM -in 4096-id_rsa
RSA Private-Key: (4096 bit, 2 primes)
    87:2b:87 (greatly shortened enormous string)
publicExponent: 65537 (0x10001)
    83:01 (shortened quite long enormous string)
    ae:c1 (I can see two on my terminal at once)
    b4:47 (I can see two on my terminal at once)
    41 (not sure why - these are also bigger than my primes)
    8b:e5 (not sure why - these are also bigger than my primes)
    ff (not sure why - these are also bigger than my primes) 
  • 1
    "here the server says what it supports - some modern eliptic curve post-Quantum one way asymetric hashes: curve25519, ecdsa," No, X25519 and NISP P256 ECDSA are not post quantum.
    – Z.T.
    Commented Jul 30, 2020 at 12:10
  • "Only the holder of the private RSA key can decrypt the ephemeral CHACHA20 key that I just sent to him using his RSA public key" - No, it uses ECDH, no symmetric key is encrypted using RSA.
    – Z.T.
    Commented Jul 30, 2020 at 12:10
  • @Z.T. since I have both RSA and ED25519 here couldn't the symmetric key be encrypted with either RSA or ED25519 in this case? Or are you saying it is encrypted with ECDH? Perhaps ECDH is able to use my ED25519 key, as the first two letters EC stand for Eliptic Curve yeah?
    – Tomachi
    Commented Aug 1, 2020 at 13:25
  • You have no idea how any of this works. You should be posting question, not answers.
    – Z.T.
    Commented Aug 1, 2020 at 15:34
  • @Z.T. to clear all of this up, perhaps you mite like to post an answer to this question? I would love to know.
    – Tomachi
    Commented Aug 8, 2020 at 8:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .