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 authenticatiepogingen dat per verbinding is toegestaan. Zodra het aantal mislukkingen de helft van deze waarde bereikt, worden aanvullende mislukkingen gelogd. De standaardwaarde is 6."

Zes pogingen zijn ruim voldoende voor iemand die een wachtwoord typt. Het is niet veel voor een agent die tien keys bevat. Zodra het aantal mislukkingen de limiet bereikt, 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 op zichzelf betekent niet "één sleutel". Zonder IdentityFile-regel tellen de standaard identiteitsbestanden mee als de geconfigureerde identiteiten, waardoor ssh nog steeds ~/.ssh/id_ed25519, ~/.ssh/id_rsa en andere standaardbestanden probeert. U heeft ook de IdentityFile-regel nodig: zodra er één is ingesteld, stopt ssh met het toevoegen van de standaardwaarden.
• 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 IdentityFile zelfs naar het bijbehorende .pub-bestand laten wijzen; dit is wat u doet 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, wat de reden is dat specifieke Host-blokken boven Host * moeten staan. IdentityFile volgt die regel niet. De handleiding vermeldt: "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. Een vergeten globale regel voegt dus weer een extra aanbod toe aan elke verbinding.

Als u een globale vangnet-instelling wilt, stelt u alleen de vlag in, onderaan het bestand:

Host *
  IdentitiesOnly yes

Elke host heeft dan zijn eigen IdentityFile nodig, wat sowieso het gewenste resultaat is. Het toewijzen van één sleutel per server maakt het bovendien mogelijk om later de toegang van één specifieke 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 foutmelding verschijnen op de hop van een jump host naar de uiteindelijke server, terwijl de eerste hop probleemloos verliep. Voer echo $SSH_AUTH_SOCK uit op de tussenliggende machine: een lege uitvoer betekent dat er geen agent bereikbaar is. Een socketpad betekent dat er wel een agent is, maar niet noodzakelijkerwijs de uwe, omdat een agent die op die machine is gestart dezelfde variabele instelt. Voer daar ook ssh-add -l uit: als deze de sleutels van uw eigen machine weergeeft, is forwarding actief.

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 zich bij de uiteindelijke server 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 er niets over 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 wel, in de beperkte zin dat een hoger getal 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, dan is sshd socket-geactiveerd. De ssh.socket van Ubuntu start niet voor elke verbinding een nieuwe daemon: het start ssh.service wanneer de eerste verbinding binnenkomt, en die service blijft draaien en handelt de verbindingen daarna af. De bovenstaande herlaadactie is nog steeds de manier om de wijziging door te voeren. Als ssh.service nog niet actief is, valt er niets te herladen en start de volgende verbinding de service met het nieuwe bestand.

Kijk nu wat die wijziging heeft gedaan. De client biedt sleutels aan die deze server nooit zal accepteren. Het verhogen van het plafond vertelt de server om twintig geweigerde aanbiedingen per verbinding te verwerken in plaats van zes, voor elke client die verbinding maakt en voor elke wachtwoordradende partij op het internet. Elk aanbod 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 aan de clientzijde 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 aanvaller minder pogingen per verbinding geeft.

Waarom fail2ban u hiervoor kan verbannen

sshd logt niet elke geweigerde sleutel. Bij de standaardwaarde LogLevel INFO wordt een geweigerde sleutel voor een bestaand account pas in het logboek geschreven zodra het aantal mislukte pogingen de helft van MaxAuthTries bereikt. Dit is wat de handleiding bedoelt met "Zodra het aantal mislukkingen de helft van deze waarde bereikt, worden aanvullende mislukkingen gelogd." Bij de standaardwaarde 6 worden de eerste drie geweigerde pogingen niet in het logboek geschreven. De laatste drie verschijnen als regels zoals deze, gevolgd door de maximum authentication attempts exceeded-regel:

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

Die regels zien eruit als een reeks mislukkingen, maar het sshd-filter van fail2ban telt ze niet. De meegeleverde standaardinstelling, publickey = nofail, leest een Failed publickey-regel voor een geldige gebruiker alleen om het adres en de gebruikersnaam op te halen. De regel die telt is maximum authentication attempts exceeded, dus één verbinding die de limiet bereikt, telt als één mislukking, niet als meerdere. De jail verbant het bronadres zodra maxretry mislukkingen binnen findtime plaatsvinden, en de eigen jail.conf van fail2ban stelt deze in op 5 en 10 minuten. Ongeveer vijf mislukte verbindingen binnen tien minuten zijn voldoende om uw eigen adres te verbannen, en een script of tool die in een lus opnieuw probeert, bereikt dat snel.

Het symptoom verandert dan, en dit is het deel dat voor verwarring zorgt. U ziet niet langer "Too many authentication failures" en begint helemaal niets meer te zien: 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 met 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 brengt, 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. Voer voor een directe verbinding ssh -o IdentitiesOnly=yes -i ~/.ssh/your_key user@host uit. 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 nog steeds MaxAuthTries bereiken voordat uw sleutel aan de beurt is. -o IdentitiesOnly=yes is de optie die ssh beperkt tot de identiteiten die u expliciet benoemt. Gebruik -i en -o IdentitiesOnly=yes samen, of -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 vrijwel 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 geweigerde aanbiedingen moet evalueren, 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 bij de client met IdentitiesOnly.

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

Uw agent is gegroeid. AddKeysToAgent yes in ~/.ssh/config houdt elke sleutel die u gebruikt geladen, en desktop-keyring-agents laden sleutels automatisch 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, falen. Voer ssh-add -l uit en vergelijk het aantal met de limiet op de server.

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

Ja, hoewel langzamer dan het serverlogboek suggereert. Het standaard fail2ban sshd-filter telt geen Failed publickey-regels voor een geldige gebruiker. Het telt de maximum authentication attempts exceeded-regel, dus elke verbinding die de limiet bereikt, telt als één mislukte poging. Met de standaardinstellingen van maxretry = 5 en findtime = 10m wordt uw adres na ongeveer vijf van dergelijke verbindingen binnen tien minuten verbannen. Het teken dat dit is gebeurd, is dat de foutmelding verandert in een hangende verbinding en vervolgens een time-out, omdat pakketten worden geweigerd in plaats van beantwoord. Deblokkeer het adres vanaf de console met sudo fail2ban-client set sshd unbanip <your address> en herstel de clientconfiguratie voordat u opnieuw verbinding maakt.