openssh unix dev - Feb 2019 - Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting.

Steps to reproduce:
1. Run a SSH server with default configuration and point a domain to it.
2. Add SSHFP record to the domain, but only for Ed25519 key.
3. Attempt to connect with VerifyHostKeyDNS set to yes, but the rest
of settings set to defaults.
4. OpenSSH defaults to ECDSA instead of Ed25519 and refuses connection
because there is no ECDSA fingerprint in SSHFP records.

A stopgap solution is to either delete all keys except Ed25519 from
the server or to always connect with HostKeyAlgorithms set to
ssh-ed25519. It would make more sense to treat SSHFP records in the
same way as known_hosts, e.g. if known_hosts already has a Ed25519
key, try to fetch a Ed25519 key instead of defaulting to ECDSA.

On Fri, 22 Feb 2019, Yegor Ievlev wrote:
> Steps to reproduce:
> 1. Run a SSH server with default configuration and point a domain to it.
> 2. Add SSHFP record to the domain, but only for Ed25519 key.
> 3. Attempt to connect with VerifyHostKeyDNS set to yes, but the rest
> of settings set to defaults.
> 4. OpenSSH defaults to ECDSA instead of Ed25519 and refuses connection
> because there is no ECDSA fingerprint in SSHFP records.
I'm not seeing the bug: typically you'd add SSHFP records for all
the server's hostkeys, but you've not done this.

-d

The reason why this is a bug is, for example, that if the server was
updated and it re-generated the ECDSA key you deleted, you would have
to do some non-obvious steps for your client to ignore it.

On Sat, Feb 23, 2019 at 11:49 AM Damien Miller <djm at mindrot.org>
wrote:
>
> On Fri, 22 Feb 2019, Yegor Ievlev wrote:
>
> > Steps to reproduce:
> > 1. Run a SSH server with default configuration and point a domain to
it.
> > 2. Add SSHFP record to the domain, but only for Ed25519 key.
> > 3. Attempt to connect with VerifyHostKeyDNS set to yes, but the rest
> > of settings set to defaults.
> > 4. OpenSSH defaults to ECDSA instead of Ed25519 and refuses connection
> > because there is no ECDSA fingerprint in SSHFP records.
>
> I'm not seeing the bug: typically you'd add SSHFP records for all
> the server's hostkeys, but you've not done this.
>
> -d

Yegor Ievlev wrote:
> It would make more sense to treat SSHFP records in the same way as
> known_hosts
I disagree with that - known_hosts is nominally a client-local configuration.

I think it's a very bad idea to have the client start treating foreign
network
input as equivalent to local configuration.


//Peter

Well, SSHFP is supposed to only be used on DNSSEC-enabled domains.

On Sat, Feb 23, 2019 at 9:59 PM Peter Stuge <peter at stuge.se>
wrote:
>
> Yegor Ievlev wrote:
> > It would make more sense to treat SSHFP records in the same way as
> > known_hosts
>
> I disagree with that - known_hosts is nominally a client-local
configuration.
>
> I think it's a very bad idea to have the client start treating foreign
network
> input as equivalent to local configuration.
>
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev