SSH : corriger « Too many authentication failures »

Ce que signifie « Too many authentication failures »

« Too many authentication failures » signifie que votre client SSH a proposé au serveur plus de clés qu’il n’était autorisé à vérifier. Le serveur a donc fermé la connexion avant même que votre clé correcte soit essayée. Il s’agit presque toujours d’un problème côté client. La clé se trouve sur votre disque, le serveur la possède dans authorized_keys, mais cela ne suffit pas, car la connexion s’est terminée trop tôt.

Voici le déroulement. ssh-agent contient toutes les clés privées que vous y avez chargées. Votre client propose ces clés au serveur une par une, car il ne peut pas savoir laquelle le compte accepte. Le serveur rejette chaque clé qui ne figure pas dans authorized_keys et compte chaque rejet comme une tentative d’authentification échouée. MaxAuthTries dans sshd_config limite le nombre d’échecs autorisés pour une connexion. La valeur par défaut est 6. Si votre agent contient dix clés et que la bonne est la huitième, le serveur ferme la connexion avant de l’atteindre.

La solution consiste donc à faire en sorte que le client ne propose qu’une seule clé : la bonne.

Ce que le serveur compte et le rôle de MaxAuthTries

L’authentification par clé publique commence par un jeu de devinettes. Le client envoie une clé publique et demande si le serveur accepterait une signature réalisée avec celle-ci. Le serveur répond par oui ou par non. Une réponse « non » est une tentative échouée, exactement comme un mot de passe incorrect.

La page de manuel sshd_config(5) décrit cette limite : « Indique le nombre maximal de tentatives d’authentification autorisées par connexion. Dès que le nombre d’échecs atteint la moitié de cette valeur, les échecs supplémentaires sont consignés. La valeur par défaut est 6. »

Six tentatives suffisent largement à une personne qui saisit un mot de passe. Ce n’est pas beaucoup pour un agent qui possède dix clés. Une fois la limite d’échecs dépassée, sshd déconnecte le client et écrit une ligne de ce type dans le journal système :

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

Votre client affiche l’autre moitié du même événement :

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

Cet échec est différent de l’erreur SSH « permission denied (publickey) ». Dans ce cas, le serveur a examiné toutes les clés proposées et n’en a accepté aucune. Ici, le serveur a arrêté son examen. Confondre ces deux situations conduit à recopier pendant une après-midi une clé qui était déjà correcte.

Pourquoi la même clé fonctionne depuis l’ordinateur portable de votre collègue

La clé et le serveur sont identiques. Son agent contient deux clés, tandis que le vôtre en contient douze. L’offre qui arrive en premier chez lui arrive en neuvième position chez vous, et la connexion est déjà terminée à ce moment-là.

Le nombre augmente progressivement. AddKeysToAgent yes dans ~/.ssh/config ajoute chaque clé utilisée à l’agent et l’y conserve. Les agents de trousseau de clés des environnements de bureau, comme GNOME Keyring sous Linux ou le trousseau de connexion sous macOS, chargent les clés à la connexion sans demander de confirmation. Ajoutez une clé client, une clé d’hôte Git et une clé pour un serveur de laboratoire au fil d’une année, et un serveur qui fonctionnait toujours commence un jour à vous refuser l’accès. Rien n’a changé sur le serveur. Votre agent contient simplement davantage de clés.

Comment voir les clés proposées avec ssh -v

Lancez la connexion qui échoue avec -v et consultez la trace.

ssh -v deploy@203.0.113.10

Deux types de lignes sont importants. Will attempt key: liste les identités que le client a assemblées, dans l’ordre où il les utilisera. Offering public key: apparaît une fois pour chaque clé effectivement envoyée au serveur.

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

Vos chemins, types de clés et empreintes seront différents. Il faut compter le nombre de lignes Offering public key: avant la déconnexion. Si les propositions défilent et que la session se termine sans que la clé souhaitée apparaisse, le diagnostic est établi. Le mot agent à la fin d’une ligne signifie que cette identité vient de ssh-agent. Le mot explicit signifie qu’elle vient d’une ligne IdentityFile ou de -i sur la ligne de commande.

Demandez ensuite à l’agent ce qu’il contient :

ssh-add -l

Chaque ligne de la sortie correspond à une clé chargée. Si la commande affiche The agent has no identities., l’agent n’est pas en cause ; examinez plutôt les lignes IdentityFile dans ~/.ssh/config. Si elle affiche Could not open a connection to your authentication agent., aucun agent ne fonctionne et les clés proposées proviennent de vos fichiers de clés par défaut.

Correctif 1 : IdentitiesOnly avec une seule clé par hôte

IdentitiesOnly yes indique à ssh de proposer uniquement les identités que vous avez configurées et d’ignorer les clés supplémentaires que l’agent propose automatiquement. Associez cette option à une ligne IdentityFile pour que le client n’envoie qu’une seule proposition.

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

Enregistrez cette configuration dans ~/.ssh/config, puis exécutez chmod 600 ~/.ssh/config. Si le fichier est accessible en écriture par son groupe ou par tout le monde, ssh refuse de s’exécuter et affiche Bad owner or permissions on /home/you/.ssh/config. Désormais, ssh vps propose une seule clé, et ssh -v vps doit afficher exactement une ligne Offering public key:.

Deux détails surprennent souvent.

• IdentitiesOnly yes seul ne signifie pas « une seule clé ». Les fichiers d’identité par défaut comptent comme des identités configurées. ssh essaie donc encore ~/.ssh/id_ed25519, ~/.ssh/id_rsa et les autres fichiers par défaut qu’il trouve. Vous devez aussi ajouter la ligne IdentityFile.
• L’agent effectue toujours la signature. IdentitiesOnly contrôle les clés proposées, pas le composant qui les signe. Si la clé privée indiquée par IdentityFile est chargée dans l’agent, celui-ci produit la signature et aucune phrase secrète ne vous est demandée. Vous pouvez même faire pointer IdentityFile vers le fichier .pub correspondant. C’est utile lorsque la clé privée se trouve uniquement dans l’agent ou sur un jeton matériel.

Un piège dans ~/.ssh/config annule silencieusement ce correctif. La plupart des mots-clés utilisent la première valeur trouvée. C’est pourquoi les blocs Host spécifiques doivent être placés avant Host *. IdentityFile ne suit pas cette règle. Le manuel indique : « Plusieurs fichiers d’identité peuvent être indiqués dans les fichiers de configuration ; toutes ces identités seront essayées successivement. » Une directive IdentityFile placée dans Host * est ajoutée à celle définie pour l’hôte, au lieu de la remplacer. Une ligne globale oubliée réintroduit donc une proposition supplémentaire dans chaque connexion.

Si vous voulez une protection globale, définissez uniquement l’option, à la fin du fichier :

Host *
  IdentitiesOnly yes

Chaque hôte doit alors avoir sa propre directive IdentityFile, ce qui correspond de toute façon au résultat recherché. Attribuer une seule clé à chaque serveur permet également de révoquer ultérieurement l’accès d’une seule machine sans devoir tout réémettre. Cette habitude mérite d’être adoptée dès le début : consultez comment gérer les clés SSH par machine.

Correction 2 : purger ou redémarrer l’agent

Si vous ne pouvez pas encore modifier la configuration, videz l’agent et ne chargez que les éléments nécessaires.

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

Si la connexion fonctionne juste après ssh-add -D, l’agent était en cause. Considérez cela comme un test, pas comme une réparation. Un agent de trousseau de clés de bureau recharge ses clés à votre prochaine connexion. Le problème réapparaîtra donc demain. Une ligne IdentitiesOnly dans ~/.ssh/config survit à un redémarrage. Un agent vide, non.

Vous pouvez aussi définir une durée de vie pour une clé afin que l’agent la supprime automatiquement :

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

La clé est supprimée 1800 secondes après son ajout. Vous pouvez également redémarrer l’agent. La méthode dépend de ce qui l’a démarré. Un ssh-agent que vous avez lancé vous-même s’arrête avec ssh-agent -k. Si vous l’exécutez depuis une unité systemd utilisateur que vous avez écrite, redémarrez cette unité avec systemctl --user restart <unit>. Un agent de trousseau de clés redémarre avec votre session de bureau.

Correctif 3 : la commande ponctuelle pour un serveur auquel vous vous connectez une seule fois

Pour un hôte que vous n’ajouterez pas à votre configuration, indiquez les mêmes paramètres sur la ligne de commande :

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

