[Bug 1993] ssh tries to add keys to ~/.ssh/known_hosts though StrictHostKeyChecking yes is set

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=1993

Darren Tucker <dtucker at zip.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at zip.com.au

--- Comment #2 from Darren Tucker <dtucker at zip.com.au> ---
(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 root at 192.168.1.1
> 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.