https://bugzilla.mindrot.org/show_bug.cgi?id=1993
Darren Tucker <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #2 from Darren Tucker <[email protected]> --- (In reply to comment #1) > Also encountered this (on 6.2p1-1) and found that the > StrictHostKeyChecking option is entirely non-functional: > > Set this up in ~/.ssh/config: > > host 192.168.*,10.* > StrictHostKeyChecking no > > But it has no effect when ssh'ing to any boxes in the defined > networks. If a key is present in known_hosts file, but the host > itself has changed, it craps out with the "WARNING: REMOTE HOST > IDENTIFICATION HAS CHANGED!" message. That's what it's supposed to do. It's the only thing protecting you from MITM attacks. From ssh_config(5): "The host keys of known hosts will be verified automatically in all cases." > Uncommenting "StrictHostKeyChecking no" in /etc/ssh/ssh_config has > the same result. > > Finally, even using the CLI option "-o StrictHostKeyChecking=no" > doesn't work and errors the same way. And, If the key isn't > present, it still gets auto-saved: > > >ssh -o StrictHostKeyChecking=no [email protected] > Warning: Permanently added '192.168.1.1' (RSA) to the list of known > hosts. That's what you asked it to do: save new keys to the config file without asking first. If you practice poor host key hygiene and your host keys change without notice you can use "StrictHostKeyChecking no", "UserKnownHostsFile /dev/null" and "LogLevel quiet" to suppress all warnings, but be aware that you lose all protection against MITM attacks. >From a security standpoint you'd be better off fixing the host key handling problems (for example if you have dynamic IPs and DNS then you can tell ssh to just store the hostnames and not IPs with "CheckHostIP no", or if you routinely reinstall systems then save and restore the host keys). The name truncation this is quite possibly a bug, I'll take a look at that. -- You are receiving this mail because: You are watching the assignee of the bug. You are watching someone on the CC list of the bug. _______________________________________________ openssh-bugs mailing list [email protected] https://lists.mindrot.org/mailman/listinfo/openssh-bugs
