openssh bugs - May 2013 - [Bug 1993] ssh tries to add keys to ~/.ssh/known_hosts though StrictHostKeyChecking yes is set

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

alex at testcore.net changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |alex at testcore.net
            Version|5.9p1                       |6.2p1

--- Comment #1 from alex at testcore.net ---
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.

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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.

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

--- Comment #3 from Darren Tucker <dtucker at zip.com.au> ---
I can't reproduce the name truncation bug on fedora with either 5.9p1
or 6.2p1:

$ ls -l /var/lib/nagios/.ssh/known_hosts
ls: cannot access /var/lib/nagios/.ssh/known_hosts: No such file or
directory

$ ssh -o stricthostkeychecking=no 192.168.1.1 
Warning: Permanently added '192.168.1.1' (RSA) to the list of known
hosts.
^C

$ cat /var/lib/nagios/.ssh/known_hosts 
192.168.1.1 ssh-rsa [....]

The fact that the string is 31 bytes long is suspicious, and it makes
me thing that it's picking up a PATH_MAX or MAXPATHLEN of 32 bytes from
somewhere, but it's not from openssh itself (if it doesn't know any
better it uses 64 bytes).

What platform is this and what is PATH_MAX and/or MAXPATHLEN?  Do you
have UserKnownHostsFile set to a non-default value?

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