-i seul est la mauvaise correction la plus fréquente. -i ajoute une clé à la liste des identités. Il ne retire pas les clés de l’agent de cette liste. Toutes les autres clés sont donc encore proposées avant la vôtre et la connexion échoue toujours à la limite. Exécutez ssh -v -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10 sans IdentitiesOnly et vous verrez les clés de l’agent être proposées en premier. -i doit être accompagné de -o IdentitiesOnly=yes.

Pour désactiver complètement l’agent pour une connexion :

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

ssh lit alors la clé privée sur le disque et demande sa passphrase si elle en possède une.

Les outils basés sur ssh acceptent la même option :

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

Pourquoi l’erreur apparaît au deuxième saut

Avec ForwardAgent yes, le socket de l’agent est rendu disponible sur le serveur auquel vous vous connectez. Une commande ssh exécutée sur ce serveur utilise votre agent local, avec toutes vos clés, via le socket transféré. C’est pourquoi l’erreur peut apparaître lors du saut d’un jump host vers le serveur final, alors que le premier saut a fonctionné correctement. Exécutez echo $SSH_AUTH_SOCK sur la machine intermédiaire : un chemin de socket indique qu’un agent transféré est accessible, et une sortie vide signifie qu’il n’y en a pas.

Le forwarding de l’agent a un autre coût. Toute personne disposant des privilèges root sur la machine intermédiaire peut utiliser votre agent pour s’authentifier en votre nom tant que votre session reste ouverte. ProxyJump évite ces deux problèmes :

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

ProxyJump ouvre une connexion via le jump host et s’authentifie auprès du serveur final depuis votre propre machine. Votre ~/.ssh/config local s’applique donc à chaque saut, y compris IdentitiesOnly. Désactiver ForwardAgent est une mesure standard pour sécuriser SSH sur un VPS.

Faut-il augmenter MaxAuthTries sur le serveur ?

En général, non. Vérifiez d’abord la valeur actuelle :

sudo sshd -T | grep -i maxauthtries

sshd -T affiche la configuration effective, valeurs par défaut comprises. Il indique donc la valeur réelle, même lorsque sshd_config n’en fait pas mention. Ajoutez -C user=deploy,host=example.com,addr=203.0.113.10 si vous utilisez des blocs Match, car ceux-ci sont évalués pour chaque connexion et sont sinon ignorés.

Augmenter la limite fonctionne, au sens strict, car une valeur plus élevée laisse davantage de marge à un client défaillant :

MaxAuthTries 20

Validez le fichier et rechargez le service. Gardez une deuxième session ouverte pendant l’opération :

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

Si systemctl is-enabled ssh.socket renvoie enabled sur Ubuntu 24.04, sshd est activé par socket. Un processus est lancé pour chaque connexion et relit sshd_config. Les nouvelles connexions prennent donc automatiquement en compte la modification.

Examinez maintenant l’effet de cette modification. Le client propose des clés que ce serveur n’acceptera jamais. Augmenter la limite indique au serveur de traiter vingt propositions rejetées par connexion au lieu de six, pour chaque client qui se connecte et pour chaque attaquant qui tente des mots de passe sur Internet. Chaque proposition oblige le serveur à effectuer une recherche dans authorized_keys. Votre propre connexion reste lente, car la bonne clé est toujours proposée en dernier. Ajoutez une treizième clé à votre agent et vous revenez au problème initial : il faut à nouveau augmenter la valeur.

Augmentez la limite uniquement lorsqu’un client légitime doit réellement présenter plusieurs identités. Dans tous les autres cas, corrigez le client. Réduire la limite constitue un durcissement raisonnable lorsque chaque utilisateur se connecte avec une clé configurée, car une valeur plus faible offre moins de tentatives par connexion à un attaquant.

Pourquoi fail2ban peut vous bannir dans ce cas

Avec son niveau de journalisation par défaut, sshd enregistre chaque clé publique refusée :

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

Une connexion établie avec un agent chargé produit plusieurs de ces lignes depuis une même adresse en une ou deux secondes. La jail fail2ban sshd compte les lignes d’échec de sshd et bannit l’adresse source lorsque maxretry est atteint dans findtime. Ces fenêtres sont courtes par défaut. Deux nouvelles tentatives sur une connexion défectueuse peuvent donc suffire à bannir votre propre adresse.

