A password is not sent by the user, but the server does send a random string that is encrypted so only the user get prove they are the holder of the private key that corresponds to their copy of the public key inside servers copy of authorized_keys prior. Getting your key into that file remotely the hard part...

This way even if an eavesdropper peels back the SSL to see the raw chat, they can't do a replay attack since it's a random string for each connection - genius!

The symmetric key used for the connection is first encrypted with the remote sides public key. Each side says the highest level of symmetric (reversible) key it supports: both my machines run CHACHA20 good for the keystrokes of ssh. An older machine might say AES256 or AES128. This is key that is more important to the data transfer, but it is ephemeral!

Asymmetric keys are only used for login, then switch to symmetric key for data transfer.

Modern setup sends new ephemeral key ever hour, but it used to be every year back the old days.

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. So i need his public key first.

Here is a verbose connection mac to linux on the LAN with verbose output:

(base) ➜  ~ ssh -v marlene
OpenSSH_8.3p1, OpenSSL 1.1.1g  21 Apr 2020
debug1: Reading configuration data /Users/tom/.ssh/config
debug1: Connecting to marlene [10.0.2.101] port 22.
...

here the server says what it supports - some modern elliptic curve post-Quantum one way asymmetric hashes: curve25519, ecdsa, and chacha20 I think for the symmetric key.

debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256

Not quite sure what is above but below is the reversible encryption key declaration:

debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none

Aha - here the server expects that CHACHA key encrypted with a Elliptic Curve Diffie-Hellman reply. A snazzy blend of prime-number factors and post-quantum upgrade.

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:n2z1lvN........7vCrJA/a0xocsQ
debug1: Host 'marlene' is known and matches the ECDSA host key.
debug1: Found key in /Users/tom/.ssh/known_hosts:38
debug1: rekey out after 134217728 blocks
...

i think here you can see it is up to the client to get up to date and generate Elliptic curve keys however. Here it looks like my machine is only seeing id_rsa in my .ssh folder. I guess this means I'd need to generate new elliptic curve keys if I want to be quantum-safe. MY BAD.

debug1: Will attempt key: /Users/tom/.ssh/id_rsa RSA SHA256:u5+23F5a0tqlOk.....eElVw2stXvPhk+M7M <<---- I only have RSA key
debug1: Will attempt key: /Users/tom/.ssh/id_dsa
debug1: Will attempt key: /Users/tom/.ssh/id_ecdsa
debug1: Will attempt key: /Users/tom/.ssh/id_ecdsa_sk
debug1: Will attempt key: /Users/tom/.ssh/id_ed25519 <--- maybe I should keygen?
debug1: Will attempt key: /Users/tom/.ssh/id_ed25519_sk
debug1: Will attempt key: /Users/tom/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,[email protected],ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected]>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: /Users/tom/.ssh/id_rsa RSA SHA256:u5+23F5a0t........w2stXvPhk+M7M
debug1: Server accepts key: /Users/tom/.ssh/id_rsa RSA SHA256:u5+23F5a0tq..........SdTZiuDegeElVw2stXvPhk+M7M
Enter passphrase for key '/Users/tom/.ssh/id_rsa':

I would need to have run ssh-keygen -t ed25519 to create that kind of curve and had it added.

If I had a id_ed25519 key I'd see:

debug1: Will attempt key: /Users/tom/.ssh/id_rsa RSA SHA256:u5+23F5a0...........eElVw2stXvPhk+M7M
debug1: Will attempt key: /Users/tom/.ssh/id_dsa
debug1: Will attempt key: /Users/tom/.ssh/id_ecdsa
debug1: Will attempt key: /Users/tom/.ssh/id_ecdsa_sk
debug1: Will attempt key: /Users/tom/.ssh/id_ed25519 ED25519 SHA256:LI4VvDYy............OKEDfj1vgw <<-----
debug1: Will attempt key: /Users/tom/.ssh/id_ed25519_sk
debug1: Will attempt key: /Users/tom/.ssh/id_xmss
debug1: SSH2_MSG_EXT_INFO received

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)
modulus: 
    00:f1:be:ce:47:2c:30:65:c0:94:9d:a6:b3:8e:21:
    06:06:8f:c2:ad:59:d7:dd:e9:18:41:6b:75:25:60: 
    87:2b:87 (greatly shortened enormous string)
