Mailing List Archive

On Sat, 2020-10-03 at 19:44 +1000, Damien Miller wrote:
> Otherwise, feel free to ask me anything.

Was it ever considered that the feature itself could be problematic,
security-wise?

I see at least two candidates:
- It's IMO generally a bad idea to distribute "better/newer" keys over
a potentially already weaker trust path (i.e. something secured by the
old key).
- If some key was compromised (and thus the server itself) an attacker
might use the feature to distribute his own keys, which, during clean
up from the attack, might be overseen.


Cheers,Chris

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 4 Oct 2020, Christoph Anton Mitterer wrote:

> On Sat, 2020-10-03 at 19:44 +1000, Damien Miller wrote:
> > Otherwise, feel free to ask me anything.
>
> Was it ever considered that the feature itself could be problematic,
> security-wise?

Of course we considered this.

> I see at least two candidates:
> - It's IMO generally a bad idea to distribute "better/newer" keys over
> a potentially already weaker trust path (i.e. something secured by the
> old key).

This is strictly no worse than continuing to use the old key, so I don't
consider it a problem.

> - If some key was compromised (and thus the server itself) an attacker
> might use the feature to distribute his own keys, which, during clean
> up from the attack, might be overseen.

How is this different to the status quo? If you don't clean up keys after
a compromise then you have a problem. Anyone doing this already has to
be prepared to deal with multiple keys being known for a host. The tooling
support for doing this (ssh-keygen -R) works identically regardless of
the number of keys.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 2020-10-04 at 14:02 +1100, Damien Miller wrote:
> This is strictly no worse than continuing to use the old key, so I
> don't
> consider it a problem.

Well but in reality it will lead to people never again replace their
key by proper means.


> How is this different to the status quo? If you don't clean up keys
> after
> a compromise then you have a problem. Anyone doing this already has
> to
> be prepared to deal with multiple keys being known for a host. The
> tooling
> support for doing this (ssh-keygen -R) works identically regardless
> of
> the number of keys.

Well the big difference is IMO:
AFIAU this feature distributes the newer server keys to clients right?

So even if the compromise is detected on the server side (and properly
cleaned up) the may be countless of clients (which you can never reach
all) who still have the compromised keys and may subsequently be
vulnerable to MitM, since they'd still trust that the key authenticates
server foo.bar.

Same scenario obviously if the compromise is never detected but just
used to get keys for MitM servers to clients... and afterwards removing
any trace/backdoor from the server.


Cheers,
Chris.

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 4 Oct 2020 at 14:38, Christoph Anton Mitterer
<calestyo@scientia.net> wrote:
[...]
> So even if the compromise is detected on the server side (and properly
> cleaned up) the may be countless of clients (which you can never reach
> all) who still have the compromised keys and may subsequently be
> vulnerable to MitM, since they'd still trust that the key authenticates
> server foo.bar.

How is that scenario any different from the attacker keeping a copy of
the compromised server's private keys, other than causing more
evidence to be created when the attacker's keys get sent out?

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 4 Oct 2020, Christoph Anton Mitterer wrote:

> On Sun, 2020-10-04 at 14:02 +1100, Damien Miller wrote:
> > This is strictly no worse than continuing to use the old key, so I
> > don't consider it a problem.
>
> Well but in reality it will lead to people never again replace their
> key by proper means.

Well, first I disagree that this method is improper. The existence of
UpdateHostkeys doesn't stop people hard-rotating their keys if that's
what they prefer.

> > How is this different to the status quo? If you don't clean up
> > keys after a compromise then you have a problem. Anyone doing this
> > already has to be prepared to deal with multiple keys being known
> > for a host. The tooling support for doing this (ssh-keygen -R) works
> > identically regardless of the number of keys.
>
> Well the big difference is IMO: AFIAU this feature distributes the
> newer server keys to clients right?
>
> So even if the compromise is detected on the server side (and
> properly cleaned up) the may be countless of clients (which you
> can never reach all) who still have the compromised keys and may
> subsequently be vulnerable to MitM, since they'd still trust that the
> key authenticates server foo.bar.

Again, how is this different to the status quo? If a server has been
compromised then its host key(s) should be considered compromised too
and should be cleaned up. This is true regardless of the existence of
UpdateHostkeys.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Hi Damien,

