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. For more details on the protocol extension behind UpdateHostkeys, please see https://github.com/openssh/openssh-portable/blob/396d32f3/PROTOCOL#L286 Otherwise, feel free to ask me anything. Thanks, Damien Miller
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
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
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
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
On 2020-10-03, Damien Miller <djm at 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 at mips.inka.de
On Wed, 7 Oct 2020, Christian Weisgerber wrote:> On 2020-10-03, Damien Miller <djm at 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; }