similar to: Missing SSHFP RRs / VerifyHostKeyDNS & StrictHostKeyChecking

https://bugzilla.mindrot.org/show_bug.cgi?id=2501 Bug ID: 2501 Summary: VerifyHostKeyDNS & StrictHostKeyChecking Product: Portable OpenSSH Version: 7.1p1 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

Have you seen this? https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=742513 --mancha

Hello. Subramanian Moonesamy has gotten the ball rolling to include Ed25519 in IANA's registry for SSHFP key types [1]. I've opened a bug report [2] that includes a patch that adds the needed support code and provisionally assigns Ed25519 a value of 4 (values 1,2,3 reserved for RSA, DSA, and ECDA, respectively) [3]. The enhancement request/bug is meant to keep the issue on the radar.

Hello list, I'm not sure whether this is bug worthy or just my own insanity. I'm using 6.4p1 packages from Debian jessie and wheezy-backports. I like VisualHostKey, although it may not add any protection (other than not trusting ones own known_hosts file?), I've become accustomed to it as it seems that extra neurons fire when I log into a host and get a visual cue of what looks like

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2040 Priority: P5 Bug ID: 2040 Assignee: unassigned-bugs at mindrot.org Summary: Downgrade attack vulnerability when checking SSHFP records Severity: minor Classification: Unclassified OS: All Reporter: ondrej at caletka.cz Hardware: All

http://bugzilla.mindrot.org/show_bug.cgi?id=1296 Summary: VerifyHostKeyDNS default domain Product: Portable OpenSSH Version: 4.3p2 Platform: ix86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org ReportedBy: dan at danrowles.com

https://bugzilla.mindrot.org/show_bug.cgi?id=1296 Christoph Lechleitner <christoph.lechleitner at iteg.at> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |christoph.lechleitner at iteg. | |at --- Comment

https://bugzilla.mindrot.org/show_bug.cgi?id=3698 Bug ID: 3698 Summary: SSHFP validation fails when multiple keys of the same type are found in DNS Product: Portable OpenSSH Version: 8.7p1 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 Component: ssh

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 at mindrot.org> wrote: > > On Fri, 22 Feb 2019, Yegor Ievlev wrote: > > > Steps to reproduce: > > 1. Run a SSH server with

When connecting to a host that provides an ECDSA host key and the client has "VerifyHostKeyDNS" set to 'yes' or 'ask' SSH outputs a mysterious and undocumented message "Error calculating host key fingerprint." This error actually seems to be generated by verify_host_key_dns(const char *hostname, struct sockaddr *address, Key *hostkey, int *flags) in dns.c, but

hi, I recently committed an update of the code that handles lookup of SSHFP resource records in DNS. this code is now included by default, the old DNS and DNSSEC defines has been removed. for more information, read about VerifyHostKeyDNS in ssh_config(5) and check out README.dns. feedback would be appreciated, jakob

Hi, I found a small issue with DNSSEC validation of SSHFP lookups. (For reference I used OpenSSH 6.8p1 on FreeBSD 10.1). The issues is that when DNSSEC valiation fails, ssh displays a confusing message to the user. When DNSSEC validation of a SSHFP record fails, ssh presents the user with "Matching host key fingerprint found in DNS. "Are you sure you want to continue connecting

I have been running openSSH 7.4p1 for a while now. When I upgraded to 7.5 a year or so ago I ran into the problem listed in this bug report: Bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218472 The release notes for 7.6 release notes indicate that the fix patch was included: https://www.openssh.com/txt/release-7.6 I tried 7.6 and I still cannot connect without a prompt wondering

hi folks: it looks like ssh-keygen -r can''t export SSHFP records for ECDSA keys: 0 dkg@pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -f foobar -t ecdsa -q -P '''' 0 dkg@pip:/tmp/cdtemp.oiRYAS$ ssh-keygen -r foobar -f foobar.pub export_dns_rr: unsupported algorithm 0 dkg@pip:/tmp/cdtemp.oiRYAS$ the first number in my prompt is the return code of the last command; note that

https://bugzilla.mindrot.org/show_bug.cgi?id=2119 Bug ID: 2119 Summary: SSHFP with DNSSEC ? no trust anchors given, validation always fails Product: Portable OpenSSH Version: 6.2p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5 Component:

https://bugzilla.mindrot.org/show_bug.cgi?id=1296 Karl P <barnaclebob at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |barnaclebob at gmail.com Version|5.1p1 |5.6p1 Status|CLOSED

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

https://bugzilla.mindrot.org/show_bug.cgi?id=1296 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |djm at mindrot.org Status|NEW |RESOLVED Resolution|

https://bugzilla.mindrot.org/show_bug.cgi?id=1608 Simon Deziel <simon at sdeziel.info> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |simon at sdeziel.info -- You are receiving this mail because: You are watching the assignee of the bug.