UpdateHostkeys is an interesting feature. I hope you plan to document it
somewhat better in the ssh_config.5 file than is currently present?

My reading of the documentation is that it is ambiguous as to the
following:

if StrictHostKeyChecking=yes and UpdateHostkeys=yes
which option wins?

(My vote is that StrictHostKeyChecking=yes wins every time.)

If the hostkey that matches is found in GlobalKnownHostsFile, then I
hope that the UpdateHostKeys is NOT used to update the
UserKnownHostsFile ...

My vote is to assume that the GlobalKnownHostsFile is being properly
managed and maintained for the listed hosts and UpdateHostKeys would
be ignored in this case.

I am unclear what happens with UpdateHostKeys when the key is found
via DNS SSHFP and the use of VerifyHostKeyDNS settings.

My vote is that if the key is found in DNS SSHFP records, the
UpdateHostKeys does NOT get used to add to the UserKnownHostsFile.

How do CheckHostIP=yes and UpdateHostKeys play together?
It is not clear to me if the HostIP fingerprints AND the Hostname
fingerprint recards are BOTH to be added via the UpdateHostKeys
directive or not.

I believe it would be wise to be explicit with regards to these impacts
to the UpdateHostKeys option as described in the man page.

Thank you for your considerating of these questions.

Be safe, stay healthy,
-- Mark
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sat, Oct 03, 2020 at 07:44:08PM +1000, Damien Miller wrote:
> Hi,
>
> I just fixed a couple of corner-cases relating to UpdateHostkeys in git
> HEAD and have enabled the option by default. IMO this protocol extension
> is important because it allows ssh clients to automatically migrate to
> the best available signature algorithms available on the server and
> supports our goal of deprecating RSA/SHA1 in the future.
>
> We would really appreciate your feedback on this feature if you are able
> to run git HEAD on non-production systems - we try our best to keep
> OpenSSH stable and usable through the development cycle (really, we try
> to keep it ready for release at any time). IMO it is quite suitable to
> use as a daily driver on one's laptop. To test this feature, you really
> only need run the ssh client.
>

Hi,

on OpenBSD-current I now get this when connecting to an existing
machine for which I have both ecdsa an ed25519 keys in my existing
known_hosts (but apparently ed25519 keys where added only for the name
previsously by ssh):

Warning: the ED25519 host key for 'freedom' differs from the key for
the IP address '2a03:7220:8081:6101:6552:9ca8:512b:9251'
Offending key for IP in /home/matthieu/.ssh/known_hosts:53
Matching host key in /home/matthieu/.ssh/known_hosts:131
Are you sure you want to continue connecting (yes/no)?

line 53 is the ecdsa key for the given address, 131 is the ed25519 key
for the name. None of the name or the IP address for freedom changed
(and the behaviour is the same with IPv4)

If I answer 'yes' the known_hosts file is not updated. I have to
remove the ecdsa key manually to have the ed25519 key for the IP
address added automatically.

ie :

% ssh-keygen -R '2a03:7220:8081:6101:6552:9ca8:512b:9251'
# Host 2a03:7220:8081:6101:6552:9ca8:512b:9251 found: line 53
/home/matthieu/.ssh/known_hosts updated.
Original contents retained as /home/matthieu/.ssh/known_hosts.old
% ssh freedom
Warning: Permanently added the ED25519 host key for IP address
'2a03:7220:8081:6101:6552:9ca8:512b:9251' to the list of known hosts.


I find this quite disturbing (and it breaks some non interactive
scripts). Is it the intended behaviour ?

--
Matthieu Herrb
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 4 Oct 2020, Matthieu Herrb wrote:

