Ordering of key offers with "ssh -i"

[Tim Jackson]

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