similar to: [Bug 1296] VerifyHostKeyDNS default domain

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=1296 Karl P <barnaclebob at gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |barnaclebob at gmail.com Version|5.1p1 |5.6p1 Status|CLOSED

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

Y'all, Currently (OpenSSH_7.1p1) no distinction is made between when an SSHFP RR is missing from the result set (rather then being empty), which can lead to confusing error messages, (the "normal" warn_changed_key() blurb is emitted) e.g. when the presented host key and known hosts both match but there is no matching RR. Further, if VerifyHostKeyDNS and StrictHostKeyChecking are

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

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

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

OpenSSH 9.3 has just been released. It will be available from the mirrors listed at https://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches, reported bugs, tested

Hello. I have an issue with SSHFP lookups using "VerifyHostKeyDNS=yes" and "options edns0" in /etc/resolv.conf (glib >= 2.6). getrrsetbyname() calls res_query() with a maximum buffer size of 65536. The glibc resolver truncates this value to 16 bits, reducing the query's advertised buffer size to 0. BIND appears to ignore it while Unbound returns a server failure.

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

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

http://bugzilla.mindrot.org/show_bug.cgi?id=1317 Summary: ssh uses obsolete SIG RRtype Product: Portable OpenSSH Version: -current Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: ssh AssignedTo: bitbucket at mindrot.org ReportedBy: svallet at

https://bugzilla.mindrot.org/show_bug.cgi?id=1978 Bug #: 1978 Summary: ECDSA & SHA256 support in SSHFS DNS records Classification: Unclassified Product: Portable OpenSSH Version: 5.9p1 Platform: All URL: https://tools.ietf.org/html/draft-os-ietf-sshfp-ecdsa- sha2-07 OS/Version: All

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

OpenSSH 6.7 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. Once again, we would like to thank the OpenSSH community for their continued support of the project, especially those who contributed code or patches,

http://bugzilla.mindrot.org/show_bug.cgi?id=1236 Summary: SCP inappropriate truncate error when copying to FIFO file Product: Portable OpenSSH Version: 4.3p2 Platform: ix86 OS/Version: All Status: NEW Severity: normal Priority: P2 Component: scp AssignedTo: bitbucket at