> Hi,
>
> on OpenBSD-current I now get this when connecting to an existing
> machine for which I have both ecdsa an ed25519 keys in my existing
> known_hosts (but apparently ed25519 keys where added only for the name
> previsously by ssh):
>
> Warning: the ED25519 host key for 'freedom' differs from the key for
> the IP address '2a03:7220:8081:6101:6552:9ca8:512b:9251'
> Offending key for IP in /home/matthieu/.ssh/known_hosts:53
> Matching host key in /home/matthieu/.ssh/known_hosts:131
> Are you sure you want to continue connecting (yes/no)?
>
> line 53 is the ecdsa key for the given address, 131 is the ed25519 key
> for the name. None of the name or the IP address for freedom changed
> (and the behaviour is the same with IPv4)
>
> If I answer 'yes' the known_hosts file is not updated. I have to
> remove the ecdsa key manually to have the ed25519 key for the IP
> address added automatically.
>
> ie :
>
> % ssh-keygen -R '2a03:7220:8081:6101:6552:9ca8:512b:9251'
> # Host 2a03:7220:8081:6101:6552:9ca8:512b:9251 found: line 53
> /home/matthieu/.ssh/known_hosts updated.
> Original contents retained as /home/matthieu/.ssh/known_hosts.old
> % ssh freedom
> Warning: Permanently added the ED25519 host key for IP address
> '2a03:7220:8081:6101:6552:9ca8:512b:9251' to the list of known hosts.
>
>
> I find this quite disturbing (and it breaks some non interactive
> scripts). Is it the intended behaviour ?

No - I think you've stumbled on a corner case I hadn't anticipated.
Does your configuration override CheckHostIP at all?

What are the known_hosts entries for the hostname and IP?

Thanks,
Damien
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 4 Oct 2020, Damien Miller wrote:

> No - I think you've stumbled on a corner case I hadn't anticipated.
> Does your configuration override CheckHostIP at all?
>
> What are the known_hosts entries for the hostname and IP?

Also, do you use HashKnownHosts? or do you have any hashed host lines
in known_hosts?

I'll try to figure this out tomorrow morning...

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, Oct 04, 2020 at 09:24:12PM +1100, Damien Miller wrote:
> On Sun, 4 Oct 2020, Damien Miller wrote:
>
> > No - I think you've stumbled on a corner case I hadn't anticipated.
> > Does your configuration override CheckHostIP at all?

No.

> >
> > What are the known_hosts entries for the hostname and IP?
>
> Also, do you use HashKnownHosts? or do you have any hashed host lines
> in known_hosts?

Yes I use HashKnownHosts yes

Here are all the lines from my known_hosts.old that contains the
public keys for this host.

(the name is 'freedom' or freedom.herrb.net and IP adresses are
192.168.31.41 and 2a03:7220:8081:6101:6552:9ca8:512b:9251)

|1|LDNls9zwwKUtszPxTWOn1hEP+30=|2C9Jva6DwfnWqEHHjylVV9gAfSs= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBF2yT8wIR716QLjlhgLO3XGvFB7QHxguK2UXaFoVFEgQwRHpi5aLRjT3eENZNYHDUj/Nr4wFWDrOW1whtU+CxkM=
|1|zjuSnQb3afgDzZBCywXwNiZHYuY=|fUpd/QMtdR1dwYwfDUMM1xKIhqA= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBF2yT8wIR716QLjlhgLO3XGvFB7QHxguK2UXaFoVFEgQwRHpi5aLRjT3eENZNYHDUj/Nr4wFWDrOW1whtU+CxkM=
|1|IfXYEUvy166GATD/1980t6hR9CM=|UsUUsCnt3m0WH1X0N6sX/8tl/k8= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBF2yT8wIR716QLjlhgLO3XGvFB7QHxguK2UXaFoVFEgQwRHpi5aLRjT3eENZNYHDUj/Nr4wFWDrOW1whtU+CxkM=
|1|tOtsqSGnI+Of4l4toTHgAKKeZpI=|pWNu4KHsqq4z49vhuovYNJVE2o4= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBF2yT8wIR716QLjlhgLO3XGvFB7QHxguK2UXaFoVFEgQwRHpi5aLRjT3eENZNYHDUj/Nr4wFWDrOW1whtU+CxkM=
|1|LDNls9zwwKUtszPxTWOn1hEP+30=|2C9Jva6DwfnWqEHHjylVV9gAfSs= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBF2yT8wIR716QLjlhgLO3XGvFB7QHxguK2UXaFoVFEgQwRHpi5aLRjT3eENZNYHDUj/Nr4wFWDrOW1whtU+CxkM=
|1|IQQcAaveFbGQNoBJdsCJAtoqKSE=|xJvFONAHNU3U2as+cdtNeP2r1es= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFpmvj21EjLwEzHAlI8WWhZqT42g0mdpqfo/vFbN0FMG