Le symptôme change alors. C’est ce qui induit souvent en erreur. Vous ne voyez plus « Too many authentication failures », mais plus rien du tout : la connexion reste bloquée, puis finit par expirer, car le pare-feu ignore désormais vos paquets au lieu d’y répondre. Un délai d’expiration à la place du message d’erreur habituel est le signal à rechercher. Cette différence est expliquée dans connexion SSH refusée ou connexion SSH expirée.

Depuis la console de votre fournisseur, ou depuis une autre adresse, vérifiez la jail et levez le bannissement :

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

Ajoutez votre propre adresse à ignoreip dans jail.local pendant que vous corrigez le client, puis retirez-la une fois terminé. La configuration de la jail elle-même est présentée dans le guide fail2ban pour Ubuntu 24.04.

Ce qu’il faut faire une seule fois pour que le problème ne se reproduise plus

Attribuez à chaque serveur son propre bloc Host dans ~/.ssh/config, avec HostName, User, IdentityFile et IdentitiesOnly yes. Ensuite, ssh vps est rapide à saisir, ne propose qu’une seule clé et ne peut pas déclencher MaxAuthTries, même si votre agent devient très volumineux. Cela maintient également la sortie de ssh -v suffisamment courte pour rester lisible le jour où un autre problème survient.

FAQ

Comment corriger immédiatement « Too many authentication failures » ?

Proposez une seule clé au lieu de toutes les clés disponibles. Pour vous connecter immédiatement, exécutez ssh -o IdentitiesOnly=yes -i ~/.ssh/your_key user@host. Pour corriger le problème définitivement, ajoutez un bloc à ~/.ssh/config avec HostName, User et IdentityFile pointant vers cette clé, ainsi que IdentitiesOnly yes, puis exécutez chmod 600 ~/.ssh/config. Vérifiez la configuration avec ssh -v : vous devez voir une seule ligne Offering public key: pour cet hôte.

Pourquoi ssh -i propose-t-il quand même mes autres clés ?

Parce que -i ajoute une identité à la liste, mais ne limite pas cette liste. Les clés chargées dans ssh-agent restent présentes et sont toujours proposées, souvent avant la vôtre. Le serveur peut donc atteindre MaxAuthTries avant de parvenir à votre clé. -o IdentitiesOnly=yes est l’option qui limite ssh aux identités que vous avez indiquées. Utilisez -i et -o IdentitiesOnly=yes ensemble, ou -o IdentityAgent=none pour ignorer complètement l’agent lors de cette connexion.

Dois-je augmenter MaxAuthTries sur le serveur pour corriger le problème ?

Non, dans presque tous les cas. Le client envoie des clés que ce serveur n’acceptera jamais. Une limite plus élevée oblige seulement le serveur à évaluer davantage de propositions rejetées pour chaque connexion, y compris pour chaque tentative de brute force qui l’atteint. Le problème réapparaîtra dès qu’une clé supplémentaire sera chargée dans votre agent. Consultez la valeur effective avec sudo sshd -T | grep -i maxauthtries si nécessaire, puis corrigez le client avec IdentitiesOnly.

Pourquoi ce problème est-il apparu sur un serveur qui fonctionnait correctement le mois dernier ?

Votre agent contient davantage de clés. AddKeysToAgent yes dans ~/.ssh/config conserve chargée chaque clé que vous utilisez, et les agents des keyrings de bureau chargent automatiquement les clés lors de la connexion. Dès que le nombre de clés chargées dépasse la valeur MaxAuthTries du serveur, tout serveur dont la clé est proposée tard dans l’ordre des offres commence à refuser la connexion. Exécutez ssh-add -l et comparez le nombre obtenu à la limite configurée sur le serveur.

Cela peut-il faire bannir mon adresse IP par fail2ban ?

Oui. Chaque clé rejetée produit une ligne Failed publickey for ... dans le journal du serveur. Une seule connexion peut donc générer plusieurs échecs depuis votre adresse en quelques secondes. Le jail fail2ban sshd bannit l’adresse lorsque maxretry est atteint dans findtime. Le signe révélateur est que l’erreur se transforme en blocage, puis en délai d’attente, car les paquets sont rejetés au lieu de recevoir une réponse. Supprimez le bannissement depuis la console avec sudo fail2ban-client set sshd unbanip <your address>, puis corrigez le client avant de vous reconnecter.