interoperability issue with agent and ecdsa-sk keys
Damien Miller
djm at mindrot.org
Sun Jan 12 12:01:56 AEDT 2020
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.
More information about the openssh-unix-dev
mailing list