--
Matthieu Herrb
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 4 Oct 2020, Matthieu Herrb wrote:

> On Sun, Oct 04, 2020 at 09:24:12PM +1100, Damien Miller wrote:
> > On Sun, 4 Oct 2020, Damien Miller wrote:
> >
> > > No - I think you've stumbled on a corner case I hadn't anticipated.
> > > Does your configuration override CheckHostIP at all?
>
> No.
>
> > >
> > > What are the known_hosts entries for the hostname and IP?
> >
> > Also, do you use HashKnownHosts? or do you have any hashed host lines
> > in known_hosts?
>
> Yes I use HashKnownHosts yes

Thanks - I think that was the missing piece of the puzzle. Can you
please try this diff? It lets UpdateKnownHosts store entries for
the IP address as well as the hostname.

diff --git a/hostfile.c b/hostfile.c
index 3dc9809..9ec9afa 100644
--- a/hostfile.c
+++ b/hostfile.c
@@ -449,6 +449,9 @@ write_host_entry(FILE *f, const char *host, const char *ip,
else
error("%s: sshkey_write failed: %s", __func__, ssh_err(r));
fputc('\n', f);
+ /* If hashing is enabled, the IP address needs to go on its own line */
+ if (success && store_hash && ip != NULL)
+ success = write_host_entry(f, ip, NULL, key, 1);
return success;
}

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sat, 3 Oct 2020, Mark D. Baushke wrote:

> Hi Damien,
>
> UpdateHostkeys is an interesting feature. I hope you plan to document it
> somewhat better in the ssh_config.5 file than is currently present?
>
> My reading of the documentation is that it is ambiguous as to the
> following:
>
> if StrictHostKeyChecking=yes and UpdateHostkeys=yes
> which option wins?
>
> (My vote is that StrictHostKeyChecking=yes wins every time.)

They are almost completely separate:

StrictHostKeyChecking controls the circumstances under which a hostkey
is accepted.

UpdateHostkeys controls whether to try to learn additional hostkeys
for a host with an already trusted host key.

The small point of interaction is when StrictHostKeyChecking=no and
the user elects to continue past a changed hostkey. I'll double-check
to make sure that UpdateHostkeys gets turned off along the other options
that are disabled in this case.

> If the hostkey that matches is found in GlobalKnownHostsFile, then I
> hope that the UpdateHostKeys is NOT used to update the
> UserKnownHostsFile ...
>
> My vote is to assume that the GlobalKnownHostsFile is being properly
> managed and maintained for the listed hosts and UpdateHostKeys would
> be ignored in this case.

Good point. I'll implement this.

> I am unclear what happens with UpdateHostKeys when the key is found
> via DNS SSHFP and the use of VerifyHostKeyDNS settings.
>
> My vote is that if the key is found in DNS SSHFP records, the
> UpdateHostKeys does NOT get used to add to the UserKnownHostsFile.

Another good point. I'll do this too :)

> How do CheckHostIP=yes and UpdateHostKeys play together?
> It is not clear to me if the HostIP fingerprints AND the Hostname
> fingerprint recards are BOTH to be added via the UpdateHostKeys
> directive or not.

They should play just fine (modulo bugs like the one Matthieu reported).
Keys learned by UpdateHostKeys should behave exactly like ones learned
by TOFU with respect to CheckHostIP and HashKnownHosts.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Damien Miller <djm@mindrot.org> writes:

> On Sat, 3 Oct 2020, Mark D. Baushke wrote:
>
> > UpdateHostkeys is an interesting feature. I hope you plan to document it
> > somewhat better in the ssh_config.5 file than is currently present?
> >
> > My reading of the documentation is that it is ambiguous as to the
> > following:
> >
> > if StrictHostKeyChecking=yes and UpdateHostkeys=yes
> > which option wins?
> >
> > (My vote is that StrictHostKeyChecking=yes wins every time.)
>
> They are almost completely separate:
>
> StrictHostKeyChecking controls the circumstances under which a hostkey
> is accepted.
>
> UpdateHostkeys controls whether to try to learn additional hostkeys
> for a host with an already trusted host key.
>
> The small point of interaction is when StrictHostKeyChecking=no and
> the user elects to continue past a changed hostkey. I'll double-check
> to make sure that UpdateHostkeys gets turned off along the other options
> that are disabled in this case.

