openssh unix dev - Jan 2020 - interoperability issue with agent and ecdsa-sk keys

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)

Thanks for any help / suggestion / bug fixes...
-- 
Matthieu Herrb

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.

I?m pretty sure it?s missing this fix:

https://github.com/openbsd/src/commit/6a4f4207fb405f62e4d0a78a02d8cc86df7f80fb


-m

Damien Miller <djm at mindrot.org> 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 at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>