Hi. By chance I found out that, despite of what ssh_config(5) says: >StrictHostKeyChecking > If this flag is set to “yes”, ssh(1) will never automatically add > host keys to the ~/.ssh/known_hosts file, it does try to add keys there, namely those for which a key is already set in the system wide known hosts file, but only for the hostname and not for the IP address. It says: Failed to add the RSA host key for IP address '129.187.131.211' to the list of known hosts (/var/lib/nagios/.ssh/known_hos). (btw: Notice that it cuts the file name, is this another bug?) While CheckHostIP no prevents the above, it also means (AFAIU) that the IP is not checked, FOR WHICH it was e.g. manually added. Not sure whether this is a bug, or a documentation issue.... and what the right way around is (CheckHostIP no? or UserKnownHostsFile /dev/null ? ) Cheers, Chris.
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@192.168.1.1 Warning: Permanently added '192.168.1.1' (RSA) to the list of known hosts.
(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@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.
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?
Hi guys. With version: 6.7p1 Regarding my initial report: It *still* happens, that SSH automatically adds a key, i.e.: $ echo > ~/.ssh/known_hosts $ 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). - the name truncation no longer happens, but only since the message is now a different one... so isn't that issue anyway gone? Anyway,... you asked for some information about platform, etc. I cannot give you these right now, since yesterday night I locked myself out of the respective nodes, and I cannot fix this from at home. Stay tuned. Regarding comment #1: Alex, you obviously confused the value no with yes... "no" is meant to automatically add the key...
(In reply to Christoph Anton Mitterer from comment #4) > Hi guys. > > With version: 6.7p1 > > > Regarding my initial report: > > It *still* happens, that SSH automatically adds a key, i.e.: > $ echo > ~/.ssh/known_hosts > $ 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). Did you have an existing, valid hostkey with a different algorithm for that host? I suspect it's due to the hostkeys-00@openssh.com method that advertises the other host key types after successful authentication. Can you run ssh -vvv and see if those appear immediately before the "key added" message? > - 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. > Anyway,... you asked for some information about platform, etc. > I cannot give you these right now, since yesterday night I locked > myself out of the respective nodes, and I cannot fix this from at > home. > Stay tuned. [...] > Regarding comment #1: > 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.
Created attachment 2635 [details] Remove length limits on know host file name in log messages
(In reply to Darren Tucker from comment #6) > Created attachment 2635 [details] > Remove length limits on know host file name in log messages A slightly different version of the patch has been committed and will be in the 6.9 release. (When I first looked at this I assumed the log message was accurate and went looking for a truncation in the actual path name used and ended up barking up the wrong tree.) (In reply to Christoph Anton Mitterer from comment #4) [..] > It *still* happens, that SSH automatically adds a key, i.e.: > $ echo > ~/.ssh/known_hosts > $ 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). 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." > Alex, you obviously confused the value no with yes... "no" is meant > to automatically add the key My thoughts exactly :-) Assuming you meant "StrictHostKeyChecking=yes", I can imagine 2 cases where this could be the case: the server sending you a new host key via hostkeys-00@openssh.com as mentioned 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. The debug output from ssh -vvv should give a clue as to what is going on, so please attach one.
The hostkeys-00@openssh.com extension has to be explicitly enabled via UpdateHostKeys=yes|ask 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, 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.
(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@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@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 :-)
Created attachment 2638 [details] ssh -vvv output what happens when a key is auto added for the IP address of an already trusted host
Created attachment 2641 [details] Mention known_hosts modification by CheckHostIP
I've documented this behaviour in the manual; it is by design, so we don't intend to change it.
Set all RESOLVED bugs to CLOSED with release of OpenSSH 7.1