3 ms·

unfortunately, devops (like me) need to ignore these as part of our work system. i need to automate deployment / reprovisioning of 30 digital ocean servers. a

unfortunately, devops (like me) need to ignore these as part of our work system. i need to automate deployment / reprovisioning of 30 digital ocean servers. as reprovisionined servers frequently use the same ip address, i always run into this. for me I had to disable the check :(

Titanous 13y ago
By disabling that check, you are destroying a huge component of the security that SSH provides. Perhaps you could clean up the authorized_keys file as part of your teardown script?
gregf 13y ago
I ran into this issue as well. As the person below mentioned, make this part of your teardown script. You can use ssh-keygen -R hostname to remove host from ~/.ssh/known_hosts.
karlkatzke 13y ago
I've ended up in this situation too. We migrate between datacenters with duplicate hosts fairly frequently at my primary place of employment, and best practice is to use the cname of the service to access the server currently acting as the primary for it (e.g. foo.bar.com as opposed to foo.datacenter.bar.com). That leaves me with a lot of foo.bar.com entries to clean out of known_hosts, or a lot of spurious MITM errors. What I've done is added a whitelist to my .ssh/config to disable the alerts only for those hosts. The foo.datacenter.bar.com address (which I use often enough, usually when migrating it between datacenters) still alerts. And yes, I know I'm living in the 90s what with my datacenters and whatnot. They're kind of like regions... what? Oh... why, you... You kids, get off my lawn!
ef4 13y ago
Part of automating deployment is automating key management. Ignoring host key checks is the worst possible solution. You're actually better off just baking a shared key into your image. So long as it's a key you generated yourself (not like this Digital Ocean scenario, where the key came from the cloud host), only someone who has already rooted one server can successfully MITM your SSH connections. Whereas if you ignore host key checks entirely, anyone who gains control of one network hop between you and your servers can own you.
Spooky23 13y ago
Not managing keys is asking for trouble. Consider signing your SSH keys to validate that you've properly pruned outdated host entries. See: http://www.openbsd.org/papers/asiabsdcon2011_openssh_whats_new.pdf http://www.openbsd.org/papers/asiabsdcon2011_openssh_whats_n... http://blog.habets.pp.se/2011/07/OpenSSH-certificates http://blog.habets.pp.se/2011/07/OpenSSH-certificates http://en.community.dell.com/techcenter/b/techcenter/archive/2011/09/08/setting-up-certificate-authority-keys-with-openssh-version-5-4.aspx http://en.community.dell.com/techcenter/b/techcenter/archive... Spend an afternooon to figure this out.

Titanous 13y ago

By disabling that check, you are destroying a huge component of the security that SSH provides. Perhaps you could clean up the authorized_keys file as part of your teardown script?

gregf 13y ago

I ran into this issue as well. As the person below mentioned, make this part of your teardown script. You can use ssh-keygen -R hostname to remove host from ~/.ssh/known_hosts.

karlkatzke 13y ago

I've ended up in this situation too. We migrate between datacenters with duplicate hosts fairly frequently at my primary place of employment, and best practice is to use the cname of the service to access the server currently acting as the primary for it (e.g. foo.bar.com as opposed to foo.datacenter.bar.com). That leaves me with a lot of foo.bar.com entries to clean out of known_hosts, or a lot of spurious MITM errors. What I've done is added a whitelist to my .ssh/config to disable the alerts only for those hosts. The foo.datacenter.bar.com address (which I use often enough, usually when migrating it between datacenters) still alerts. And yes, I know I'm living in the 90s what with my datacenters and whatnot. They're kind of like regions... what? Oh... why, you... You kids, get off my lawn!

ef4 13y ago

Part of automating deployment is automating key management. Ignoring host key checks is the worst possible solution. You're actually better off just baking a shared key into your image. So long as it's a key you generated yourself (not like this Digital Ocean scenario, where the key came from the cloud host), only someone who has already rooted one server can successfully MITM your SSH connections. Whereas if you ignore host key checks entirely, anyone who gains control of one network hop between you and your servers can own you.

Spooky23 13y ago

Not managing keys is asking for trouble. Consider signing your SSH keys to validate that you've properly pruned outdated host entries. See: http://www.openbsd.org/papers/asiabsdcon2011_openssh_whats_new.pdf http://www.openbsd.org/papers/asiabsdcon2011_openssh_whats_n... http://blog.habets.pp.se/2011/07/OpenSSH-certificates http://blog.habets.pp.se/2011/07/OpenSSH-certificates http://en.community.dell.com/techcenter/b/techcenter/archive/2011/09/08/setting-up-certificate-authority-keys-with-openssh-version-5-4.aspx http://en.community.dell.com/techcenter/b/techcenter/archive... Spend an afternooon to figure this out.