Mailing List Archive

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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting. [ In reply to ]
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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting. [ In reply to ]
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@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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting. [ In reply to ]
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@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting. [ In reply to ]
Well, SSHFP is supposed to only be used on DNSSEC-enabled domains.

On Sat, Feb 23, 2019 at 9:59 PM Peter Stuge <peter@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@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting. [ In reply to ]
Yegor Ievlev wrote:
> > I think it's a very bad idea to have the client start treating foreign
> > network input as equivalent to local configuration.
>
> Well, SSHFP is supposed to only be used on DNSSEC-enabled domains.

To the client it's still foreign input, even though it's signed by
(best case) the remote site DNS administrator.


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting. [ In reply to ]
Well, known_hosts isn't exactly trusted input, since it's usually
composed of the keys you first encounter, without any additional
checking, as opposed to (hopefully) correctly signed SSHFP records.

On Sat, Feb 23, 2019 at 10:22 PM Peter Stuge <peter@stuge.se> wrote:
>
> Yegor Ievlev wrote:
> > > I think it's a very bad idea to have the client start treating foreign
> > > network input as equivalent to local configuration.
> >
> > Well, SSHFP is supposed to only be used on DNSSEC-enabled domains.
>
> To the client it's still foreign input, even though it's signed by
> (best case) the remote site DNS administrator.
>
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting. [ In reply to ]
On Sat, 23 Feb 2019, Yegor Ievlev wrote:

> 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.

No, that would also be a misconfiguration. If your SSHFP keys don't
match your hostkeys then you're doing it wrong.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting. [ In reply to ]
Ok, thanks for the clarification.

On Sun, Feb 24, 2019 at 2:23 AM Damien Miller <djm@mindrot.org> wrote:
>
> On Sat, 23 Feb 2019, Yegor Ievlev wrote:
>
> > 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.
>
> No, that would also be a misconfiguration. If your SSHFP keys don't
> match your hostkeys then you're doing it wrong.
>
> -d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting. [ In reply to ]
On Sat, 2019-02-23 at 22:23 +0300, Yegor Ievlev wrote:
> Well, known_hosts isn't exactly trusted input, since it's usually
> composed of the keys you first encounter
If someone accepts keys without checking them, he cannot be helped.


> without any additional
> checking, as opposed to (hopefully) correctly signed SSHFP records.
In fact, SSHFP is far less trustworthy, than properly exchanged host
keys (respectively fingerprints).

Anyone in the tree of the DNS down to the domain with your SSHFP RR has
the potential power to forge such RR.


C.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting. [ In reply to ]
Well, the most likely entity who can do that is your registrar, since
it can change your nameservers and DS records.

On Mon, Feb 25, 2019 at 3:51 AM Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
>
> On Sat, 2019-02-23 at 22:23 +0300, Yegor Ievlev wrote:
> > Well, known_hosts isn't exactly trusted input, since it's usually
> > composed of the keys you first encounter
> If someone accepts keys without checking them, he cannot be helped.
>
>
> > without any additional
> > checking, as opposed to (hopefully) correctly signed SSHFP records.
> In fact, SSHFP is far less trustworthy, than properly exchanged host
> keys (respectively fingerprints).
>
> Anyone in the tree of the DNS down to the domain with your SSHFP RR has
> the potential power to forge such RR.
>
>
> C.
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting. [ In reply to ]
On Mon, 2019-02-25 at 04:18 +0300, Yegor Ievlev wrote:
> Well, the most likely entity who can do that is your registrar, since
> it can change your nameservers and DS records.

Or the registry, the IANA, respectively any authority in between which
controls a DNS zone.


Also, the typical way one communicates "securely" with the registrar,
is via TLS, which is because of the certificate model inherently
broken.
Mozilla, e.g. ships around 150 root CAs, many of whom are known to be
not trustworthy... with probably thousands of intermediate CAs, all
which can basically issue anything.

SSHFP is IMO mostly interesting for organisations which maintain their
own secure DNS resolvers (i.e. with their signing keys being configured
as trust anchors).
But even then you have probably different security properties than with
normal SSH keys that were directly exchanged via some trusted path
(namely the single point of failure).

Cheers,
Chris.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possible bug: SSH doesn't prefer host keys listed in SSHFP records while connecting. [ In reply to ]
Hi,

On Mon, Feb 25, 2019 at 01:51:16AM +0100, Christoph Anton Mitterer wrote:
> Anyone in the tree of the DNS down to the domain with your SSHFP RR has
> the potential power to forge such RR.

This is why you only trust SSHFPs if they are DNSSEC validated.

(Of course the sysadmin who maintains your SSHFP zone entries needs to
be trusted, so you do not want to do this for zones hosted elsewhere)

gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany gert@greenie.muc.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev