openssh unix dev - Jul 2009 - Ordering of key offers with "ssh -i"

Hi

Is it expected behaviour that when using "ssh -i", the key specified
in the
"-i" option is only sent to the server *after* trying all other keys
in ~/.ssh
? I couldn't find anything about this in the manual, and it seems like 
surprising behaviour to me. It can be the cause of unexpected failures in some 
cases, if a server has MaxAuthTries set to a value which is less than the 
number of keys that the client has available.

I'm using OpenSSH 5.2p1 on Fedora, although I've recompiled without 
Fedora-specific patches to eliminate those as the cause.

Example output where I have "key1", "key2" and
"key3" in ~/.ssh, but I want to
use a special key "specialkey" to log in to a particular server (which
has
MaxAuthTries=3):

$ ssh -i specialkey joe at ssh.example.com
...
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: key1
debug1: Authentications that can continue: publickey
debug1: Offering public key: key2
debug1: Authentications that can continue: publickey
debug1: Offering public key: key3
Received disconnect from X.Y.Z.A: 2: Too many authentication failures for joe

In this case, the client never gets to try "specialkey", despite it
being
explicitly specified.

If I temporarily remove key3:

debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering public key: key1
debug1: Authentications that can continue: publickey
debug1: Offering public key: key2
debug1: Authentications that can continue: publickey
debug1: Offering public key: /path/to/specialkey

[success]

It seems to be something to do with the agent, because the problem doesn't 
occur if you set SSH_AUTH_SOCK to an empty string before running "ssh
-i".

Thanks,

Tim

Tim Jackson wrote:
> Hi
> 
> Is it expected behaviour that when using "ssh -i", the key
specified in
> the "-i" option is only sent to the server *after* trying all
other keys
> in ~/.ssh ? I couldn't find anything about this in the manual, and it 
> seems like surprising behaviour to me. It can be the cause of unexpected 
> failures in some cases, if a server has MaxAuthTries set to a value 
> which is less than the number of keys that the client has available.
What you're looking for is, from ssh_config(5):

  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''.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
     Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.