SSH Too many authentication failures oplossen

Wat "Too many authentication failures" betekent

"Too many authentication failures" betekent dat uw SSH-client de server meer sleutels heeft aangeboden dan deze bereid was te controleren, waardoor de server de verbinding verbrak voordat uw juiste sleutel kon worden geprobeerd. Dit is bijna altijd een probleem aan de kant van de client. De sleutel staat op uw schijf, de server heeft deze in authorized_keys, maar beide feiten helpen niet omdat de verbinding te vroeg werd beëindigd.

Dit is de keten van gebeurtenissen. ssh-agent bevat elke private key die u erin heeft geladen. Uw client biedt deze sleutels één voor één aan de server aan, omdat de client niet kan weten welke sleutel het account accepteert. De server wijst elke sleutel die niet in authorized_keys staat af en telt elke afwijzing als een mislukte authenticatiepoging. MaxAuthTries in sshd_config beperkt het aantal mislukkingen dat per verbinding is toegestaan. De standaardwaarde is 6. Als uw agent tien sleutels bevat en de juiste sleutel staat op de achtste plek, verbreekt de server de verbinding voordat deze bij de juiste sleutel aankomt.

De oplossing is dus om de client slechts één sleutel te laten aanbieden: de juiste.

Wat de server telt en waar MaxAuthTries van toepassing is

Authenticatie met een public key begint als een raadspel. De client stuurt een public key en vraagt of de server een handtekening die daarmee is gemaakt, accepteert. De server antwoordt met ja of nee. Een "nee" is een mislukte poging, precies zoals een foutief wachtwoord.

De sshd_config(5) manual page beschrijft de limiet: "Specificeert het maximale aantal toegestane authenticatiepogingen per verbinding. Zodra het aantal mislukkingen de helft van deze waarde bereikt, worden aanvullende mislukkingen gelogd. De standaardwaarde is 6."

Zes pogingen is ruim voldoende voor iemand die een wachtwoord typt. Het is niet veel voor een agent die tien keys beheert. Zodra het aantal mislukkingen de limiet overschrijdt, verbreekt sshd de verbinding en schrijft een regel zoals deze naar het systeemlogboek:

error: maximum authentication attempts exceeded for deploy from 203.0.113.10 port 51292 ssh2

Uw client toont de andere helft van dezelfde gebeurtenis:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures
Disconnected from 203.0.113.10 port 22

Dit is een ander type fout dan de SSH permission denied (publickey) fout. In dat geval heeft de server alles bekeken wat u aanbood en niets daarvan geaccepteerd. Hier is de server gestopt met kijken. Het verwarren van deze twee situaties is de reden waarom mensen een hele middag besteden aan het opnieuw kopiëren van een key die al correct was.

Waarom dezelfde sleutel wel werkt vanaf de laptop van uw collega

Er is geen verschil in de sleutel of de server. Hun agent beheert twee sleutels en die van u twaalf. Het aanbod dat voor hen als eerste aankomt, komt voor u als negende aan, en tegen die tijd is de verbinding al verbroken.

Het aantal groeit ongemerkt. AddKeysToAgent yes in ~/.ssh/config voegt elke sleutel die u gebruikt toe aan de agent en laat deze daar staan. Desktop-keyring-agents, zoals GNOME Keyring op Linux of de login-sleutelhanger op macOS, laden sleutels bij het inloggen zonder daarom te vragen. Voeg in de loop van een jaar een clientsleutel, een git-hostsleutel en een labsleutel toe, en op een dag weigert een server die altijd werkte u de toegang. Er is niets veranderd op de server. Uw agent is voller geworden.

Hoe u aanbiedingen bekijkt met ssh -v

Voer de falende verbinding uit met -v en lees de trace.

ssh -v deploy@203.0.113.10

Twee soorten regels zijn van belang. Will attempt key: somt de identiteiten op die de client heeft verzameld, in de volgorde waarin deze worden gebruikt. Offering public key: verschijnt eenmaal voor elke sleutel die daadwerkelijk naar de server wordt verzonden.

debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Will attempt key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent

Uw paden, sleuteltypes en vingerafdrukken zullen afwijken. Waar u op moet letten is het aantal Offering public key:-regels vóór de verbreking. Als de aanbiedingen voorbij komen en de sessie eindigt zonder dat uw beoogde sleutel ooit verschijnt, is de diagnose gesteld. Het woord agent aan het einde van een regel betekent dat de identiteit afkomstig is van ssh-agent. Het woord explicit betekent dat deze afkomstig is van een IdentityFile-regel of van -i op de opdrachtregel.

Vraag vervolgens aan de agent welke sleutels deze bevat:

ssh-add -l

