Mailing List Archive

IdentityFile vs IdentitiesOnly
Hi folks,

I've got a moderate number of keys in my ssh config file.
Problem: Very often I get an error message like

Received disconnect from 2001:db8::8077 port 999:2: Too many authentication failures
Authentication failed.

AFAIU the ssh-agent is to blame here, trying out all keys
he has ever seen. This conflicts with MaxAuthTries 6, set by
default on the peer.

The solution seems to be to set IdentitiesOnly, e.g.:

:
:
Host host.example.com 2001:db8::8077
IdentityFile ~/.ssh/id_ecdsa
IdentitiesOnly yes
Port 999
:
:

Shouldn't an explicit IdentityFile (as in the example) *imply*
IdentitiesOnly?


Every helpful comment is highly appreciated
Harri
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: IdentityFile vs IdentitiesOnly [ In reply to ]
On Mon, 1 Apr 2019 at 08:12, Harald Dunkel <harald.dunkel@aixigo.de> wrote:
> I've got a moderate number of keys in my ssh config file.
> Problem: Very often I get an error message like
[...]
> The solution seems to be to set IdentitiesOnly, e.g.:
[...]
> Shouldn't an explicit IdentityFile (as in the example) *imply*
> IdentitiesOnly?

Probably not. What version are you using? Is this key in the agent
or do you need to supply a passphrase?

For recent versions each key has an annotation that says whether or
not the key file was supplied by the user (ie either in the config
file or on the command line). It should prefer keys that were both
specified in the config *and* in the agent, and it should try them in
the order they were supplied. If you're running into a situation
where this doesn't work, then it is likely you are either using a
version prior to that behaviour or there's a bug in it.

Can you post the subset of your config file(s) that causes the
behaviour? You'll need to include any Host entries that match the
system you're experiencing the problem with (including any wildcards a
and the implicit "Host *" at the start for the file) any IdentityFile
directives, but nothing else. (You'll also need to consider entries
in the host-wide ssh_config, if you have any).

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: IdentityFile vs IdentitiesOnly [ In reply to ]
Hi Darren,

On 4/1/19 10:41 AM, Darren Tucker wrote:
> On Mon, 1 Apr 2019 at 08:12, Harald Dunkel <harald.dunkel@aixigo.de> wrote:
>> I've got a moderate number of keys in my ssh config file.
>> Problem: Very often I get an error message like
> [...]
>> The solution seems to be to set IdentitiesOnly, e.g.:
> [...]
>> Shouldn't an explicit IdentityFile (as in the example) *imply*
>> IdentitiesOnly?
>
> Probably not. What version are you using? Is this key in the agent
> or do you need to supply a passphrase?
>

My client is 7.4 or newer, but the peers might be many years old.
The oldest I found was version 6.0 on AIX.

"AddKeysToAgent yes" is set.

> For recent versions each key has an annotation that says whether or
> not the key file was supplied by the user (ie either in the config
> file or on the command line). It should prefer keys that were both
> specified in the config *and* in the agent, and it should try them in
> the order they were supplied. If you're running into a situation
> where this doesn't work, then it is likely you are either using a
> version prior to that behaviour or there's a bug in it.
>

??? I have seen ssh-agent as a transparen means to avoid the same
password dialog again and again. ssh chooses which keys to try,
looking at the host name/IP address on the command line. The "Host"
constructs in the config file make sure that options set for one
host don't affect others.

You mean this not the case for IdentityFile? If I drop ssh-agent
support, will ssh try *other* keys in a different sequence?


Regards
Harri
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: IdentityFile vs IdentitiesOnly [ In reply to ]
On Tue, 2 Apr 2019 at 14:50, Harald Dunkel <harald.dunkel@aixigo.de> wrote:
>
[...]
> My client is 7.4 or newer, but the peers might be many years old.
> The oldest I found was version 6.0 on AIX.

In this case the version of the server doesn't matter, only the client.

> "AddKeysToAgent yes" is set.

Ah, this might be the reason, see below.

[...]
> ??? I have seen ssh-agent as a transparen means to avoid the same
> password dialog again and again. ssh chooses which keys to try,
[...]

That's true, however the it chooses the order[0] in which to try them
based in part on which ones are already in the agent.

> The "Host" constructs in the config file make sure that options set
> for one host don't affect others.

It's a bit more complicated than that. For example you can have
wildcards that match multiple hosts, and some directives are not
strict overrides.

> You mean this not the case for IdentityFile?

IdentityFile directives append to a list[1], and by default the list
has multiple entries for the various key types. Quoting
ssh_config(5):

It is possible to have multiple identity files specified in con?
figuration files; all these identities will be tried in sequence.
Multiple IdentityFile directives will add to the list of identi?
ties tried (this behaviour differs from that of other configura?
tion directives).

> If I drop ssh-agent support, will ssh try *other* keys in a different sequence?

Possibly. it'll depend on a few variables.

[0] https://github.com/openssh/openssh-portable/blob/master/sshconnect2.c#L1506
[1] https://github.com/openssh/openssh-portable/blob/master/readconf.c#L1060

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: IdentityFile vs IdentitiesOnly [ In reply to ]
Hi Darren,

if I got this right, then using ssh-agent some memory effect appears
to sneak in, besides the remembered passphrases. IMHO thats the bad
part. The ssh client should stay in control which keys are tried in
which sequence.

Is there a risk that a key pair with a "poor" cipher is tried first,
even though a key pair with a better cipher is mentioned first in the
config file?


Thanx for your detailed response

Harri
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: IdentityFile vs IdentitiesOnly [ In reply to ]
On Wed, 3 Apr 2019 at 09:51, Harald Dunkel <harald.dunkel@aixigo.de> wrote:
> Hi Darren,
>
> if I got this right, then using ssh-agent some memory effect appears
> to sneak in, besides the remembered passphrases.

The "memory effect" is probably AddKeysToAgent which I alluded to in
my previous message. The first time you access that specific host,
the key is not in the agent so the keys that are cond in the agent are
tried first. The second time it's in the agent so it's amongst the
first tried.

BTW the agent does not remember passphrases. It decrypts and
remembers the unencrypted private key, and it never discloses the
private key, it only signs challenges with it when asked to.

> IMHO thats the bad part. The ssh client should stay in control which keys are tried in
> which sequence.

The client is in control. Under most circumstances the keys loaded in
the agent are preferable because they do not require entering a
passphrase, and in the cases where this isn't desired there's the
IdentitiesOnly override you already found.

> Is there a risk that a key pair with a "poor" cipher is tried first,
> even though a key pair with a better cipher is mentioned first in the
> config file?

If by "ciphers" you mean public key algorithm types then no.

The keys are public/private key pairs and the server never knows the
private key. Basically the way it works is the client asks "if I
prove I have the private key corresponding to this public key will you
let me in?", the server says yes or no, and if it says yes the client
proves it does by signing a challenge with the private key and sending
it to the server, which verifies the signature.

Separately the private keys are usually encrypted with a symmetric
cipher on the client side, but that is an implementation detail that
the server has no visibility into.

> Thanx for your detailed response

You're welcome.

--
Darren Tucker (dtucker at dtucker.net)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new)
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev