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
