similar to: [Bug 1296] VerifyHostKeyDNS default domain

Hi, I was trying to run sshd after applying the fips patches mentioned in http://www.gossamer-threads.com/lists/engine?do=post_attachment;postatt_id=1835;list=openssh but for some reason sshd refuses to accept the connection. I guess I do something terribly wrong. Is there a reason that this is bound to fail? These 5.6 patches were the most recent I could find. Are there any fips patches

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

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|

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

Need help for uploading a public key for a new EC2 (AMI) user to tmp folder. Any help on this appreciated. Follow the steps http://aws.amazon.com/articles/1233 i.e not able to pass this step "Copy all the public key files that you generated to a temporary place on your instance:" Steps: 1. SSH into my EC2 instance and logged in as su 2. Created a user "geoman" and with a

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

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=1296 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |FIXED --- Comment #5 from Damien Miller <djm at

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

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

https://bugzilla.mindrot.org/show_bug.cgi?id=1835 Summary: sftp should fallback to sshv1 if server doesn't support sshv2 Product: Portable OpenSSH Version: 5.6p1 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: sftp AssignedTo:

https://bugzilla.mindrot.org/show_bug.cgi?id=2042 Priority: P5 Bug ID: 2042 Assignee: unassigned-bugs at mindrot.org Summary: Troubleshooting information should be logged when sshd doesn't have permission to read user's authorized_keys file Severity: enhancement Classification: Unclassified

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.

I'm trying to replace some sshv1 clients and servers in a modular way, and the "Server Lies" warning (when the server says the key has one more bit than it really has) is causing heartache. Per the FAQ, this is relatively benign. Here's a patch that allows an admin or user to disable the warning. - Morty diff -Nur openssh-3.7.1p2/readconf.c

https://bugzilla.mindrot.org/show_bug.cgi?id=1213 --- Comment #48 from Daniel Richard G. <skunk at iSKUNK.ORG> --- (In reply to Damien Miller from comment #47) > > There might be a few cases that we've missed, but please give > -current a spin and let us know if it has fixed all keyscan crashes > that you were seeing previously (I think it should...) Hi Damien, thank you

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:

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