I’m pretty sure it’s missing this fix: https://github.com/openbsd/src/commit/6a4f4207fb405f62e4d0a78a02d8cc86df7f80fb -m Damien Miller <djm@xxxxxxxxxxx> schrieb am So. 12. Jan. 2020 um 02:02: > On Sat, 11 Jan 2020, Matthieu Herrb wrote: > > > Hi, > > > > It seems that some versions of ssh-agent get confused by ECDSA-SK > > keys. > > > > From my OpenBSD-current laptop, I'm trying to do remote system > > adminstration on a machine running Debian 8 with > > the stock ssh package (OpenSSH_6.7p1 Debian-5+deb8u8, OpenSSL 1.0.2l > > 25 May 2017). I need access to a remote gitlab server to fetch files > > with git, using an ED25519 key in my ssh-agent. > > > > Once connected to the intermediate host, ssh-add -l doesn't see the > > ED25519 key anymore. It says > > > > ssh-add -l > > 2048 a0:80:0a:59:fe:5a:d9:f3:b1:e7:6c:57:32:8c:5c:e5 > /home/matthieu/.ssh/id_rsa (RSA) > > key_from_blob: invalid format > > > > And my ED25519 key I use to authenticate against the gitlab server is > > missing. Thus tring to connect to it fails. > > > > If I remove the ECDSA-SK key from the agent before connecting to the > > debian host, things work again. > > > > Is this an oversight when the ECDSA-SK key type was added, or is it an > > ancient bug in OpenSSH 6.7's agent implementation wrt unknown key > > types that cannot be fixed ? (other than by updating SSH on the debian > > host) > > It's probably(*) the OpenSSH 6.7 implementation's fault for not > understanding the new ECDSA-SK key type, but I'm not 100% sure the > underlying bug(s) of the tools freaking out when they see an unknown > key type are all fixed - we did fix a bunch of these as part of general > refactorings, but it's possible there are some that we missed. > > For the particular case of ssh seeing an unknown key type returned from > an agent, I think the recent versions do the right thing: > https://github.com/openssh/openssh-portable/blob/master/authfd.c#L297 > > -d > > (*) I think some desktop environments have ssh-agent implementations that > lag OpenSSH's to varying degress. IMO these are a constant source of > hassle. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev@xxxxxxxxxxx > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
