I often wish to SSH in. I am on a dynamic DNS system.
My external IP address changes on a regular basis. Everytime i try to SSH in, i get:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
9a:40:57:9a:de:72:6f:8b:d1:e8:57:67:09:22:09:11.
Please contact your system administrator.
Add correct host key in /home/username/.ssh/known_hosts to get rid of this message.
Offending key in /home/username/.ssh/known_hosts:28
RSA host key for 29.176.21.134 has changed and you have requested strict checking.
Host key verification failed.
How can i specify a wild card or something? So that if my IP address changes, i can still SSH in?
Before you do it, though, it’s not a good thing to have disabled…
Good luck.
samwootton wrote:
> Hi,
>
> Thanks for you reply.
>
> Not sure where to turn strict checking off.
>
> Could you point me in the right direction?
>
> Regards, Sam
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Use a DNS name if you can… that MAY help (untested by me).
You can also clean out your ~/.ssh/known_hosts file every time the IP
changes which gives you security at a reasonable price. The error message
actually tells you the line to delete if you want to bypass the message:
Offending key in /home/username/.ssh/known_hosts:28
Delete line 28 to fix it.
Good luck.
samwootton wrote:
> Hey,
>
> Many thanks for the help.
>
> So yeah, thats what i was kind of thinking - that it might be unsafe.
>
> So, how do i go about allowing SSH access on a dynamic IP?
>
> I have a website hosted on Apache, on a dynamic IP, so need port 22
> access for house keeping.
>
> Thank you.
>
> Regards, Sam
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
It looks to me like what is happening is you are contacting someone else’s sshd, hence the warning. Had you contacted your own sshd on a different address, you would have got an advisory, not fatal, that you have a new host and fingerprint. So disabling strict checking is not the solution. You simply do not have a login on someone else’s sshd and they might think you are trying to hack them.
The problem you really need to solve is how to tie your dynamic address to a domain name known to you. What you want is dynamic DNS. Do a search for what this does and for free providers of this service.
The known_hosts file is tied to something used to reach the destination
server. If you use DNS names then even if the IP changes you’re still
hitting the same box, in theory.
With that in mind I guess instead of cleaning up known_hosts you could
also hack /etc/hosts whenever your IP changes though that is a bigger
hack, in my opinion, as it requires using ‘root’.
Good luck.
samwootton wrote:
> HI,
>
> I only have 3 lines in there. And i am not 100% clear on how using a
> domain name will get around the issue.
>
> I am using a domain name - and i still get the error, thats the
> problem.
>
> Getting slightly more confused here ;]
>
> Thanks for your help.
>
> Regards, Sam
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
Ok - firstly, i really appreciate the time takan by members to help.
I think i didn’t explain things properly.
This machine is running a website, i already use a dynamic DNS solution (dyndns.org), i ran this website on a mac os x for years, then moved to opensuse.
I cannot ssh to e.g. mydomain.com from any machine, either the machine that Apache is on, or any machine from outside it.
There is no reason you cannot do this. SSH-ing FROM a dynamic IP is
normal and will not cause the error you noted. SSH-ing TO a dynamic IP
will result in the error you posted.
So if you moved your website from a Mac to a Linux box and did not copy
over the server-side SSH keys then those keys have changed. In that case,
assuming you do not change the information again, you will need to clean
up your users’ (and all users’ or other clients’) known_hosts file so that
it does not have the mac machine’s keys. Once done you should not get the
error anymore. If you still have your Mac you could probably also copy
over its SSH keys to this server, restart ‘sshd’, and get rid of the error
altogether.
Good luck.
samwootton wrote:
> Ok - firstly, i really appreciate the time takan by members to help.
>
> I think i didn’t explain things properly.
>
> This machine is running a website, i already use a dynamic DNS solution
> (dyndns.org), i ran this website on a mac os x for years, then moved to
> opensuse.
>
> I cannot ssh to e.g. mydomain.com from any machine, either the machine
> that Apache is on, or any machine from outside it.
>
> So:
>
> 1) I have a server that is running Apache.
> 2) It hosts mydomain.com
> 3) It is on a dynamic IP, that uses a updater from dyndns.org.
> 4) How can i SSH in from a changing IP? (as i have dynamic IP)?
>
> Thanks for any help and advice.
>
> Regards, Sam
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
I suggest to read: Configure the /etc/ssh/ssh_config file and then, possibly set ‘CheckHostIP no’ in your configuration file. This reduces security, but you can’t have both at the same time: changing IP addresses AND security.
So, what i have done is clear completely ~/.ssh/known_hosts and put ‘CheckHostIP no’ in my SSH config (although it was commented out anyway - so not sure if i have actually changed anything).
I assume that CheckHostIP defaults to yes, so you changed something when it was not set before. As long as ‘mydomainname.com’ and the key stay the same (same machine but different IP) you should get in now.
In future if you are decommissioning one machine and replacing it with another, you can copy the old sshd host keys over, restart sshd and then you can login on the new machine with no hassles. Otherwise the solution, as mentioned, is to delete the entry in known_hosts and sshd will create a new entry. The fully secure solution is to copy the public part of the host key over using a separate secure channel (USB key, paper, etc.) but most people accept that the host they are ssh’ing to is the correct one. You can also double check the fingerprint.
In future you would get answers faster if you explain the setup fully from the beginning instead of making us play 20 questions with you.
I faced the same issue today, and what i did is just the clean the file .ssh/known_hosts and tried to login again, and it worked and add new key to access the host.
I did configure the ssh daemon on the server and later when i tried from different place(my office pc, server is dedicated hosted by a company), it shows this error, but solved in just 2 minutes by cleaning up that file. Its because i upgraded the server OS and the IP key was different from the current one stored on my PC.
And yeh, no need to put any ‘CheckHostIP no’ line there.
This error shows no issue with server, it has just to clean your pc keys and let ssh add new one.
Suppose the following: you log in for a second time, the client has a different IP address, the target host refuses to let you in, the target host is 200 miles away: how would you clean up known_hosts on the target host?
I think you’re missing the OP’s question. The problem isn’t that the server is checking his (client) IP. The problem is that the client has “strict” checking enabled and is refusing to connect to the server after an IP change. The purpose is to prevent a Man-In-The-Middle attack, and a changed IP on the server end can indicate that this is happening. The known_hosts file is for the latter, not for the server.
Client IPs change all the time – imagine someone on the road with a laptop, SSH’ing in from his/her motel room. I’ve done it myself. As a result and as a practical matter, SSH servers normally don’t do client IP checking nowadays. (That’s me speaking from my own experience; I have absolutely no figures to back that up and I could certainly be wrong.)
This was an interesting thread to me. A lot of people are using Dynamic DNS at the server end now, and it appears that “strict” checking on the client end is too anal-retentive. But how else could you prevent Man In The Middle? An interesting mental exercise.
Exactly on the explanation. The limitation is on the client side just
like SSL limitations are on the web browser and not the web server when it
comes to third-party trust.
Regarding “how does one work around this” I think the answers are here.
Either use a static IP or be aware of the situation and work around it.
This is the same as with the web and SSL as well; either go to a site with
a certificate that is not fully trusted (because you know it is yours and
therefore you trust it) or do not. Adding an untrusted key to a list of
trusted keys also, similarly, undoes the warning. Even in these cases,
though, you do not typically turn off all of the warnings as you want to
be notified when a potential MITM attack is taking place.
Good luck.
smpoole7 wrote:
> vodoo;2057561 Wrote:
>> @mmarif4u
>>
>> Suppose the following: you log in for a second time, the client has a
>> different IP address, the target host refuses to let you in, the target
>> host is 200 miles away: how would you clean up known_hosts on the target
>> host?
>
> I think you’re missing the OP’s question. The problem isn’t that the
> server is checking his (client) IP. The problem is that the client
> has “strict” checking enabled and is refusing to connect to the server
> after an IP change. The purpose is to prevent a Man-In-The-Middle
> attack, and a changed IP on the server end can indicate that this is
> happening. The known_hosts file is for the latter, not for the server.
>
> Client IPs change all the time – imagine someone on the road with a
> laptop, SSH’ing in from his/her motel room. I’ve done it myself. As a
> result and as a practical matter, SSH servers normally don’t do client
> IP checking nowadays. (That’s me speaking from my own experience; I have
> absolutely no figures to back that up and I could certainly be wrong.)
>
> This was an interesting thread to me. A lot of people are using Dynamic
> DNS at the server end now, and it appears that “strict” checking on the
> client end is too anal-retentive. But how else could you prevent Man In
> The Middle? An interesting mental exercise.
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
