If you do some like this, you'll be victim of some attacks like man in the middle, etc.
I'm sorry for my english =)
----- Mensaje original -----
De: Peter Norton pn+chef-list@knewton.com
Enviado: martes, 17 de abril de 2012 2:22
Para: chef@lists.opscode.com
Asunto: [chef] Re: Re: Why does knife sometime decide to bomb out?
How is that disabled? I find that especially when dealing with ec2 instances this is a huge nuisance. Disabling strict host key checking in general (per Chef Support for Automation & DevOps | Chef) seems to miss how there are two use cases. In one, in general, I don't want ssh to ssh into a host whose host key has changed. However with knife I am sure that amazon has given me an address and I should just ignore any host key conflicts and bootstrap.
It seems that even if the option can't be manipulated directly in the Net::SSH API (I'm not sure if it can or can't) it'd be nice to be able to default it to having the known_hosts file = /dev/null when using knife, e.g. per http://net-ssh.github.com/ssh/v2/api/classes/Net/SSH/Config.html.
-Peter
On Tue, Apr 17, 2012 at 1:11 AM, Daniel DeLeo dan@kallistec.com wrote:
On Monday, April 16, 2012 at 9:22 PM, David Montgomery wrote:
Hi,
Per the below....this happens about 10% of the time. Why does this
happen? This just happened three times in a row.
There is no difference at all when bootstrapping on a cloud provider e.g.
AWS. You need to not have a host key in known_hosts to bootstrap the
server since conflicts will kill the bootstrap. If there is a MITM at this
point in the process, then it's their public key that's being stored
whether or not you use host key checking.
How is that disabled? I find that especially when dealing with ec2
instances this is a huge nuisance. Disabling strict host key checking in
general (per Chef Support for Automation & DevOps | Chef)
seems to miss how there are two use cases. In one, in general, I don't
want ssh to ssh into a host whose host key has changed. However with knife
I am sure that amazon has given me an address and I should just ignore any
host key conflicts and bootstrap.
It seems that even if the option can't be manipulated directly in the
Net::SSH API (I'm not sure if it can or can't) it'd be nice to be able to
default it to having the known_hosts file = /dev/null when using knife,
e.g. per http://net-ssh.github.com/ssh/v2/api/classes/Net/SSH/Config.html.
-Peter
On Tue, Apr 17, 2012 at 1:11 AM, Daniel DeLeo dan@kallistec.com wrote:
On Monday, April 16, 2012 at 9:22 PM, David Montgomery wrote:
Hi,
Per the below...this happens about 10% of the time. Why does this
There is no difference at all when bootstrapping on a cloud provider e.g. AWS. You need to not have a host key in known_hosts to bootstrap the server since conflicts will kill the bootstrap. If there is a MITM at this point in the process, then it's their public key that's being stored whether or not you use host key checking.
Note that all providers will recycle old IP addresses. So, if you create and destroy enough nodes, you can be guaranteed that sooner or later you will run into a new node that has been assigned the IP address of a node you used to have a while back. The more nodes you create & destroy, the more likely that will happen sooner rather than later.
The best solution here is that when you destroy an old node, you purge all references to it, everywhere. In addition to deleting the node, you also delete the corresponding client that Chef created, you delete all references to the ssh keys for that node, you use the provider-specific plugins to make sure that the system is actually gone as opposed to simply making it unmanaged by Chef, you need to delete all entries related to that node from your DNS, etc....
IMO, there needs to be a better solution to this problem so that you can purge all references to any given node(s) with a single command. But we're not there yet.