Te veel authenticatie fouten voor *gebruikersnaam*

Dit wordt meestal ** veroorzaakt door het per ongeluk aanbieden van meerdere ssh-sleutels** aan de server. De server zal elke sleutel weigeren nadat er te veel sleutels zijn aangeboden.

U kunt dit zelf zien door de -v vlag toe te voegen aan uw ssh commando om verbose-uitvoer te krijgen. U zult zien dat er een aantal sleutels wordt aangeboden, totdat de server de verbinding weigert met het commando ~/.ssh/config: “Te veel authenticatie fouten voor [gebruiker]”. Zonder verbose-modus ziet u alleen de dubbelzinnige boodschap “Verbindingsreset door peer”.

Om te voorkomen dat irrelevante sleutels worden aangeboden, moet u dit expliciet specificeren in elke host entry in het IdentitiesOnly (op de cliëntmachine) bestand door ssh-add -D toe te voegen als volgt:

Host www.somehost.com
  IdentityFile ~/.ssh/key_for_somehost_rsa
  IdentitiesOnly yes
  Port 22

Als u de ssh-agent gebruikt, helpt het om ssh uit te voeren om de identiteiten te wissen.

Indien je geen ssh-hosts configuratie gebruikt, moet je expliciet de juiste sleutel opgeven in het &007 commando zoals:

ssh -i some_id_rsa -o 'IdentitiesOnly yes' them@there:/path/

Aanwijzing: de ‘IdentiteitenAlleen ja’ parameter moest tussen aanhalingstekens staan.

of

ssh -i some_id_rsa -o IdentitiesOnly=yes them@there:/path/

Ik heb een makkelijkere manier gevonden om dit te doen (als je gebruik maakt van wachtwoord authenticatie): ssh -o PubkeyAuthentication=no username@hostname.com

Dit dwingt tot niet-sleutel authenticatie. Ik kon onmiddellijk inloggen. Referentie

Ik kreeg deze fout ook en vond dat het gebeurde b/c de server was geconfigureerd om tot 6 pogingen te accepteren:

/etc/ssh/sshd_config
...
...
#MaxAuthTries 6

Naast het instellen van de IdentitiesOnly yes in je ~/.ssh/config bestand heb je nog een paar andere opties.

1. Verhoog de MaxAuthTries (op de ssh-server)
2. 2. verwijder enkele sleutelparen die je hebt in je ~/.ssh/ directory & run ssh-add -D
3. koppel expliciet een sleutel aan een bepaalde host in je ~/.ssh/config bestand

Zoiets als:

host foo
hostname foo.example.com
IdentityFile /home/YOU/.ssh/foo

1. Is waarschijnlijk geen goede manier om het te doen, gezien het feit dat het je ssh server een beetje verzwakt omdat het nu meer sleutels accepteert in een bepaalde verbindingspoging. Denk aan brute kracht aanvalsvectoren hier.

2. Is een goede manier om te gaan, ervan uitgaande dat je sleutels hebt die niet nodig zijn en permanent kunnen worden verwijderd.

3. En de aanpak van het instellen van Identiteiten Alleen zijn waarschijnlijk de favoriete manieren om met dit probleem om te gaan!

Ik heb dit toegevoegd aan ~/.ssh/configureer dit:

Host *
IdentitiesOnly yes

Het schakelt de optie IdentitiesOnly=yes standaard in. Als u verbinding moet maken met een privé sleutel, moet u dit aangeven met de optie -i

Als u de volgende SSH-fout krijgt:

$ Received disconnect from host: 2: Too many authentication failures for root

Dit kan gebeuren als u (standaard op mijn systeem) vijf of meer DSA/RSA-identiteitsbestanden hebt opgeslagen in uw .ssh-map en als de ‘-i’ optie niet is opgegeven bij de opdrachtregel.

De ssh-client zal eerst proberen in te loggen met elke identiteit (privésleutel) en vervolgens vragen om authenticatie van het wachtwoord. Echter, sshd laat de verbinding vallen na vijf slechte aanmeldingspogingen (ook hier kan de standaardinstelling variëren).

Indien u een aantal private keys in uw .ssh directory heeft, kunt u “Public Key Authentication” uitschakelen op de opdrachtregel met het ‘-o’ optionele argument.

Bijvoorbeeld:

$ ssh -o PubkeyAuthentication=no root@host