publicExponent: 65537 (0x10001)
privateExponent: 
    2c:fe:9c:9a:36:a9:53:67:02:c2:4d:12:c2:73:a3: 
    1a:f6:fe:b3:3a:db:de:07:65:f5:73:04:d7:f0:04:
    83:01 (shortened quite long enormous string)
prime1: 
    00:f9:4d:fb:6e:52:bd:ba:d7:0b:41:a3:94:b1:c6:
    a1:02:b7:27:38:0d:72:5c:d2:2e:5f:ce:e1:0d:88:
    ae:c1 (I can see two on my terminal at once)
prime2: 
    00:f8:3c:da:21:d8:ae:9d:93:47:d9:ee:3d:e9:6b: 
    27:f9:0d:27:fe:4c:b0:66:9f:8b:9d:d6:cf:93:7f: 
    b4:47 (I can see two on my terminal at once)
exponent1: 
    0c:af:ba:36:c0:01:25:ab:e1:c7:c2:52:43:c5:a7:
    40:2a:1f:d5:cb:61:61:75:d4:a4:4d:7b:c8:5b:87:
    41 (not sure why - these are also bigger than my primes)
exponent2: 
    00:ec:fb:fb:2b:30:d7:92:eb:96:3e:c1:a9:2d:7b:
    c0:c3:8d:01:cf:4e:9b:61:7d:93:26:7e:7a:f0:cf:
    8b:e5 (not sure why - these are also bigger than my primes)
coefficient: 
    79:7a:00:14:81:9d:a8:ba:a9:2c:24:df:07:c4:2d:
    a9:e3:63:bd:f0:5f:83:b2:b5:74:1b:4e:72:c9:5a: 
    ff (not sure why - these are also bigger than my primes) 

The symettric key used for the connection is first encrypted with the remote sides public key. Each side says the highest level of symmetric (reversible) key it supports: both my machines run CHACHA20 good for the keystrokes of ssh. An older machine might say AES256 or AES128. This is key that is more important to the data transfer, but it is ephemeral!

here the server says what it supports - some modern eliptic curve post-Quantum one way asymetric hashes: curve25519, ecdsa, and chacha20 I think for the symmetric key.

Aha - here the server expects that CHACHA key encrypted with a Eliptic Curve Diffie Helman reply. A snazzy blend of prime-number factors and post-quantum upgrade.

i think here you can see it is up to the client to get upto date and generate Eliptic curve keys however. Here it looks like my machine is only seeing id_rsa in my .ssh folder. I guess this means I'd need to generate new eliptic curve keys if I want to be quantum-safe. MY BAD.

The symmetric key used for the connection is first encrypted with the remote sides public key. Each side says the highest level of symmetric (reversible) key it supports: both my machines run CHACHA20 good for the keystrokes of ssh. An older machine might say AES256 or AES128. This is key that is more important to the data transfer, but it is ephemeral!

here the server says what it supports - some modern elliptic curve post-Quantum one way asymmetric hashes: curve25519, ecdsa, and chacha20 I think for the symmetric key.

Aha - here the server expects that CHACHA key encrypted with a Elliptic Curve Diffie-Hellman reply. A snazzy blend of prime-number factors and post-quantum upgrade.

i think here you can see it is up to the client to get up to date and generate Elliptic curve keys however. Here it looks like my machine is only seeing id_rsa in my .ssh folder. I guess this means I'd need to generate new elliptic curve keys if I want to be quantum-safe. MY BAD.