Okay. I do think that the man page should be updated to tell the user
how these switches interact.

> > If the hostkey that matches is found in GlobalKnownHostsFile, then I
> > hope that the UpdateHostKeys is NOT used to update the
> > UserKnownHostsFile ...
> >
> > My vote is to assume that the GlobalKnownHostsFile is being properly
> > managed and maintained for the listed hosts and UpdateHostKeys would
> > be ignored in this case.
>
> Good point. I'll implement this.

Thank you very much.

> > I am unclear what happens with UpdateHostKeys when the key is found
> > via DNS SSHFP and the use of VerifyHostKeyDNS settings.
> >
> > My vote is that if the key is found in DNS SSHFP records, the
> > UpdateHostKeys does NOT get used to add to the UserKnownHostsFile.
>
> Another good point. I'll do this too :)

Thank you very much.

> > How do CheckHostIP=yes and UpdateHostKeys play together?
> > It is not clear to me if the HostIP fingerprints AND the Hostname
> > fingerprint recards are BOTH to be added via the UpdateHostKeys
> > directive or not.
>
> They should play just fine (modulo bugs like the one Matthieu reported).
> Keys learned by UpdateHostKeys should behave exactly like ones learned
> by TOFU with respect to CheckHostIP and HashKnownHosts.

Yes. I had not cosidered how HashKnownHosts would work or what happens
with both IPv4 and IPv6 hostnames.

There may be one additional edge condition, when the host is actually a
bastian host that has an internal NAT'ed IP address and an external IP
address. Things like that get tricky when CheckHostIP=yes and an
UpdateHostKeys may only update the currently visible IP address even
though the user has previously added the old key for both IP addresses
manually. I still need to think about how that one should work.

Of course, there is another edge case I run into which is where the
hostname is using DynDNS with a dynamic IP address where I would rather
it NOT record the IP address for a particular subdomain of hosts or need
to explicity override config optios on the command-line.

Be safe, stay healthy,
-- Mark
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, Oct 04, 2020 at 10:50:32PM +1100, Damien Miller wrote:
> On Sun, 4 Oct 2020, Matthieu Herrb wrote:
>
> > On Sun, Oct 04, 2020 at 09:24:12PM +1100, Damien Miller wrote:
> > > On Sun, 4 Oct 2020, Damien Miller wrote:
> > >
> > > > No - I think you've stumbled on a corner case I hadn't anticipated.
> > > > Does your configuration override CheckHostIP at all?
> >
> > No.
> >
> > > >
> > > > What are the known_hosts entries for the hostname and IP?
> > >
> > > Also, do you use HashKnownHosts? or do you have any hashed host lines
> > > in known_hosts?
> >
> > Yes I use HashKnownHosts yes
>
> Thanks - I think that was the missing piece of the puzzle. Can you
> please try this diff? It lets UpdateKnownHosts store entries for
> the IP address as well as the hostname.
>
> diff --git a/hostfile.c b/hostfile.c
> index 3dc9809..9ec9afa 100644
> --- a/hostfile.c
> +++ b/hostfile.c
> @@ -449,6 +449,9 @@ write_host_entry(FILE *f, const char *host, const char *ip,
> else
> error("%s: sshkey_write failed: %s", __func__, ssh_err(r));
> fputc('\n', f);
> + /* If hashing is enabled, the IP address needs to go on its own line */
> + if (success && store_hash && ip != NULL)
> + success = write_host_entry(f, ip, NULL, key, 1);
> return success;
> }
>

thanks for the patch, unfortunatly it doesn't solve the issue. ssh is
still claiming that the ecdsa key present in known_hosts differs from
the ed25519 key.
And if I answer yes to the question known_hosts is not updated.

The way to fix this is still to remove the ecdsa key from
known_hosts manually.

--
Matthieu Herrb
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, Oct 04, 2020 at 06:41:05PM +0200, Matthieu Herrb wrote:
>
> thanks for the patch, unfortunatly it doesn't solve the issue. ssh is
> still claiming that the ecdsa key present in known_hosts differs from
> the ed25519 key.
> And if I answer yes to the question known_hosts is not updated.
>
> The way to fix this is still to remove the ecdsa key from
> known_hosts manually.
>

