similar to: sshfp/ldns still having issues in 7.6

> I replaced the ldns code with getdns. Works fine for more than a year now. > I am interested in how you did that. Would you mind sharing your procedure? > I don't think anybody cares. I tried to tell people. But that had no > effect. > There certainly is not as much talk about it as I would expect there to be.

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:

In the current implementation, ssh always uses the hostname supplied by the user directly for the SSHFP DNS record lookup. This causes problems when using the domain search path, e.g. I have "search example.com" in my resolv.conf and then do a "ssh host", I will connect to host.example.com, but ssh will query the DNS for an SSHFP record of "host.", not

Hi, we're currently considering making use of RFC4255 SSHFP records, but are hitting a problem with a 4.4p1 client running on Tru64 5.1A: [...] debug3: verify_host_key_dns DNS lookup error: out of memory [...] No matching host key fingerprint found in DNS. A 4.3p2 linux client gives the following : [...] debug3: verify_host_key_dns debug1: found 1 insecure fingerprints in DNS debug1:

https://bugzilla.mindrot.org/show_bug.cgi?id=2702 Bug ID: 2702 Summary: ssh compiled with --with-ldns segfaults during known_hosts parsing Product: Portable OpenSSH Version: 7.5p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh

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

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2022 --- Comment #2 from Darren Tucker <dtucker at zip.com.au> --- Patch applied, thanks. I still don't understand how it gets into this state since the space should be allocated immediately beforehand: if (rrset->rri_nsigs > 0) { rrset->rri_sigs = calloc(rrset->rri_nsigs,

Hi, as discussed before, we're trying to make use of SSHFP records (RFC 4255) to publish host key fingerprints in the DNS. However, some non-OpenBSD platforms don't support DNSSEC in the native resolver (e.g. glibc), which renders the whole thing quite useless, since openssh correctly requires the RRs to be signed and validated. The following patch adds support for ldns, an external

https://bugzilla.mindrot.org/show_bug.cgi?id=2708 Bug ID: 2708 Summary: openssh: 7.5p1 update breaks ldns/sshfp Product: Portable OpenSSH Version: 7.5p1 Hardware: Other OS: FreeBSD Status: NEW Severity: normal Priority: P5 Component: ssh Assignee: unassigned-bugs at

https://bugzilla.mindrot.org/show_bug.cgi?id=2603 Bug ID: 2603 Summary: Build with ldns and without kerberos support fails if ldns compiled with kerberos support Product: Portable OpenSSH Version: 7.3p1 Hardware: amd64 OS: Linux Status: NEW Severity: normal Priority: P5

Dear OpenSSH Developers, I'm a member of the Debian System Administration (DSA) team. [1] We manage the Debian Projects computing infrastructure. Recently, DSA had the opportunity to address a member's request that we begin using certificates to authenticate Debian Project machines to ssh clients. We provided a lengthy reply, the summary of which is "we publish SSHFP records; use

https://bugzilla.mindrot.org/show_bug.cgi?id=2022 Bug #: 2022 Summary: ssh segfaults when using ldns, SSHFP, a DNSSEC-enabled resolver and a CNAME Classification: Unclassified Product: Portable OpenSSH Version: 6.0p1 Platform: All OS/Version: All Status: NEW Severity: normal

https://bugzilla.mindrot.org/show_bug.cgi?id=2516 Bug ID: 2516 Summary: ssh client shouldn't trust the DNS AD bit blindly Product: Portable OpenSSH Version: 7.1p1 Hardware: All OS: All Status: NEW Severity: security Priority: P5 Component: ssh Assignee: unassigned-bugs at

https://bugzilla.mindrot.org/show_bug.cgi?id=2022 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #5 from Damien Miller <djm at mindrot.org> --- Set all RESOLVED bugs to CLOSED with release

http://bugzilla.mindrot.org/show_bug.cgi?id=1320 Summary: Add support for ldns Product: Portable OpenSSH Version: -current Platform: Other OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org ReportedBy: svallet at

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

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

Well, known_hosts isn't exactly trusted input, since it's usually composed of the keys you first encounter, without any additional checking, as opposed to (hopefully) correctly signed SSHFP records. On Sat, Feb 23, 2019 at 10:22 PM Peter Stuge <peter at stuge.se> wrote: > > Yegor Ievlev wrote: > > > I think it's a very bad idea to have the client start treating

Hi, is it possible to use SSHFP DNS records to enable password-free host-based login? What I already got working is to use SSHFP DNS records to verify the server host keys. debug1: found 2 secure fingerprints in DNS debug1: matching host key fingerprint found in DNS But hostbased login does not work and I still need to supply a password to log in. (Or to configure a known_hosts file on the