similar to: auto-accept keys matching DNSSEC-validated SSHFP records

https://bugzilla.mindrot.org/show_bug.cgi?id=1672 Summary: add local DNSSEC validation Product: Portable OpenSSH Version: 5.3p1 Platform: Other OS/Version: Linux Status: NEW Severity: enhancement Priority: P2 Component: ssh AssignedTo: unassigned-bugs at mindrot.org ReportedBy: robert.story

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

Well, SSHFP is supposed to only be used on DNSSEC-enabled domains. On Sat, Feb 23, 2019 at 9:59 PM Peter Stuge <peter at stuge.se> wrote: > > Yegor Ievlev wrote: > > It would make more sense to treat SSHFP records in the same way as > > known_hosts > > I disagree with that - known_hosts is nominally a client-local configuration. > > I think it's a very bad

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

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

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

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

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2041 Priority: P5 Bug ID: 2041 Assignee: unassigned-bugs at mindrot.org Summary: Check for SSHFP when certificate is offered. Severity: enhancement Classification: Unclassified OS: All Reporter: ondrej at caletka.cz Hardware: All Status: NEW

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

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

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

Attached is a patch that adds local DNSSEC validation to OpenSSH. See the readme for more detail. Please direct any questions or comments to users at dnssec-tools.org. Thanks.. -- Robert Story Senior Software Engineer SPARTA (dba Cobham Analytic Soloutions) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size:

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

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

https://bugzilla.mindrot.org/show_bug.cgi?id=2223 Bug ID: 2223 Summary: Ed25519 support in SSHFP DNS resource records Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at

https://bugzilla.mindrot.org/show_bug.cgi?id=1672 --- Comment #8 from pva <peter.volkov at gmail.com> --- What is the status of this patch? It looks like many people don't realize that without a secure local resolver, SSHFP just hides security under the carpet: instead of a clear one-time 'yes' it makes this 'yes' unattended, yet it's still possible for mitm on local

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.