similar to: [Bug 2241] New: ssh-keygen -R removes matching key as well as @cert-authority

I have confirmed this behavior from OpenSSH 6.6 in OS X (from MacPorts) and 6.6 in Ubuntu. I have set up a SSH Certificate authority, and as such I put in the following line at the top of my known_hosts file @cert-authority *.mydomain.com ssh-rsa <public key> Below this are all my hashed entries for various other hosts that I?ve contacted over the years. Every once in a while I?ll

https://bugzilla.mindrot.org/show_bug.cgi?id=2045 Priority: P5 Bug ID: 2045 Assignee: unassigned-bugs at mindrot.org Summary: point user to ssh-keygen -R to remove key from known_hosts Severity: enhancement Classification: Unclassified OS: All Reporter: thomas at koch.ro Hardware: All

http://bugzilla.mindrot.org/show_bug.cgi?id=780 Summary: ssh host-key hash should match ssh-add/ssh-keygen hash Product: Portable OpenSSH Version: -current Platform: ix86 OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: openssh-bugs at mindrot.org

https://bugzilla.mindrot.org/show_bug.cgi?id=1545 Summary: ssh-keygen -R removes all comments from known_hosts file Product: Portable OpenSSH Version: 5.1p1 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh-keygen AssignedTo:

https://bugzilla.mindrot.org/show_bug.cgi?id=2591 Bug ID: 2591 Summary: ssh-keygen -R is case-sensitive, but should not be Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: minor Priority: P5 Component: ssh-keygen Assignee: unassigned-bugs

https://bugzilla.mindrot.org/show_bug.cgi?id=2145 Bug ID: 2145 Summary: ssh-keygen -R doesn't work when there are entries for "proxycommand" keys Product: Portable OpenSSH Version: 6.2p1 Hardware: Other OS: Linux Status: NEW Severity: trivial Priority: P5

https://bugzilla.mindrot.org/show_bug.cgi?id=3600 Bug ID: 3600 Summary: please make ssh-keygen symlink aware for proper handling of hosts removal in symlinked known_hosts Product: Portable OpenSSH Version: 9.3p2 Hardware: amd64 OS: Linux Status: NEW Severity: enhancement

Hi, I tripped over the effects of commit 660854 [0] when moving some infrastructure from Debian 7 to 8 (openssh 6.0 to 6.7); our ansible module used "return 0, but no output" for 'host not found in known_hosts file', and now complains that ssh-keygen is returning an error status. I don't think this change in API was announced in the release notes? i.e. ssh-keygen -F

http://bugzilla.mindrot.org/show_bug.cgi?id=997 Summary: Correction to man page for ssh-keygen Product: Portable OpenSSH Version: 4.0p1 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: Documentation AssignedTo: openssh-bugs at mindrot.org ReportedBy:

Since ssh-keygen is not listing the _types_ of keys I have in my file, wouldn't it be a good idea to make the -t switch filtering out the selected type of key when doing a listing with -l? i.e. in this case I see both rsa1, rsa, and dss keys: $ ssh-keygen -l -f ~/.ssh/known_hosts 1024 a9:4f:0b:b6:33:d7:d0:ad:6a:11:b4:57:25:7e:1e:f8 fluff.x42.com 1024

Scenario: Use the ssh-keygen utility in openssh-1.2pre17 to generate a host key Kill and restart sshd Remove the old host key from ~/.ssh/known_hosts Connect to the host using ssh. I get this: homer.ka9q.ampr.org$ ssh 199.106.106.3 who The authenticity of host '199.106.106.3' can't be established. Key fingerprint is 1024 a0:8d:17:f0:fa:a9:9f:6f:b5:d0:1c:d6:02:92:bd:5e. Are you sure

https://bugzilla.mindrot.org/show_bug.cgi?id=1544 Summary: ssh-keygen -l on known_hosts file does not display hostnames for lines with comments Product: Portable OpenSSH Version: 5.1p1 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh-keygen

https://bugzilla.mindrot.org/show_bug.cgi?id=3216 Bug ID: 3216 Summary: Confusing error "host key ... has changed" when connecting to a server not offering matching host key types Product: Portable OpenSSH Version: 7.9p1 Hardware: ARM64 OS: Linux Status: NEW

https://bugzilla.mindrot.org/show_bug.cgi?id=3157 Bug ID: 3157 Summary: known_hosts @cert-authority with legacy plain key entry drops incorrect set of HostKeyAlgorithms Product: Portable OpenSSH Version: 8.1p1 Hardware: All OS: Mac OS X Status: NEW Severity: normal Priority:

https://bugzilla.mindrot.org/show_bug.cgi?id=3146 Bug ID: 3146 Summary: ssh-keygen -R changes permissions on existing file Product: Portable OpenSSH Version: 7.9p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh-keygen Assignee:

https://bugzilla.mindrot.org/show_bug.cgi?id=1545 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #25 from Damien Miller <djm at

https://bugzilla.mindrot.org/show_bug.cgi?id=1544 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #26 from Damien Miller <djm at

https://bugzilla.mindrot.org/show_bug.cgi?id=1376 Summary: 'ssh-keygen -HF' hashes host,IP together Classification: Unclassified Product: Portable OpenSSH Version: 4.7p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: ssh-keygen AssignedTo: bitbucket

Hi folks, maybe I am too blind to see, but would it be possible to avoid extra entries in known_hosts, if the remote host has a signed public key matching a @cert-authority line? Something like Host * HashKnownHosts unsigned This could help to keep the known_hosts file small and yet get all the unsigned public keys in. Just a suggestion, of course. Regards Harri

On 11/15/23, 10:51 AM, "openssh-unix-dev on behalf of Marian Beermann" <openssh-unix-dev-bounces+iain.morgan=nasa.gov at mindrot.org <mailto:nasa.gov at mindrot.org> on behalf of public at enkore.de <mailto:public at enkore.de>> wrote: On 11/15/23 18:09, Chris Rapier wrote: > On 11/11/23 9:31 PM, Damien Miller wrote: > >> It's not discouraged so much as