Elke regel in de uitvoer is één geladen sleutel. Als de uitvoer The agent has no identities. toont, dan is de agent niet het probleem en moet u in plaats daarvan naar de IdentityFile-regels in ~/.ssh/config kijken. Als de uitvoer Could not open a connection to your authentication agent. toont, dan draait er geen agent en zijn de aanbiedingen afkomstig van uw standaard sleutelbestanden.

Oplossing 1: IdentitiesOnly met één sleutel per host

IdentitiesOnly yes instrueert ssh om uitsluitend de door u geconfigureerde identiteiten aan te bieden en de extra identiteiten die de agent aanbiedt te negeren. Combineer dit met een IdentityFile-regel en de client verstuurt slechts één aanbod.

Host vps
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/id_ed25519_vps
  IdentitiesOnly yes

Sla dit op in ~/.ssh/config en voer vervolgens chmod 600 ~/.ssh/config uit. Als een bestand schrijfbaar is voor de groep of voor iedereen, weigert ssh het uit te voeren met Bad owner or permissions on /home/you/.ssh/config. Nu biedt ssh vps één sleutel aan en zou ssh -v vps precies één Offering public key:-regel moeten tonen.

Twee details verrassen gebruikers hier vaak.

• IdentitiesOnly yes betekent op zichzelf niet "één sleutel". De standaard identiteitsbestanden tellen mee als geconfigureerde identiteiten, dus ssh probeert nog steeds ~/.ssh/id_ed25519, ~/.ssh/id_rsa en de andere standaardbestanden die het vindt. U heeft ook de IdentityFile-regel nodig.
• De agent voert nog steeds de ondertekening uit. IdentitiesOnly bepaalt welke sleutels worden aangeboden, niet wie ze ondertekent. Als de privésleutel die wordt genoemd door IdentityFile in de agent is geladen, produceert de agent de handtekening en wordt u nooit om een wachtwoordzin gevraagd. U kunt zelfs IdentityFile naar het bijbehorende .pub-bestand laten wijzen; dit doet u wanneer de privésleutel alleen in de agent of op een hardware-token staat.

Eén valkuil in ~/.ssh/config maakt deze oplossing stilletjes ongedaan. De meeste trefwoorden gebruiken de eerste gevonden waarde, en daarom horen specifieke Host-blokken boven Host * te staan. IdentityFile volgt die regel niet. De handleiding stelt: "Het is mogelijk om meerdere identiteitsbestanden op te geven in configuratiebestanden; al deze identiteiten worden achtereenvolgens geprobeerd." Een IdentityFile onder Host * wordt toegevoegd aan uw per-host-instelling, in plaats van deze te vervangen, waardoor een vergeten globale regel bij elke verbinding weer een extra aanbod toevoegt.

Als u een globaal vangnet wilt, stel dan alleen de vlag in, onderaan het bestand:

Host *
  IdentitiesOnly yes

Elke host heeft dan zijn eigen IdentityFile nodig, wat uiteindelijk het gewenste resultaat is. Het toewijzen van één sleutel per server maakt het bovendien mogelijk om later de toegang van een enkele machine in te trekken zonder alles opnieuw uit te geven. Het is de moeite waard om deze gewoonte vroeg aan te leren: zie hoe u SSH-sleutels per machine beheert.

Oplossing 2: de agent opschonen of herstarten

Als u de configuratie nog niet kunt bewerken, leeg dan de agent en laad alleen wat u nodig heeft.

ssh-add -l                    # list what is loaded
ssh-add -d ~/.ssh/id_rsa      # remove one key
ssh-add -D                    # remove every key
ssh-add ~/.ssh/id_ed25519_vps # load the one you need

Als de verbinding direct na ssh-add -D werkt, was de agent de oorzaak. Beschouw dit als een test en niet als een reparatie. Een desktop keyring agent laadt zijn sleutels opnieuw bij uw volgende aanmelding, waardoor het probleem morgen terugkeert. Een IdentitiesOnly-regel in ~/.ssh/config overleeft een herstart. Een lege agent niet.

U kunt een sleutel ook een levensduur meegeven zodat de agent deze automatisch voor u verwijdert:

ssh-add -t 1800 ~/.ssh/id_ed25519_vps

De sleutel wordt 1800 seconden na toevoeging verwijderd. De agent herstarten werkt ook; hoe u dit doet hangt af van hoe deze is gestart. Een ssh-agent die u zelf heeft gestart, stopt met ssh-agent -k. Als u deze uitvoert vanuit een door u geschreven systemd user unit, herstart die unit dan met systemctl --user restart <unit>. Een keyring agent herstart samen met uw desktopsessie.

Oplossing 3: het eenmalige commando voor een server die u zelden beheert

Voor een host die u niet aan uw configuratie toevoegt, kunt u dezelfde instellingen op de command line meegeven:

ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10

