Incorrect behavior re: trying multiple or specific keys

Description

IRC user up_the_irons is having an edge case problem with SSH keys and (I presume) Paramiko:

Background

• He has two SSH keys in ~/.ssh/, an older one and a newer one.
• Both keys are loaded up into his ssh-agent.
• The server in question only has the newer key on its end; the older key is actually out of date in general.

Details of problem

• In normal SSH, without any -i options being specified, SSH appears to try the first, old key, find that it fails, then tries the second, newer key, and makes the connection.
  • During this process, no authentication prompts appear whatsoever – the agent is being used.
  • Because it’s not prompting him at any point, everything appears to work fine, despite the “bad” key being in place.
• In normal Fabric use, it appears to try the old key (prompting with a GUI password prompt.)
  • The user cancels that prompt since it’s not the right key
  • Fabric then spits out the “user” password prompt (user@host) on the CLI
  • This prompt appears to truly be using password-based auth, as the passphrase for the 2nd/good key does not work. (The remote system is pubkey only so we can only test this via passphrase failure)
• When attempting to force use of just the one good key with fab -i, it still GUI-prompts him for the passphrase of the bad key.
  • When he cancels that prompt, Fabric again presents the user@host password prompt, as before.
  • However, this prompt is actually the prompt for the good key, and if its passphrase is entered, it unlocks and is used (and everything works)

Take-away

• The behavior here is almost the same in both cases (bad key tried/denied, then a user@host prompt is displayed)
• Without -i, Fabric/Paramiko appear to only be considering the first key found, and after that key fails (is cancelled/denied by the user) it skips directly to password authentication.
  • What it should be doing: Trying all possible keys – either all keys the agent knows of (if that’s how the agent is supposed to work – it may simply be a dumb passphrase rememberer, I don’t recall,) or all keys in the appropriate key directories.
• With -i, it will eventually try the key specified with -i, but not after trying the bad key anyways, and it uses the wrong prompt (which would be issue #85 at work)
  • What it should be doing: Using only the key or keys specified with -i (which is repeatable) and ignoring all other keys. (At least, assuming that this is how ssh -i behaves – we should ideally be mimicking that.)
• A tertiary issue is why it’s prompting him with Fab and not with regular SSH, but this may just be an agent quirk and is hopefully not related to the other two issues.

---

Originally submitted by Jeff Forcier (bitprophet) on 2010-03-09 at 09:06pm EST

Relations

• Related to #85: Prompts for “passphrase” instead of “password” in some situations

[byoms23]

I was trying to perform a run without password (as described in #484) on EC2 server using a private key (created using the RSA algorithm, a private.pem file).

I noticed that the problem was that Fabric wasn’t setting the right authentication method for this configuration into Paramiko. I tried to create the connection manually and I obtained the same error: Authentication failed.. I upgraded Paramiko to version 2.0.0 and nothing. Finally, I found this gist: https://gist.github.com/batok/2352501 and I could connect manually and run the command.

I ended up with this:

import paramiko
k = paramiko.RSAKey.from_private_key_file("{{/path/to/private.pem}}")
c = paramiko.SSHClient()
c.set_missing_host_key_policy(paramiko.AutoAddPolicy())
c.connect( hostname = "{{ec2_server_name}}", username = "ubuntu", pkey = k )
stdin, stdout, stderr = c.exec_command("uname");
print(stdout.read())
c.close()

[RajatGoyal]

I found that for key without passpharse, it worked fine if I provided user string instead of a list:

For example: works fine if i use:

env.user = ‘ubuntu’

instead of env.user = [‘ubuntu’]

(all my other evn params are also strings)