more data points. I started experimenting with
'-o UserKnownHostsFile freedom' -o 'UpdateHostKeys ask'

where 'freedom' is a minimal known_hosts files

(with your patch applied, and hashed names / IP addresses):

If only ecdsa keys are in freedom :

- if both the lines for the hashed IP address and name are there, ssh
connects and asks to add updated keys. It adds existing rsa (?) and
ed25519 keys for both the hashed name and the IP.

- if only the line for the hashed name is there, ssh adds the line
with the hashed address and ecdsa key and then asks as above.

- if only the line for the hashed IP address is there, ssh claims that
the identity can't be established and shows me the fingerprint of
the ed25519 key.


if only ed2519 keys are there :

- if both lines key for the hashed IP address and name are there, ssh
connects.

- if only the line for the name is there, ssh connects and adds a line
with the hash the IP address (v4 or v6) and the ed25519 key

- if only the line for the hashed IP address is there, ssh claims that
the identity can't be established and shows me the fingerprint of
the ed25519 key (that is in the known host with the hash of IP)

If like in my original situation I have ecdsa keys for hashed hostname
and IP but only the ed25519 key for the hashed host name, then ssh
claims:

Warning: the ED25519 host key for 'freedom' differs from the key for
the IP address '2a03:7220:8081:6101:6552:9ca8:512b:9251'
Offending key for IP in /home/matthieu/.ssh/freedom:4
Matching host key in /home/matthieu/.ssh/freedom:9

line 4 is the line for the ecdsa key with the hashed IP
line 9 is the line for the ed25519 key with the hashed name

--
Matthieu Herrb
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Sun, 4 Oct 2020, Matthieu Herrb wrote:

> thanks for the patch, unfortunatly it doesn't solve the issue. ssh is
> still claiming that the ecdsa key present in known_hosts differs from
> the ed25519 key.
> And if I answer yes to the question known_hosts is not updated.
>
> The way to fix this is still to remove the ecdsa key from
> known_hosts manually.

Please try removing the ssh-ed25519 key from known_hosts (leaving just
the ECDSA lines for name and IP) and try connecting with my patch. IMO
the problem is that unpatched ssh forgot to write a known_hosts entry
for the host's IP address and left your known_hosts in an inconsistent
state.