-i op zichzelf is de meest voorkomende onjuiste oplossing. -i voegt een sleutel toe aan de lijst met identiteiten. Het verwijdert de sleutels van de agent niet uit die lijst, waardoor alle andere aanbiedingen nog steeds vóór die van u worden verzonden en de verbinding bij de limiet alsnog wordt verbroken. Voer ssh -v -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10 uit zonder IdentitiesOnly en u zult zien dat de agent-sleutels als eerste worden aangeboden. -i vereist -o IdentitiesOnly=yes ernaast.

Om de agent volledig buiten beschouwing te laten voor één verbinding:

ssh -o IdentityAgent=none -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10

ssh leest dan de private key van de schijf en vraagt om de passphrase, indien aanwezig.

De tools die op ssh zijn gebaseerd, accepteren dezelfde optie:

scp -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps report.tar.gz deploy@203.0.113.10:/tmp/
rsync -av -e "ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" ./site/ deploy@203.0.113.10:/srv/site/
GIT_SSH_COMMAND="ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" git clone git@example.com:team/repo.git

Waarom de foutmelding verschijnt op de tweede hop

Met ForwardAgent yes wordt de agent-socket beschikbaar gemaakt op de server waarmee u verbinding maakt. Een ssh-commando dat op die server wordt uitgevoerd, gebruikt uw lokale agent, met al uw sleutels, via de geforwarde socket. Daarom kan de fout optreden op de hop van een jump host naar de eindserver, terwijl de eerste hop probleemloos verliep. Voer echo $SSH_AUTH_SOCK uit op de tussenliggende machine: een socket-pad betekent dat een geforwarde agent bereikbaar is, en een lege uitvoer betekent dat er geen aanwezig is.

Agent forwarding brengt een tweede risico met zich mee. Iedereen met root-rechten op die tussenliggende machine kan uw agent gebruiken om zich als u te authenticeren, zolang uw sessie openstaat. ProxyJump voorkomt beide problemen:

ssh -J deploy@jump.example.com deploy@10.0.0.5

ProxyJump opent een verbinding via de jump host en authenticeert bij de eindserver vanaf uw eigen machine, waardoor uw lokale ~/.ssh/config op elke hop van toepassing is, inclusief IdentitiesOnly. Het uitschakelen van ForwardAgent is een standaardstap bij het beveiligen van SSH op een VPS.

Moet u MaxAuthTries op de server verhogen?

Doorgaans niet. Controleer eerst de huidige waarde:

sudo sshd -T | grep -i maxauthtries

sshd -T toont de effectieve configuratie, inclusief standaardwaarden, waardoor de werkelijke waarde wordt gerapporteerd, zelfs als sshd_config niets vermeldt. Voeg -C user=deploy,host=example.com,addr=203.0.113.10 toe als u Match-blokken gebruikt, omdat deze per verbinding worden geëvalueerd en anders worden overgeslagen.

Het verhogen van de limiet werkt in de beperkte zin dat een groter aantal een slecht functionerende client meer ruimte geeft:

MaxAuthTries 20

Valideer het bestand en herlaad de service; houd een tweede sessie open terwijl u dit doet:

sudo sshd -t
sudo systemctl reload ssh      # Debian and Ubuntu
sudo systemctl reload sshd     # RHEL family

Als systemctl is-enabled ssh.socket de melding enabled geeft op Ubuntu 24.04, is sshd socket-geactiveerd: er start een nieuw proces per verbinding dat sshd_config opnieuw inleest, waardoor nieuwe verbindingen de wijziging automatisch overnemen.

Kijk nu wat die wijziging heeft opgeleverd. De client biedt sleutels aan die deze server nooit zal accepteren. Het verhogen van het plafond dwingt de server om per verbinding twintig afgewezen aanbiedingen te verwerken in plaats van zes, voor elke client die verbinding maakt en voor elke wachtwoord-gokker op het internet. Elke aanbieding kost de server een opzoekopdracht in authorized_keys. Uw eigen inlogproces blijft traag, omdat de juiste sleutel nog steeds achteraan in de rij staat. Voeg een dertiende sleutel toe aan uw agent en u bent weer terug bij af, waarbij u opnieuw om een hoger getal vraagt.

Verhoog de waarde alleen wanneer een legitieme client daadwerkelijk meerdere identiteiten moet presenteren. Los in alle andere gevallen het probleem bij de client op. Het verlagen van de waarde is een redelijke vorm van hardening zodra elke gebruiker inlogt met een geconfigureerde sleutel, aangezien een lager getal een gokker minder pogingen per verbinding geeft.

Waarom fail2ban u hiervoor kan verbannen

Op het standaard logniveau registreert sshd elke geweigerde publieke sleutel:

Failed publickey for deploy from 203.0.113.10 port 51292 ssh2: ED25519 SHA256:AAAA...

