.ssh/known_hosts:

[ab@novell.com]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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/

iQIcBAEBAgAGBQJK6CvVAAoJEF+XTK08PnB5BsoQAKuY2EufUv E7dB5JepORWVKj
CUMXcD2AKzgN0KyPmIDSJtXxCu3YVif8QSEgT5SwDzunzmGat/cMa4e+kCX2JSOh
ix99Pt1sbsx+gvMCNqSiuDVoghxub6xoSLwcqeJiizNhlYW81S/PrvhwpHdrlBbI
ab0ua7REB6F2meaSP/q83ZXJKlhcDWxfdTECBMg6h9fl+aa2H1XHrk4Jf9Nn4/fm
fSHXMTKR4RpL7yS5R7YX9ho0oFJ+/cyO+iklhkVrfLy3JAmylEb83sUgobMiaUUe
YdbUiW5/p8pqSoRNWKg4zng6lv57a3kXLEE9vpBfk7m8ZAvN4BTIvtA2w2 dcynpx
zBusgL1ikpuohxeyRmk3LkaC3o2leqex90C67Y8GOs8FXTOvAS SBdEatZ2p2da4v
b2TDAXHeHIcLrZNHv65jWa0XHykaeBjDlWi/EMMeitAgv9bkF2qPP4n9bNo9WzKV
pYw7pSJCvjlQNBVT+t/v2HdK5hQgIxSWk4FSQCb7KTz86uxVmBhGgOoirmVhL8xZ
oE1CR4sdhIjsbRonwHqH1J/Wdg2pWk+76wdOZ6DYmC49db/KZRZ34ZG6ac8eU+t7
Q0QTTpUjuAwu30vQUvFfwyl9f9B/6F/x5/srzUUCxCARBJAbdhlbHDPEcu2L1bOR
+/Pw3O5Se550tDntvPUH
=C0GL
-----END PGP SIGNATURE-----

[vodoo]

Hi Sam

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.

[samwootton]

Hi,

Many thanks for peoples help.

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

The end result was that i could SSH in with myusername@mydomain.com. So good news.

As soon as i SSH'd in, i saw:

mydomainname.com,76.192.18.170 ssh-rsa AAAAB3Nza....

had been added to known_hosts.

Which makes me wonder - when my IP changes - i guess i am blocked (but hopefully not, because of the change to the config???).

Nearly there ;]

Thanks again.

Regards, Sam

[vodoo]

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.

[ken_yap]

@samwooton

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

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

[mmarif4u]

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.

Hope this is helpful.

[vodoo]

@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?

[smpoole7]

Originally Posted by vodoo

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

[ab@novell.com]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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/

iQIcBAEBAgAGBQJK6tqyAAoJEF+XTK08PnB5OMYP/0Lt70XwMqj5ZBee5Yp70eXq
YwKFtEfVP4rQK9wdrr1NtFp89JEEdN7jHFCwVtmLDGS4mXVH0l NJ8UwWNL9N49ED
XfczdgGDs2oAiFQmW7kBTlFOXq71rMDRCBy8IwR0BnXMz3L3hY nKa4nWhtNuquET
2os6qc3r0lptD6kv/AybLD1SvgIPphewE5zf+QhmHrXLoQVF2Q04jhgkF0B+5mf7
03keluIDsGb3dXxRpPnuQgamN8SMgPrbEjZ65r0wLT3PW8phID qtGO5MpeRVS86q
4ZrN2UERKEqAJDW3Ji0Np2Mqb231nqi6EKC+Z8Qow4U1riEsO2 3rK0ub05OHd9fE
lLp/F/c1j487XBfdkxMcBz8chSGNSQionRY8/Tt32JmCW/ckiKuRndgqHTXpI3Pi
oXDuzhL/gljYrE4+uOY2oIxtuD306GtpSVejCnzs9XLJNPuXNE1j7lTZvK e5QiCa
Ejxyjs0ripmGIhKV2eFGPqNDHONYXBB+ZuLcUxDDCs+Y5WENLU/+wEZjsrijoYWG
XhjeKZndnJR/g6zwqD5NWN/4nVUXnxIcWHZ/COVUNpyc72COoqXx0z+qpENc3ESo
kk/VqB0HsvjetVSf0DsJHgcsuPFICg0ImGq4k6r1mGJ/8/KOT+/uYuCpnI1yJwhH
OmYkhPiESukwqpYCuwb3
=72fZ
-----END PGP SIGNATURE-----

[vodoo]

@smpoole7

Thanks. Now I got it. Total confusion on my side. And sorry to the OP.