Als u een wachtwoord heeft, en u wilt gewoon het wachtwoord gebruiken om in te loggen, dan is hier hoe u dat doet.

Om ALLEEN wachtwoordauthenticatie te gebruiken en NIET de Public-key te gebruiken, en NIET de enigszins misleidende “keyboard-interactive” (dat is een superset inclusief wachtwoord), kunt u dit doen vanaf de opdrachtregel:

ssh -o PreferredAuthentications=password user@example.com

Ga uit @David zeggen, voeg deze IdentitiesOnly yes toe aan uw .ssh/config, het doet hetzelfde als ssh -o PubkeyAuthentication=no.

Nadat u bent ingelogd, verwijdert u .ssh/authorized_keys. Ga nu terug naar de lokale machine en typ het volgende

cat ~/.ssh/id_rsa.pub | ssh -o PubkeyAuthentication=no user@IP_ADDR 'cat >> .ssh/authorized_keys'. Dit zou uw ssh opnieuw moeten activeren met de publieke sleutel

Ik weet dat dit een oude draad is, maar ik wilde hier alleen maar toevoegen dat ik dezelfde foutmelding tegenkwam, maar het werd veroorzaakt door de eigenaar van de .ssh-map die root was in plaats van de gebruiker die de sleutel gebruikte. Ik heb het probleem verholpen door de volgende commando’s uit te voeren:

sudo chown -R user:user /home/user/.ssh

Ik heb er ook voor gezorgd dat de toestemmingen in de .ssh-map correct waren:

sudo chmod 700 /home/user/.ssh

De bestanden in de .ssh-map zouden de toestemming moeten hebben van 600:

sudo chmod 600 /home/user/.ssh/authorized_keys
``` &001

In mijn geval was het probleem de mapmachtigingen. Dit heeft het voor mij opgelost:

$ chmod 750 ~;chmod 700 ~/.ssh

Dit was een leuke voor mij. Het blijkt dat ik mijn wachtwoord lokaal heb veranderd terwijl ik in een andere lokalisatiemodus zat dan een toetsenbord dat ik gebruikte om op afstand in te loggen. Dit maakte mijn wachtwoord in feite anders dan wat ik dacht dat het was waarschijnlijk omdat een van mijn speciale tekens anders was dan wat het toetsenbord zei dat het was.

Te veel authenticatie fouten

Dit bericht wordt veroorzaakt door te veel mislukte authenticatiepogingen gezien de toegestane limieten die worden afgedwongen op de externe SSH-server. Dit betekent mogelijk dat je te veel identiteiten hebt toegevoegd in de SSH-agent.

Hier zijn enkele suggesties:

• Voeg -v toe om te zien of dat het geval is (je hebt te veel identiteiten gebruikt).
• Lijst met toegevoegde identiteiten door ssh-add -l.
• Verwijder falende identiteit van de agent door: ssh-add -d.
• U kunt ook alle identiteiten verwijderen door ssh-add -D en alleen relevante identiteiten opnieuw toevoegen.

• Als u toegang heeft tot de SSH-server, vinkt u de optie MaxAuthTries aan (zie: man sshd_config ).

• Als dit niet helpt, controleer dan of u de juiste referenties of het juiste bestand gebruikt.

Ik had mijn publieke sleutel in .ssh/authorized_keys2, maar de server was geconfigureerd om alleen .ssh/authorized_keys te lezen:

# The default is to check both .ssh/authorized_keys and .ssh/authorized_keys2
# but this is overridden so installations will only check .ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys

Na het verplaatsen van mijn bestand naar .ssh/authorized_keys kan ik succesvol inloggen met mijn sleutel.

In mijn geval gebeurde het omdat ik de gebruikersnaam “ubuntu” gebruikte, maar de gebruikersnaam in dit geval was “ec2-user”

Nadat ik deed wat “John T” suggereerde, kreeg ik deze fout:

Toestemming geweigerd (publickey).

Toen vond ik de oplossing (d.w.z. het veranderen van de gebruikersnaam in “ec2-user”) in dit antwoord: https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue ](https://stackoverflow.com/questions/1454629/aws-ssh-access-permission-denied-publickey-issue)

Dit bericht kan verschijnen als de juiste gebruikersnaam en het juiste wachtwoord niet zijn ingevoerd.

Controleer eerst of de gebruiker in de lijst staat:

vim /etc/passwd