openssh bugs - Jun 2015 - [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

--- Comment #9 from Christoph Anton Mitterer <calestyo at scientia.net>
---

(replies to all your comments in one)

Hey.

Sorry for the delay.

(In reply to Darren Tucker from comment #5)
> > $ ssh -o StrictHostKeyChecking=no someHost
> > Warning: Permanently added the ECDSA host key for IP address
> > '2e01:2a6:b9:3823::2:1' to the list of known hosts.
> > (changed the IP/name for privacy reasons).
First, I just tried it again with 6.7p1.

> Did you have an existing, valid hostkey with a different algorithm
> for that host?
There was no key for that host (neither with another algo) in
known_hosts, but there were in ssh_known_hosts (i.e. for all algos the
target host supports).

> I suspect it's due to the hostkeys-00 at openssh.com
> method that advertises the other host key types after successful
> authentication.
That can't be the case, since this was only added in 6.8, IIRC, and I'd
disable it since I consider it a security risk.

> Can you run ssh -vvv and see if those appear
> immediately before the "key added" message?
nope:
$ ssh -vvv host 2>&1 | grep "hostkeys-.*@openssh.com"
$

> > - the name truncation no longer happens, but only since the message
> > is now a different one... so isn't that issue anyway gone?
> I found the truncation in comment #1, diff incoming.
Great :)
AFAIU the fix for that specific part (i.e. the truncation) has been
commited for 6.9, right? So we can check of that one.

> > Alex, you obviously confused the value no with yes... "no"
is meant
> > to automatically add the key...
> 
> Also with regard to that comment:
> 
> "host 192.168.*,10.*
> StrictHostKeyChecking no
> 
> But it has no effect when ssh'ing to any boxes in the defined
> networks."
> 
> "Host" in ssh_config doesn't define a network, it defines a
hostname
> as passed to the ssh command line.  It should work if you specify an
> IP address on the command line.
May I suggest, that you add an example like this to the description in
the manpage.
As we can see, people may easily confuse this and believe it would be
matched after name resolution.



> Err, that's exactly what StrictHostKeyChecking=no is supposed to do:
> 
> "If this flag is set to "no", ssh will automatically add new
host
> keys to the user known hosts files."
gnah,... that comes from copy&pasting :D
I tried of course with =yes and =ask,... and with both it happens that
it adds an entry for the IP-address to known_hosts, while I used the
hostname with they pre-existing entry from ssh_known_hosts.
> Assuming you meant "StrictHostKeyChecking=yes"
Yes =)
>, I can imagine 2
> cases where this could be the case: the server sending you a new
> host key via hostkeys-00 at openssh.com  as mentioned above,
Probably not the case, as said above.
> or adding
> adding a key for the IP address only after having found a correct
> matching host key for the name in the system-wide config.
Sure... and this is the very issue I was reporting in the beginning.

I have no idea why OpenSSH chose to do so, IMHO it's not very smart
security-wise:
IP addresses may easily change and the address 1.2.3.4 that previously
belonged to trusted.host.org may be used by rogue.server.com next day.
But due to this auto-adding of the key under the address it will be
trusted as well.
Of course rogue.server.com would still need the private key, but I
could have just moved my VM server to another ISP (and they might have
kept a copy) and now be able to trick me into using it.

It's for sure not the worst security hole, but generally I think the
relation "name <-> trusted key" (with "name" being a
hostname or an
address) should never be automagically added without the user's
consent.
If I add a key for example.org, then I want that be trusted for just
"example.org".
Should I also want to access it via it's IP, then I should need to add
93.184.216.34 myself.

Is there any benefit (technical or security) of adding the key for the
IP automatically? At least I see just disadvantages:
- the one above
- longer known hosts files which need to be parsed
- stale keys may be left over (and trusted) in the user's known_hosts,
when e.g. the sysadmin managed ssh_known_hosts replaces legacy keys.
> The
> debug output from ssh -vvv should give a clue as to what is going
> on, so please attach one.
will do that in a minute



(In reply to Damien Miller from comment #8)
> The OP's question is the CheckHostIP option updating addresses for
> hostnames it already knows about. We could probably clarify the
> documentation for this behaviour
Well, see above,... I think it shouldn't (even if the documentation was
updated),... I think it's really security sensitive...

But adding information about that behaviour would of course be better
than nothing.

If I remember correctly, DKG has posted a patch some time ago on the
mailing list, requesting to disable CheckHostIP anyway.
I agreed with him, it seems to provide no additional security but
rather just leaks information.
> but if you want to avoid it use:
> 
> UserKnownHostsFile none
> SystemKnownHostsFile /etc/ssh/known_hosts ~/.ssh/known_hosts
> 
> to get ssh to treat the known hosts file as a system (read-only)
> rather than a user (r/w) file.
That's however merely a bad workaround, as this also means that the
user cannot use a personal hosts file.
I, however, just want to prevent auto-adding known/trusted keys with
IPs of the hosts to that file :-)

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