How to tell ssh not to check authenticity of the connection host?

I regularly have to connect to hosts behind multiple VPN networks and providers, addressed as either 10.0.0.* or 192.168.*. That is, each VPN network is free to reserve either of those ranges when connected. For this reason I cannot assume tie a 10.0.0.* address to a particular host, because that would depend on which VPN I am connected to. Or even resolve to my wireless router instead!

For this reason, I explicitly have disabled strict key checking for hosts with these "intranet" addresses matching the above, in my ~/.ssh/config:

Host 192.168.* 10.0.0.*
    StrictHostKeyChecking=no
    UserKnownHostsFile=/dev/null

I have picked these instructions up by googling and also reading other SO questions and answers.

The problem is that every time I connect to the address ranges above, for example ssh 10.0.0.16, it tells me:

Warning: Permanently added '10.0.0.16' (RSA) to the list of known hosts.

which is frankly untrue, by virtue of the ubiquitous /dev/null (which I personally find to often be used as an ugly hack) - there is no permanence of adding anything to /dev/null, is it? It just clutters my terminal and throws me off every time I see it there.

Is there any way to have ssh ignore fingerprint and not print the confusing message above? I don't want to alias ssh='ssh 2>/dev/null' or anything insane like that. Have I gone about this in the wrong way? What choices do I have? Some other options, perhaps? The /dev/null is a hack in my opinion, and that is why I am being punished.

What I do not want to do is alias the nodes to some hostnames on the client side in my ~/.ssh/config, like in this answer. This is because of two reasons:

I cannot simply configure ssh to take an alias (using the Host directive) to resolve to a particular address f.e., precisely because the addresses are reused by different VPN providers I connect to - 10.0.0.15 may for example be one host when connected to one VPN and another when connected to another VPN. Should I "split" my ~/.ssh/config into multiple, one for each VPN? And utilize these configuration files accordingly?
A node in question may be a part of a pretty large group of nodes on the same intranet, a "cloud" as it is called these days. The number of nodes can go up to a hundred. I am not entirely sure how to "bulk-map" multiple such nodes to their respective addresses?

amn

Posted 2015-05-19T08:42:17.480

Reputation: 1 622

So your only issue now is how to get rid of that message after connect? – Marki555 – 2015-05-19T10:00:47.667

Yes, although the fact that I am getting the message may signify I have gone about it the wrong way. Haven't tried CheckHostIP yet. – amn – 2015-05-19T11:11:12.963

I have tried adding CheckHostIP=no to the rule above, but it appears to have no immediate effect - I still get the message as if something was "permanently" added (to /dev/null). It is precisely because I care for security in general, that the message disturbs me, being a false negative, and cluttering my reading of information in the terminal. – amn – 2015-05-19T11:24:35.070

sshd does not allow to turn off most of its security features by design (for example connecting using null cipher). One possibility is to re-compile sshd with these checks disabled. – Marki555 – 2015-05-19T11:32:45.127

Ok, an understandable decision. Should I use rsh in this case, since the security is taken care of by VPN authentication? As far as I understand, it may be exactly what I want then? – amn – 2015-05-19T11:35:29.233

Yes you can try to use rsh if permitted by your security policies... By the way, VPN protects only your connection to the target LAN, but doesn't protect you from the man-in-the-middle attackers on that LAN. – Marki555 – 2015-05-19T11:51:57.950

you can also try the openssh mailing list or maybe comp.security.ssh – barlop – 2015-05-19T17:43:52.953

Answers

I know this is an old question but i was looking for an answer to this to. So for any future googlers, here is what i found.

ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no user@host

you can bind this to an alias to make it easier for you.

alias ssh-nocheck='ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no'

ssh-nocheck user@host

Found the answer on https://linuxcommando.blogspot.com/2008/10/how-to-disable-ssh-host-key-checking.html

-edit: formatting

SoysauceShow

Posted 2015-05-19T08:42:17.480

Reputation: 21

By ignoring the authenticity checks you are opening yourself to a man-in-the-middle attack, so you may want to reconsider.

You might want to modify your SSH configuration by setting "CheckHostIP" to no and then setting up entries in your hosts file for each host and connecting by name rather then hosts. (Note I have not tried this, but I believe it will work). Have a look here as well.

davidgo

Posted 2015-05-19T08:42:17.480

Reputation: 49 152

Just to get it out of the way - I am aware of the implications of ignoring autheticity checks. I believe these implications are of no consequence in my case, as the entire possibility to reach the nodes behind the addresses mentioned is first established after connecting to the VPN through a SSL tunneled authentication (VMWare VPN client). Plus, I suspect the VPN connection itself to be SSL tunneled. – amn – 2015-05-19T11:14:08.903

I have an entire sequence of nodes, that are part of a processing "cloud", and aliasing each would be unfeasible. They also are not mapped by my DNS service in any way, so unless I label them, the only way to reach them is through IP addresses. Am I to understand that SSH has no way of simply leaving its entire host-ip check alone? It appears it can be partially circumvented but it's all of limited usefulness, while the actual core issue - establishing an SSH connection to a server that "roams" through IP address space - cannot be easily solved? – amn – 2015-05-19T11:22:31.783