ssh: Received disconnect from xx.yy.zz.aa: 2: Too many authentication failures for XXXX

Bug #1195911 reported by Lars Noodén
14
This bug affects 3 people
Affects Status Importance Assigned to Milestone
GNOME Keyring
Confirmed
Medium
gnome-keyring (Ubuntu)
Triaged
High
Unassigned

Bug Description

When trying to connect using ssh, I get this error:

 Received disconnect from xx.yy.zz.aa: 2: Too
        many authentication failures for XXXX

It appears that for some reason Lubuntu's agent somehow arbitrarily
pulls in some keys and, despite not being asked to, tries to use them
for authentication and won't let me try the password.

If I list the keys in the agent (ssh-add -L) then it lists a bunch of public
keys, none of which I put there, none of which should be there. If
anything there should be private keys in the agent. If I remove the
keys (ssh-add -D) then they are still there when I check again.

Looking at the output for the server, it looks like it keeps trying keys
until the max limit for failed logins is reached.

The problem can be made to go away by uninstalling gnome-keyring and rebooting or by clearing ~/.ssh/ of keys.

The problem can be created by adding 6 or more keys to ~/.ssh/ and then trying to connect with ssh, say to localhost.

  cd ~/.ssh/
  ssh 127.0.0.1
  ssh-keygen -P '' -f test_key_1
  ssh-keygen -P '' -f test_key_2
  ssh-keygen -P '' -f test_key_3
  ssh-keygen -P '' -f test_key_4
  ssh-keygen -P '' -f test_key_5
  ssh 127.0.0.1
  ssh-keygen -P '' -f test_key_6
  ssh 127.0.0.1
  rm test_key_6
  ssh 127.0.0.1

I'm not sure if this is a security vulnerability.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: gnome-keyring 3.8.2-0ubuntu3
ProcVersionSignature: Ubuntu 3.9.0-7.15-generic 3.9.7
Uname: Linux 3.9.0-7-generic x86_64
ApportVersion: 2.10.2-0ubuntu2
Architecture: amd64
Date: Sat Jun 29 00:52:05 2013
InstallationDate: Installed on 2013-06-21 (7 days ago)
InstallationMedia: Lubuntu 13.10 "Saucy Salamander" - Alpha amd64+mac (20130620)
MarkForUpload: True
SourcePackage: gnome-keyring
UpgradeStatus: No upgrade log present (probably fresh install)

Revision history for this message
Lars Noodén (larsnooden) wrote :
Revision history for this message
Lars Noodén (larsnooden) wrote :

This seems to be partially fixed in Saucy now. Identities are not getting automatically added to the agent. However, if six keys are added to the agent manually, it then still is impossible to authenticate using a seventh key either added to the agent or pointed to manually.

Revision history for this message
Lars Noodén (larsnooden) wrote :

While it appears not to be a problem in Lubuntu, it is still a problem in Ubuntu 13.10.

$ lsb_release -r
Release: 13.10

There are really two problems. One is that the keyring or something snarfs up the keys without asking and then offers all of them when trying to connect. The other is that there is no negotiation between the ssh client and server about which key to offer.

Revision history for this message
Lars Noodén (larsnooden) wrote :

This bug also messes with tools like FileZilla, preventing it from authenticating with a password. The keyes get tried first, even if they aren't keys for that server, so that it fails before it can even get around to trying the password.

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in gnome-keyring (Ubuntu):
status: New → Confirmed
Revision history for this message
Lars Noodén (larsnooden) wrote :

Seems to be back with 14.04

$ lsb_release -rd
Description: Ubuntu 14.04 LTS
Release: 14.04

Changed in gnome-keyring (Ubuntu):
importance: Undecided → High
Changed in gnome-keyring (Ubuntu):
status: Confirmed → Triaged
Changed in gnome-keyring:
importance: Unknown → Medium
status: Unknown → Confirmed
Revision history for this message
Lars Noodén (larsnooden) wrote :

I see this bug is still open. One work-around exists where ~/.ssh/config is used. Make an entry there for the host (or range of hosts using a pattern) and assign the right key using IdentityFile while also setting IdentitiesOnly to "yes". Both parts are needed for the work-around.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.