Strongly related to openssh 8.9

After upgrading openssh-client to 8.9p1, Yubikey-managed SSH keys
can no longer be used. After downgrading to 1:8.4p1-5, it works.
I believe this is due to recent changes in OpenSSH 8.9 regarding
ssh-agent communication protocol which GnuPG hasn't yet picked up,
but haven't found anything on GnuPG's bug tracker.

$ ssh example.com
sign_and_send_pubkey: signing failed for ED25519 "cardno:XXXXXXXX" from agent: agent refused operation
username@example.com's password:

## See
https://www.openssh.com/agent-restrict.html

## Other reports
https://bugs.archlinux.org/task/74143

## Workaround
I use sid and had to add the stable repo to my sources.list, then
(due to dependencies):

  apt-get install openssh-client=1:8.4p1-5 \
                  openssh-server=1:8.4p1-5 \
                  openssh-sftp-server=1:8.4p1-5

Regards

Same problem with Gnuk, presumably multiple or all smartcards are
affected?

Although I was until today using openssh 8.9 just fine, it wasn't until
the openssh 9.0 upgrade that it stopped working for me...


live well,
  vagrant

According to some folks on irc.oftc.net #debian-devel, not all
smartcards are affected, we're the lucky ones!

I am using a fairly old build of gnuk, maybe newer firmware versions
have been made compatible somehow... ?

For me, downgrading to openssh 1:8.9p1-3 seems to work fine.

I've marked that version of openssh as hold for now, but that feels very
wrong. :/


live well,
  vagrant

Hi,

For anyone who suffers this, the workaround is:

Add `KexAlgorithms=-sntrup761x25519-sha512@openssh.com` to ~/.ssh/config
or `-o KexAlgorithms=-sntrup761x25519-sha512@openssh.com` to the command.

Thanks!  That works for me with openssh-client 1:9.0p1-1 and gpg-agent
2.2.27-3+b1.

Though for clarity, the ~/.ssh/config option is without the '=':

  KexAlgorithms -sntrup761x25519-sha512@openssh.com


live well,
  vagrant

I found an issue of scdaemon.  At upstream development, it is tracked by:

https://dev.gnupg.org/T5935

When the data is not so large (smaller than the buffer size of token),
it works using Gnuk, with the patch of scdaemon.

This bug report was tagged severity "serious"

https://www.debian.org/Bugs/Developer#severities says that severity
level means:

  > is a severe violation of Debian policy (roughly, it violates a
  > "must" or "required" directive), or, in the package maintainer's or
  > release manager's opinion, makes the package unsuitable for release.

I see no justification for that severity level in the discussion, so i'm
changing it to normal.  If you think that's wrong, feel free to reset it
to "serious" with an explicit justification, thanks!

Thanks for tracking this down, gniibe!

If there's a specific patch that we should include in the debian release
of the 2.2 branch, please let me know.  The patch mentioned in
https://dev.gnupg.org/T5935
(https://dev.gnupg.org/rGe8fb8e2b3e66d5ea8a3dc90afdc14611abf2c3da)
doesn't look like it will apply directly to the 2.2 branch.

In the meantime, people with the affected key/hardware combination
should be able to continue using the workaround described by vagrant.

Hi,

I have a Nitrokey Start that has the same problem, but the suggested
workaround was not enough for me. After a few attempts, I discovered
that I need this in my ssh_config file:

KexAlgorithms -sntrup761x25519-sha512@openssh.com
HostKeyAlgorithms -ecdsa-sha2-nistp256

Notice that after this change connections to hosts that previously used
a ecdsa-sha2-nistp256 host key will fail key verification and trigger
the usual scary message about a MITM attack.

Thanks, Giovanni.

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.

[...]

Hello,

The respective patch was backported by gniibe
https://dev.gnupg.org/rG07e43eda8dc69cecc385a6b3723e155afbc59257 and is
part of 2.2.37.

Do you still see the problem (#998728, 1008573, and #1032907)?

cu Andreas

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

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