There is a problem with (portable) OpenSSHv5.0 with regards to key selection. In the past, with SCP, you could use the "identity key file '-i'" parameter to select THE specific key to be used for the SCP transaction, and it didn't matter WHAT TYPE of key (RSA/DSA) was used. 1) According to the MANual page for V5.0 SSH: -i identity_file Selects the file from which the identity (private key) for RSA authentication is read. This option is directly passed to ssh(1). NOTE the explicit specification of RSA! 2) when using v5.0 "-i" parameter, the selected key file does not appear FIRST in any list of keys (joined from an SSH "config" file), nor does it completed replace/supplant any key list available through any SSH configuration file (global or local); in this example - the "MYdesignatedKEY" key was associated with the "-i" parameter: debug2: key: /<path>/.ssh/id_rsa (0x813ceXX) debug2: key: /<path>/.ssh/id_dsa (0x813ceXX) debug2: key: /<path>/.ssh/MYdesignatedKEY (0xgarbale) debug2: key: /<path>/.ssh/id_dsa_new (0x813ceXX) debug2: key: /<path>/.ssh/id_rsa_new (0x813cfXX) 3) In order to ignore/bypass ANY SSH config file, you have to supply an EXISTING file, even if empty, with the "-F" parameter! 4) Last but not least, when selecting a specific identity file using the "-o ssh option" parameter, and an empty "SSH config file", SSHDv5.0 STILL refuses to use the specified key: debug2: key: /<path>/.ssh/MYdesignatedKEY (0xgarble0) debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Next authentication method: publickey debug1: Offering public key: debug2: we sent a publickey packet, wait for reply debug1: Server accepts key: pkalg ssh-rsa blen 277 debug2: input_userauth_pk_ok: fp GG:AA:RR:BB:LL:EE:e3:c8:b1:2f:af:5b:0f:d7:dc:a7 debug1: Authentication succeeded (publickey). fingerprint for MYdesignatedKEY.pub: GG:AA:RR:BB:LL:EE:c5:5f:6d:1b:af:51:0d:ae:f0:30 fingerprint for default "id_rsa.pub": GG:AA:RR:BB:LL:EE:e3:c8:b1:2f:af:5b:0f:d7:dc:a7
I have fixed the scp manpage: in OpenSSH-5.1 it will read "... the identity (private key) for public key authentication". Regarding #3, you may specify "-F/dev/null" to avoid reading a config file. I can't replicate your issues #2 and #4. Make sure that you have no configuration interfering with your tests and no agent. E.g.: env SSH_AUTH_SOCK= ssh -F/dev/null -vv -ixxx -i ~/.ssh/id_rsa myhost will try key "xxx" before it tries id_rsa. If an agent is present, keys in it are always tried first
After many more tests with/without configuration files, with/without "default keys" (eg; id_dsa/id_rsa), with/without new/empty user_ssh directories, ...., I think that I have found the fundamental problem. Despite what the MANual page for 'ssh_config' says, ssh(1) obtains configuration data from the following sources in the fol- lowing order: 1. command-line options 2. user's configuration file (~/.ssh/config) 3. system-wide configuration file (/etc/ssh/ssh_config) For each parameter, the first obtained value will be used. IF there is one or more of the "default keys" that EXIST in the user's SSH "home" directory, WHETHER or not there are ANY SSH system/user configuration files, the default keys will ALWAYS appear FIRST in the list of keys to be offered, EVEN when there is a key list provided as command line arguments. IF the remote/target site has the requisite components of the "default keys" in its target SSH "authorized_keys" file, THEN THOSE "default keys" will be offered and accepted FIRST and any command line key list will be effectively ignored. Since these "default keys" (names) are built into SSH/SCP/SSHD, they SHOULD be at the END of any collected/derived key list, unless also provided as command line parameters, in which case - they will appear twice in the derived key list. My workaround - delete all "id_dsa/id_rsa" (user) key files, "delete" the system-wide SSH configuration file, create a new USER SSH config file that has JUST the key files specific to single remote hosts. Do NOT have a "host wildcard" entry in the user SSH configuration file.
Created attachment 1582 [details] Script to help demonstrate bug in "ssh -i id_rsa-xxx ..." Execute this script several times with different arguments. Example: sshd-bug.sh TEST1 sshd-bug.sh TEST2 sshd-bug.sh TEST3 Intermix execution of the basic ssh command. Example: ssh -t -i /home/randy/.ssh/id_rsa-BUG-TEST2 localhost The commands will echo the last tunnel that was created, not the tunnel explicitly referenced by "-i .../id_rsa-BUG-...". If a primitive Linux console is used, the correct tunnel is used.
Last week I submitted bug 302252 to https://bugs.launchpad.net I suspect it is related to this 1483 item in https://bugzilla.mindrot.org The wrong identity key is being used by "ssh -i id_rsa-xxx ...". Miller's comment above "If an agent is present, keys in it are always tried first" really caught my attention. The problem I reported includes a bizarre behavior, where it fails when "ssh -i id_rsa-xxx ..." is executed in X-windows, but works okay when executed in a primitive Linux console (obtained via ctl-alt-F5). My knowledge of ssh and agents is very limited. Does "agent" behavior change when running within X-windows versus a primitive Linux console? How do I disable agents on Ubuntu? See the "sshd-bug.sh" script... attached to another post here. Randy
Does adding -o IdentitiesOnly=yes help? It should force ssh to only use the identities provided on the command line or config file: IdentitiesOnly Specifies that ssh(1) should only use the authentication identity files configured in the ssh_config files, even if ssh-agent(1) offers more identities. The argument to this keyword must be "yes" or "no". This option is intended for situations where ssh-agent offers many different identities. The default is "no".
6 months with no followup == no bug
Move resolved bugs to CLOSED after 5.7 release