On Sun, 20 Oct 2019, Ted Unangst wrote: > Ah, so when this happens, it's on a machine that doesn't have id_ed25519.pub. > Here's a before and after ssh -vvv for reference.
ah, so you have just the private key id_ed25519 and no corresponding pubkey on this machine? So, what usually happens is that ssh can test whether or not a key has a chance of being accepted by sshd if it has the pubkey. That is what is happening here: > debug1: Next authentication method: publickey > debug1: Offering public key: [email protected] ED25519 > SHA256:KQM4nnWGRt2PxBx9AZIST6zCR6j4XQAQLSdpRfm9jfg agent > debug3: send packet: type 50 > debug2: we sent a publickey packet, wait for reply > debug3: receive packet: type 51 It seems to have an ed25519 key in your agent that ssh tests against the server, but the server isn't interested. If it were then ssh would invoke the private key (either from disk or, in this case, via ssh-agent) to sign a challenge and perform a real authentication attempt. The try-key-valid vs signed-auth-attempt are separate because ssh tries to avoid unwrapping or invoking private keys unless there is a chance they will be accepted. Anyway, in this case the key wasn't prima facie acceptable so ssh continues to try other keys. Eventually it arrives at your id_ed25519 key: > debug1: Trying private key: /home/tedu/.ssh/id_ed25519 > Enter passphrase for key '/home/tedu/.ssh/id_ed25519': Here, there is no .pub file available to perform the public key test described above. So ssh has no option but to try to unwrap the private key in order do the try-pubkey-valid test. If you add a corresponding .pub file then ssh can just test it without unwrapping the private key. I can't recall any changes being made to this behaviour recently, but it's possible that I'm wrong. -d
