search for: updatehostkeys

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

I've expressed several concerns with enabling UpdateHostKeys by default, none of which were even commented on, so this topic seems to not be in any way open for discussion, but I'll still add one more thing here. Peter Stuge wrote: > Subject: Re: UpdateHostkeys now enabled by default > Date: Mon, 5 Oct 2020 11:22:29 +0000 .. > I do not disagree...

For the last few releases, there has been a notice that ssh-rsa will be deprecated in a near-future release. Is there a target release for this deprecation to take effect? I saw in the 8.4 release notes that?UpdateHostKeys is going to be default enabled in the next release to prepare for this. Is it likely that 8.6 will deprecate ssh-rsa after a release cycle of UpdateHostKeys being default or are we likely talking further in the future than that? I apologize if this has been asked before and I've missed it. I...

On Wed, 5 Feb 2020, Phil Pennock wrote: > On 2020-02-06 at 10:29 +1100, Damien Miller wrote: > > * sshd(8): allow the UpdateHostKeys feature to function when > > multiple known_hosts files are in use. When updating host keys, > > ssh will now search subsequent known_hosts files, but will add > > updated host keys to the first specified file only. bz2738 > > In testing this, when the impact is to...

https://bugzilla.mindrot.org/show_bug.cgi?id=2894 Bug ID: 2894 Summary: Set UpdateHostKeys for interactive sessions to 'ask' (or consider defaulting to 'yes') Product: Portable OpenSSH Version: 7.7p1 Hardware: Other OS: Other Status: NEW Severity: enhancement Priority: P5...

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2650 Bug ID: 2650 Summary: UpdateHostKeys ignores RSA keys if HostKeyAlgorithms=rsa-sha2-256 Product: Portable OpenSSH Version: 7.4p1 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 Component: ssh Assignee...

https://bugzilla.mindrot.org/show_bug.cgi?id=2738 Bug ID: 2738 Summary: UpdateHostKeys does not check keys in secondary known_hosts files Product: Portable OpenSSH Version: 7.4p1 Hardware: amd64 OS: Linux Status: NEW Severity: minor Priority: P5 Component: ssh Assign...

Compiled OK, and operating nicely on CentOS 6.6, both 32/64 bit. Really appreciate the UpdateHostkeys feature! One issue I noticed, the screen output gets garbled if the user has been "asked" to "Accept" the new hostkeys. Looks like the screen output is missing the CR's, and only LF's get presented. [root at be2 .ssh]# ssh be1 ls -l Warning: Permanently added 'be1,f...

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

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

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

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

...er removing the ssh-rsa algorithm from ssh(1)'s allowed list: ssh -oHostKeyAlgorithms=-ssh-rsa user at host If the host key verification fails and no other supported host key types are available, the server software on that host should be upgraded. A future release of OpenSSH will enable UpdateHostKeys by default to allow the client to automatically migrate to better algorithms. Users may consider enabling this option manually. [1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust" Leurent, G and Peyrin, T (2020) https://eprint...

...er removing the ssh-rsa algorithm from ssh(1)'s allowed list: ssh -oHostKeyAlgorithms=-ssh-rsa user at host If the host key verification fails and no other supported host key types are available, the server software on that host should be upgraded. A future release of OpenSSH will enable UpdateHostKeys by default to allow the client to automatically migrate to better algorithms. Users may consider enabling this option manually. [1] "SHA-1 is a Shambles: First Chosen-Prefix Collision on SHA-1 and Application to the PGP Web of Trust" Leurent, G and Peyrin, T (2020) https://eprint...

...able > > host keys after authentication has completed. The client may > > record the keys in known_hosts, allowing it to upgrade to better > > host key algorithms and a server to gracefully rotate its keys. > > > > The client side of this is controlled by a UpdateHostkeys config > > option (default on). > > Actually, the default is off. You can enable it using UpdateHostKeys=yes > or UpdateHostKeys=ask > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https...

...gt; to verify the hostkey sent This kind of information is host specific, and seems like it could be directly cached instead of re-read. is this the sort of significant changes you're talking about, or is there more that needs doing? > and (optionally) a couple of times to > deal with UpdateHostkeys messages from the server. UpdateHostKeys seems like it's about modifying the stored keys, right? that's a different thing than just reading it. We'd need to specify some sort of interface for sending back updates to the KnownHostsCommand as well, and this isn't something that was...

...ct: Portable OpenSSH Version: 7.3p1 Hardware: amd64 OS: Linux Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org Reporter: lkinley at gmail.com When UpdateHostKeys=yes/ask, only hostname based entries are added to known_hosts file when learning new hostkeys. Shouldn't IP entries also be added? Consider the following scenario: User connects for the first time, specifying a HostKeyAlgorithms setting that is not first in the default list (rsa-sha2-256 in...

...d_config accordingly (adding the line below) and restarted ssh: cd /etc/ssh sudo ssh-keygen -f 2024_ssh_host_ed25519_key -t ed25519 -N '' sudo vi /etc/ssh/sshd_config # added line: HostKey /etc/ssh/2024_ssh_host_ed25519_key sudo service ssh restart When I connect to serverA (`ssh -v -o UpdateHostKeys=yes serverA`) afterwards, known_hosts on the client is not updated. The output of the ssh command contains this: debug1: Host '[serverA.domain.internal]:22' is known and matches the ED25519 host key. # ... debug1: client_input_hostkeys: searching /Users/snafu/.ssh/known_hosts for [serverA....

...ted ssh: > > cd /etc/ssh > sudo ssh-keygen -f 2024_ssh_host_ed25519_key -t ed25519 -N '' > > sudo vi /etc/ssh/sshd_config > # added line: HostKey /etc/ssh/2024_ssh_host_ed25519_key > > sudo service ssh restart > > > When I connect to serverA (`ssh -v -o UpdateHostKeys=yes serverA`) > afterwards, known_hosts on the client is not updated. The output of the > ssh command contains this: > > debug1: Host '[serverA.domain.internal]:22' is known and matches the ED25519 host key. > # ... > debug1: client_input_hostkeys: searching /Users/snafu/...