Le message
Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures
Disconnected from 203.0.113.10 port 22Sur le serveur, le journal indique :
maximum authentication attempts exceeded for user from 203.0.113.20 port 47120 ssh2 [preauth]Souvent, on ne vous a jamais demandé de mot de passe. Dans notre test, un compte avec un mot de passe valide a échoué avec ce message avant toute invite, car les clés avaient épuisé toutes les tentatives d'abord.
Vérifier la cause
Comptez les clés de votre agent :
ssh-add -lRegardez ensuite ce qui est réellement proposé :
ssh -v user@server 2>&1 | grep -E 'Offering|Too many'debug1: Offering public key: key1 ED25519 SHA256:...
debug1: Offering public key: key2 ED25519 SHA256:...
debug1: Offering public key: key3 ED25519 SHA256:...
debug1: Offering public key: key4 ED25519 SHA256:...
debug1: Offering public key: key5 ED25519 SHA256:...
debug1: Offering public key: key6 ED25519 SHA256:...
Received disconnect from 203.0.113.10 port 22:2: Too many authentication failuresChaque clé que le serveur n'accepte pas compte pour un échec, et la limite est MaxAuthTries, 6 par défaut. Dans notre test, la sixième clé avait encore son tour : avec la bonne clé en sixième position la connexion réussissait, et avec six mauvaises clés devant elle la connexion échouait. Un serveur avec une limite plus basse échoue plus tôt.
La solution : dire à ssh quelle clé utiliser
Pour un essai :
ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_server user@serverPour le rendre permanent, ajoutez ceci à ~/.ssh/config :
Host server
HostName 203.0.113.10
User user
IdentityFile ~/.ssh/id_ed25519_server
IdentitiesOnly yes-i seul ne suffit pas. Nous l'avons essayé : sans IdentitiesOnly, les clés de l'agent passaient quand même en premier, et la même erreur revenait. C'est IdentitiesOnly yes qui limite ssh aux clés que vous avez nommées.
D'autres réglages par hôte se trouvent dans ces exemples de fichier ssh config.
Si la clé n'existe que dans l'agent
IdentityFile peut pointer vers le fichier de clé publique. ssh utilise alors ce fichier pour choisir la clé, et l'agent fait la signature :
Host server
IdentityFile ~/.ssh/id_ed25519_server.pub
IdentitiesOnly yesSi vous vous connectez avec un mot de passe
Les clés ne font ici que gêner : désactivez-les pour cette connexion :
ssh -o PubkeyAuthentication=no user@serverDans un fichier de configuration, c'est PubkeyAuthentication no dans le bloc de l'hôte.
Autres options
Garder moins de clés dans l'agent
ssh-add -l # list
ssh-add -d ~/.ssh/old_key # remove one
ssh-add -D # remove allCela ne retire des clés que de l'agent et ne touche pas aux fichiers. Si vous utilisez une clé distincte pour chaque serveur, la liste grossit vite : la configuration ci-dessus est donc la réponse durable.
Ignorer l'agent pour un hôte
Host server
IdentityAgent none
IdentityFile ~/.ssh/id_ed25519_serverCela marche aussi, mais vous saisissez la phrase secrète de la clé à chaque fois si elle en a une.
Définir IdentitiesOnly pour tous les hôtes
Vous pouvez mettre IdentitiesOnly yes sous Host *. Sans IdentityFile pour un hôte, ssh essaie les fichiers par défaut comme ~/.ssh/id_ed25519, et ignore les autres clés de l'agent. Les hôtes qui comptaient sur l'une de ces autres clés ont donc besoin de leur propre ligne IdentityFile.
N'augmentez pas MaxAuthTries pour cela
Vous pouvez relever la limite sur un serveur que vous contrôlez, mais la cause est côté client. Tous les autres serveurs auxquels vous vous connectez gardent leur limite, et une limite plus haute donne à quiconque devine plus d'essais par connexion.
Des échecs répétés peuvent vous faire bannir
Si le serveur fait tourner fail2ban, chaque déconnexion de ce type peut compter contre votre adresse. Dans notre test, une telle déconnexion a ajouté un échec à la jail sshd. Si l'erreur devient Connection refused après quelques essais, vous êtes peut-être banni. Voir fail2ban pour SSH.
Questions
Quelle est la valeur par défaut de MaxAuthTries ?
6. Chaque clé refusée par le serveur compte comme une tentative : un agent avec beaucoup de clés peut les épuiser avant d'arriver à la bonne.
Pourquoi ssh -i ne suffit-il pas ?
Sans IdentitiesOnly yes, ssh propose quand même les clés de l'agent avant celle donnée avec -i.
Comment voir les clés que ssh propose ?
Lancez ssh -v user@server et cherchez les lignes Offering public key.