similar to: [Bug 2119] New: SSHFP with DNSSEC – no trust anchors given, validation always fails

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, 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

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=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 --- 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,

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

> 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=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

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

On 2/12/19 10:55 PM, Alice Wonder wrote: > DNSSEC keys do not expire. Signatures do expire. How long a signature > is good for depends upon the software generating the signature, some > lets you specify. ldns I believe defaults to 60 days but I am not sure. > > The keys are in DNSSKEY records that are signed by your Key Signing > Key and must be resigning before the signature

Hi, I submitted a patch back in November of 2009 to add local validation of DNSSEC record to openssh. I recent updated the patch for 5.8, and figured I do a little marketing while I'm at it. :-) Someone had previously submitted a patch which simply trusted the AD bit in the response, which is susceptible to spoofing by anyone who can inject packets between the resolver and the client. Our

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

I am reading: https://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-bind-rndc.html I have bind installed and default config running. I have not applied my customizations yet. The first step I am taking is getting rndc.key created. So reading the guide I am trying to run (while logged in as root, and in /etc): dnssec-keygen -a hmac-md5 -b 256 -n HOST rndc.key The system is just

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

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

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

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

I am having trouble both setting and connecting to rails pages and anchors. using a collection, I am trying to set the anchors like this... <a href="in_outs/list#name=<%= user_list_facility.list_value %>">\ <%= user_list_facility.list_value %></a> which does sort of work...the resulting source html is: <a href="name=15th Ave">15th Ave</a>