I recently switched to a new laptop running bookworm, and started noticing issues connecting to machines running openssh server 0.9.x (e.g. running bookworm). debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering public key: cardno:FFFE 87023833 ED25519 SHA256:SrXM0ACTMy3d2DkLRt/UehScFvN8w+62NoN9/6+u5Kg agent debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 60 debug1: Server accepts key: cardno:FFFE 87023833 ED25519 SHA256:SrXM0ACTMy3d2DkLRt/UehScFvN8w+62NoN9/6+u5Kg agent debug3: sign_and_send_pubkey: using publickey-hostbound-v00@openssh.com with ED25519 SHA256:SrXM0ACTMy3d2DkLRt/UehScFvN8w+62NoN9/6+u5Kg debug3: sign_and_send_pubkey: signing using ssh-ed25519 SHA256:SrXM0ACTMy3d2DkLRt/UehScFvN8w+62NoN9/6+u5Kg sign_and_send_pubkey: signing failed for ED25519 "cardno:FFFE 87023833" from agent: agent refused operation debug1: Trying private key: /home/vagrant/.ssh/id_rsa ... I would assume that this is some client-side interaction, since the agent is running locally, but this same setup works fine when connecting to systems running older versions of openssh server (e.g. bullseye)... so there is definitely something about the newer openssh server versions that triggers the issue. I can also try using my older laptop, which was also running bookworm, to see if I missed something in the configuration. The openpgp smartcard is a fairly old gnuk firmware, fwiw. live well, vagrant
Control: merge 1032907 1008573 ... ... That proved helpful, as the older laptop had a configuration option pointing to the older bug about this same issue: https://bugs.debian.org/1008573 That I had apparently commented on... It showed a workaround with a one-line entry in .ssh/config: KexAlgorithms -sntrup761x25519-sha512@openssh.com live well, vagrant
Control: merge 1032907 1008573 ... ... That proved helpful, as the older laptop had a configuration option pointing to the older bug about this same issue: https://bugs.debian.org/1008573 That I had apparently commented on... It showed a workaround with a one-line entry in .ssh/config: KexAlgorithms -sntrup761x25519-sha512@openssh.com live well, vagrant
Hi José and Vagrant, It seems bugs #998728, 1008573, and #1032907 are all the same. Perhaps the maintainers would like to merge them. Thanks for your workaround, Vagrant; I found that adding KexAlgorithms -sntrup761x25519-sha512@openssh.com to my ~/.ssh/config allows me to connect to a Bookworm machine, from Bookworm, and also to hosts running a newer OpenSSH daemon. A similar issue upstream is here: https://dev.gnupg.org/T6250 Werner K. hints that it might be fixed in the GnuPG 2.3 series. As soon as the maintainers upload it to experimental, I will be happy to test it. Thanks everyone for your attention.
I just confirmed that downgrading to openssh-server 1:9.2p1-2+deb12u3 does work again on at least one machine. live well, vagrant
I just confirmed that downgrading to openssh-server 1:9.2p1-2+deb12u3 does work again on at least one machine. live well, vagrant
With the recent update of openssh in bookworm (1:9.2p1-2+deb12u4) this no longer seems a sufficient workaround; I can no longer ssh in to machines running this version of openssh. My hunch is the problem was introduced in a new and exciting way with: https://bugs.debian.org/1088873 openssh: please add sntrup761x25519-sha512 as an alias to sntrup761x25519-sha512@openssh.com in 9.2/Bookworm Specifying both in ~/.ssh/config does not work around the issue for me: KexAlgorithms -sntrup761x25519-sha512@openssh.com,-sntrup761x25519-sha512 live well, vagrant
With the recent update of openssh in bookworm (1:9.2p1-2+deb12u4) this no longer seems a sufficient workaround; I can no longer ssh in to machines running this version of openssh. My hunch is the problem was introduced in a new and exciting way with: https://bugs.debian.org/1088873 openssh: please add sntrup761x25519-sha512 as an alias to sntrup761x25519-sha512@openssh.com in 9.2/Bookworm Specifying both in ~/.ssh/config does not work around the issue for me: KexAlgorithms -sntrup761x25519-sha512@openssh.com,-sntrup761x25519-sha512 live well, vagrant
Ok, through trial and error, looping through all the algoritms: bad diffie-hellman-group1-sha1 bad diffie-hellman-group14-sha1 good diffie-hellman-group14-sha256 bad diffie-hellman-group16-sha512 bad diffie-hellman-group18-sha512 bad diffie-hellman-group-exchange-sha1 good diffie-hellman-group-exchange-sha256 good ecdh-sha2-nistp256 good ecdh-sha2-nistp384 bad ecdh-sha2-nistp521 good curve25519-sha256 good curve25519-sha256@libssh.org bad sntrup761x25519-sha512 bad sntrup761x25519-sha512@openssh.com The sha1 ones were not supported on the server side, so no surprise there. Looks like all the nistp384 and sha512 all fail. At least that leaves me with a viable workaround again... live well, vagrant