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
On Mon, 1 Apr 2019 at 08:12, Harald Dunkel <harald.dunkel at 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.
Hi Darren, On 4/1/19 10:41 AM, Darren Tucker wrote:> On Mon, 1 Apr 2019 at 08:12, Harald Dunkel <harald.dunkel at 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
Maybe Matching Threads
- IdentityFile vs IdentitiesOnly
- [Bug 3080] New: Document IdentityFile=none and clarify interaction of defaults with IdentitiesOnly
- [Bug 3681] New: SSH Agent Certificate Not Recognized with 'IdentitiesOnly' Configured
- ssh-agent and IdentityFile
- key management with ssh-agent, IdentityFile and info leakage