Mailing List Archive: OpenSSH: Dev

Ordering of key offers with "ssh -i"

Index | Next | Previous | View Threaded

lists at timj

Jul 25, 2009, 6:21 AM

Post #1 of 3 (865 views)
Permalink

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
...
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
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

dtucker at zip

Jul 25, 2009, 4:41 PM

Post #2 of 3 (777 views)
Permalink

Re: Ordering of key offers with "ssh -i" [In reply to]

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.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

lists at timj

Jul 26, 2009, 1:57 AM

Post #3 of 3 (781 views)
Permalink

Re: Ordering of key offers with "ssh -i" [In reply to]

On 26/07/09 00:41, Darren Tucker wrote:

> Tim Jackson wrote:

>> 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 ?

> What you're looking for is, from ssh_config(5):
> IdentitiesOnly

That does help - thanks. I overlooked that as it only mentioned the config
files rather than interactive options. Still, the ordering seems strange. Even
without IdentitiesOnly, wouldn't it make sense to try the specified key(s)
first, and only then fall back to other keys provided by the agent?

Tim
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads