[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Fab-user] EC2 host keys

From: s s
Subject: Re: [Fab-user] EC2 host keys
Date: Sat, 9 May 2009 14:06:51 -0400

Anyone interested in writing this up as a real use-case so we can start with a test suite so we get this right and have some examples of how it can/will be used?

I'll be happy to do some editing and write some test code if someone will just get the basic use-case up on the wiki as a starting point.


On May 9, 2009, at 12:49 PM, Jeff Forcier wrote:

Hi Pat,

First, I think this partially falls under an existing TODO item, which
I plan to have in place for 1.0 and hopefully 0.9: honoring any
.ssh/config options that we have functionality for. In this case,
Fabric would probably check your StrictHostKeyChecking option and use
that to override the default value of env.reject_unknown_keys.

Secondly, I've read over your use case and I may be missing something:
as things currently are, why isn't setting env.reject_unknown_keys to
False good enough? Simply loading the host key list is not what drives
the reject/don't-reject decision: that's driven by the policy given to

I just double checked this by tweaking a (static) IP in my known_hosts
file so that it was incorrect, then ensuring my fabfile had
env.reject_unknown_keys = False. When connecting to that server, the
"new" IP was added as a new entry to my known_hosts and the connection
was created without issue.

Is the problem that you don't want the new IPs added to your host list, or what?


P.S. In checking "man ssh_config" I found that there's an even more
specific setting, CheckHostIP, which sounds like it fits your
situation better than StrictHostKeyChecking. Unfortunately, Paramiko
doesn't appear to support that level of granularity, so we're out of
luck with that for now. Wanted to mention it anyways, though, in case
you weren't aware of it, for non-Fabric use.

On Sat, May 9, 2009 at 11:10 AM, Patrick J McNerthney
<address@hidden> wrote:
I have an issue with Amazon EC2 instances where ssh host keys have been saved in .ssh/known_hosts but are incompatible with an EC2 instance ip address. This occurs when the ip address has been reassigned to a new EC2
instance.  So the basic sequence of events are:

o Start an EC2 instance which is assigned an ip address.
o ssh to that ip address and that server's ssh key is associated with that
ip address in the known_hosts file.
o Terminate that EC2 instance.
o A new EC2 instance is started and it happens to get assigned the same ip

At this point, if I first ssh to it, I have ssh configured with
StrictHostKeyChecking set to no, so ssh will emit a warning about this ip
address having a new key, but still allows me to continue.

However, if at this point I try to use Fabric to execute some commands, it always will fail. This is because the SSHClient.load_system_host_keys is always called, causing the connection to fail if there is an incompatibility
between the ip address and the server key.

I have addressed this in my own fork here:

What this does is replace this:

  if not env.reject_unknown_keys:

with this:

  if env.reject_unknown_keys:

I also considered using another env setting value to control this, but my conclusion that this behavior is in fact in line with the implied behavior of the "reject_unknown_keys" name. In other words, the list of known keys should only be loaded if the intention is to reject those keys that are not

Pat McNerthney
ClearPoint Metrics, Inc.

Fab-user mailing list

Fab-user mailing list

reply via email to

[Prev in Thread] Current Thread [Next in Thread]