Eén verbinding vanaf een volledige agent produceert binnen een seconde of twee meerdere van deze regels vanaf hetzelfde adres. De fail2ban sshd jail telt het aantal sshd-foutmeldingen en verbant het bronadres zodra maxretry is bereikt binnen findtime. Deze vensters zijn standaard klein, dus twee pogingen met een defecte verbinding kunnen voldoende zijn om uw eigen adres te verbannen.

Het symptoom verandert vervolgens, en dit is het punt dat voor verwarring zorgt. U ziet niet langer "Too many authentication failures", maar helemaal niets meer: de verbinding blijft hangen en krijgt uiteindelijk een time-out, omdat de firewall uw pakketten nu negeert in plaats van ze te beantwoorden. Een time-out waar u voorheen een foutmelding kreeg, is het signaal, en dat onderscheid wordt behandeld in SSH-verbinding geweigerd versus verbinding time-out.

Controleer via de console van uw provider, of vanaf een ander adres, de jail en hef de verbanning op:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.10

Plaats uw eigen adres in ignoreip in jail.local terwijl u de client in orde maakt, en verwijder het weer zodra u klaar bent. De jail zelf is geconfigureerd in de fail2ban-handleiding voor Ubuntu 24.04.

Wat u eenmalig moet doen om dit te voorkomen

Geef elke server een eigen Host-blok in ~/.ssh/config, met HostName, User, IdentityFile en IdentitiesOnly yes. Daarna is ssh vps kort om te typen, biedt het precies één sleutel en kan het MaxAuthTries niet triggeren, ongeacht hoe vol uw agent raakt. Het houdt bovendien de ssh -v-uitvoer kort genoeg om te kunnen lezen op de dag dat er iets anders defect raakt.

FAQ

Hoe los ik "Too many authentication failures" direct op?

Bied slechts één sleutel aan in plaats van alle beschikbare sleutels. Gebruik voor een directe verbinding ssh -o IdentitiesOnly=yes -i ~/.ssh/your_key user@host. Voeg voor een permanente oplossing een blok toe aan ~/.ssh/config met HostName, User, IdentityFile die naar die specifieke sleutel verwijst, en IdentitiesOnly yes, gevolgd door chmod 600 ~/.ssh/config. Controleer dit met ssh -v: u zou voor die host één Offering public key:-regel moeten zien.

Waarom biedt ssh -i nog steeds mijn andere sleutels aan?

Omdat -i een identiteit aan de lijst toevoegt, in plaats van de lijst te beperken. De sleutels die in ssh-agent zijn geladen, blijven in de lijst staan en worden nog steeds aangeboden, vaak vóór uw eigen sleutel. Hierdoor kan de server de limiet MaxAuthTries bereiken voordat uw sleutel wordt geprobeerd. -o IdentitiesOnly=yes is de optie die ssh beperkt tot de identiteiten die u expliciet benoemt. Gebruik -i en -o IdentitiesOnly=yes samen, of gebruik -o IdentityAgent=none om de agent voor die specifieke verbinding volledig te negeren.

Moet ik MaxAuthTries op de server verhogen om dit op te lossen?

Nee, in bijna elk geval. De client stuurt sleutels die deze server nooit zal accepteren. Een hogere limiet zorgt er alleen voor dat de server per verbinding meer afgewezen aanbiedingen moet verwerken, voor elke client en elke brute-force-poging die de server bereikt. Bovendien treedt het probleem opnieuw op zodra er één extra sleutel in uw agent wordt geladen. Controleer de effectieve waarde met sudo sshd -T | grep -i maxauthtries als u nieuwsgierig bent, en los het probleem vervolgens op de client op met IdentitiesOnly.

Waarom gebeurt dit op een server die vorige maand nog goed werkte?

Uw agent is groter geworden. AddKeysToAgent yes in ~/.ssh/config houdt elke sleutel die u gebruikt geladen, en desktop-keyring-agents laden automatisch sleutels bij het inloggen. Zodra het aantal geladen sleutels de MaxAuthTries van de server overschrijdt, zal elke server waarvan de sleutel laat in de aanbiedingsvolgorde staat, de verbinding weigeren. Voer ssh-add -l uit en vergelijk het aantal met de limiet op de server.

Kan dit ertoe leiden dat mijn IP-adres door fail2ban wordt verbannen?

Ja. Elke afgewezen sleutel produceert een Failed publickey for ...-regel in het serverlogboek. Eén verbinding kan daardoor binnen enkele seconden meerdere foutmeldingen vanaf uw adres genereren. De fail2ban-jail sshd blokkeert het adres zodra maxretry is bereikt binnen findtime. Het teken dat dit is gebeurd, is dat de foutmelding verandert in een hangende verbinding en vervolgens een timeout, omdat pakketten worden geweigerd in plaats van beantwoord. Verwijder de blokkade via de console met sudo fail2ban-client set sshd unbanip <your address> en herstel de configuratie op de client voordat u opnieuw verbinding maakt.