fab-user
[Top][All Lists]
Advanced

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

Re: [Fab-user] Need debugging advice for host key error


From: Ben Abrams
Subject: Re: [Fab-user] Need debugging advice for host key error
Date: Wed, 10 Dec 2014 10:33:42 -0800

Carl,

Did someone regenerate the host key fingerprint? While its trivial to ignore it does open you up for a man in the middle. I would verify that everything is good before doing anything like this. Here is some documentation on ssh behavior with fabric: http://docs.fabfile.org/en/latest/usage/ssh.html

You have several options:
1. Fix your (or whatever user fab is running as) .ssh/known_hosts to not have the conflict (ie delete the offending key)
2. Change .ssh/config for host (list of hosts to use something like StrictHostKeyChecking=no or UserKnownHostsFile=/dev/null)
3. You could also do this by modifying the behavior of fabric to not care by setting env.disable_known_hosts=True

Hope this helps you

On Wed, Dec 10, 2014 at 10:20 AM, Waldbieser, Carl <address@hidden> wrote:

Use fabric to retrieve a bunch of files from a set of hosts each day.
However, one host started giving me the following error:

  Fatal error: Host key for $MYHOST did not match pre-existing key! Server's key was changed recently, or possible man-in-the-middle attack.
  Underlying exception:
      ('$MYHOST', <paramiko.rsakey.RSAKey object at 0x13e36d0>, <paramiko.rsakey.RSAKey object at 0x13e5490>)

(I changed the actual host name to $MYHOST).

I thought an admin had just re-IP'd the host.  But I could ssh to it without a warning-- how strange.
I removed the entry from my known_hosts file anyway.  I verified I could shell in.  Then I ran fabric and got the same result.
I can get the result by executing something as simple as:

  $ fab -H "$MYHOST" -- ls

The following short paramiko script seems to work, though:

  #! /usr/bin/env python

  import paramiko.client

  c = paramiko.client.SSHClient()
  c.load_system_host_keys()
  c.connect("ldap6")
  t = c.exec_command("ls")
  print t[1].read()
  c.close()

So I am not exactly sure where to look next.  Has anyone run into this puzzling behavior?

Thanks,
Carl Waldbieser
ITS System Programmer
Lafayette College


_______________________________________________
Fab-user mailing list
address@hidden
https://lists.nongnu.org/mailman/listinfo/fab-user



--
Ben Abrams
Computer Consultant

reply via email to

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