If that fails then please send a debug trace from ssh ("ssh -vvv ...")

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, Oct 05, 2020 at 10:18:07AM +1100, Damien Miller wrote:
> On Sun, 4 Oct 2020, Matthieu Herrb wrote:
>
> > thanks for the patch, unfortunatly it doesn't solve the issue. ssh is
> > still claiming that the ecdsa key present in known_hosts differs from
> > the ed25519 key.
> > And if I answer yes to the question known_hosts is not updated.
> >
> > The way to fix this is still to remove the ecdsa key from
> > known_hosts manually.
>
> Please try removing the ssh-ed25519 key from known_hosts (leaving just
> the ECDSA lines for name and IP) and try connecting with my patch. IMO
> the problem is that unpatched ssh forgot to write a known_hosts entry
> for the host's IP address and left your known_hosts in an inconsistent
> state.
>
> If that fails then please send a debug trace from ssh ("ssh -vvv
> ...")

Yes that works as expected in my tests. Thanks.

The problem is more that, in the default config, ssh is now refusing
to connect when in addition to ecdsa keys there is alreadry an ED25519
key for the hashed host name, but no hash IP entry. The bare 8.4 ssh
(from OpenBSD september 29 snapshot) does connect without asking in
that situation.

--
Matthieu Herrb
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Mon, 5 Oct 2020, Matthieu Herrb wrote:

> > If that fails then please send a debug trace from ssh ("ssh -vvv
> > ...")
>
> Yes that works as expected in my tests. Thanks.
>
> The problem is more that, in the default config, ssh is now refusing
> to connect when in addition to ecdsa keys there is alreadry an ED25519
> key for the hashed host name, but no hash IP entry. The bare 8.4 ssh
> (from OpenBSD september 29 snapshot) does connect without asking in
> that situation.

I think it is because I just changed the prefer hostkey algorithm from
ECDSA to ED25519 and not because of the UpdateHostkeys.

Maybe CheckHostIP should be relaxed to not consider IP address lines in
known_hosts when the key type there is a lower priority algorithm than
the selected hostkey type. I need to think about it.

-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Damien Miller wrote:
> > Was it ever considered that the feature itself could be problematic,
> > security-wise?
>
> Of course we considered this.

I'm intuitively opposed to fully automating this.


> > I see at least two candidates:
> > - It's IMO generally a bad idea to distribute "better/newer" keys over
> > a potentially already weaker trust path (i.e. something secured by the
> > old key).
>
> This is strictly no worse than continuing to use the old key, so I don't
> consider it a problem.

I disagree. The problem is not with the crypto; I agree that if just
looking at keys without context then a pushed key is no worse than
the key which authenticated the push.

However! Those pushed keys were pushed for some reason, but only the
server knows why; the client can't *know* that reason without some OOB
communication, so must simply /assume/ that the new key is better/preferable.
I consider that dangerous, because it's an assumption and because we
are trained to make this particular assumption too often already.

Also, I believe that this is the first time that servers are given the
power to remotely manipulate client configuration? I consider that
dangerous as well.

Finally, it's a paradigm shift in host key management on clients, away
from Trust-On-First-Use. This isn't dangerous per se, but I do consider
it quite a drastic change, not to be made lightly at all.


I do not disagree with progressive key management, we clearly need to
roll keys now and then, and I'm also not against some automation, but
I don't think that it should be fully automated.

I even find opt-in too aggressive. I would like this to only occur on
explicit client request.

Host keys are quite stable and I think that's a good thing.


> > - If some key was compromised (and thus the server itself) an attacker
> > might use the feature to distribute his own keys, which, during clean
> > up from the attack, might be overseen.
>
> How is this different to the status quo? If you don't clean up keys after
> a compromise then you have a problem.

It's different because enabling this feature by default lets a
malicious server distribute many different keys to every connecting
client.

I think cleaning up such a mess on clients is significantly different
from cleaning up a single well-known and compromised key, even if
tooling exists to make both tasks appear identical.


//Peter
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On 2020-10-03, Damien Miller <djm@mindrot.org> wrote:

> I just fixed a couple of corner-cases relating to UpdateHostkeys in git
> HEAD and have enabled the option by default.

I'm struggling to understand under which conditions this adds/changes
entries in ~/.ssh/known_hosts.

So far it always fails with "wildcard known hosts name found,
skipping UserKnownHostsFile update".

I don't have any wildcard entries in known_hosts. I _do_ have a
number of entries with multiple addresses like this:

partoc,fddd:28ee:243::4,172.16.0.4

So it skips those. But it also skips very basic entries like

amd64.ports.openbsd.org,199.185.231.80

--
Christian "naddy" Weisgerber naddy@mips.inka.de
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

On Wed, 7 Oct 2020, Christian Weisgerber wrote:

> On 2020-10-03, Damien Miller <djm@mindrot.org> wrote:
>
> > I just fixed a couple of corner-cases relating to UpdateHostkeys in git
> > HEAD and have enabled the option by default.
>
> I'm struggling to understand under which conditions this adds/changes
> entries in ~/.ssh/known_hosts.
>
> So far it always fails with "wildcard known hosts name found,
> skipping UserKnownHostsFile update".

ah, that's a bug

diff --git a/clientloop.c b/clientloop.c
index 0b27991..8d21b20 100644
--- a/clientloop.c
+++ b/clientloop.c
@@ -1858,9 +1858,9 @@ hostkeys_find(struct hostkey_foreach_line *l, void *_ctx)

/* UpdateHostkeys is skipped for wildcard host names */
if (strchr(l->hosts, '*') != NULL ||
- strchr(l->hosts, ',') != NULL) {
- debug3("%s: hostkeys file %s:%ld contains wildcard or pattern",
- __func__, l->path, l->linenum);
+ strchr(l->hosts, '?') != NULL) {
+ debug3("%s: hostkeys file %s:%ld contains wildcard", __func__,
+ l->path, l->linenum);
ctx->wildcard_hostspec = 1;
}

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev