web-dev-qa-db-fra.com

Verrouillé sur mon propre serveur: obtenir "trop ​​d'échecs d'authentification" immédiatement lors de la connexion via ssh

J'ai une instance AWS EC2 Ubuntu pour les projets pour animaux de compagnie. Lorsque j'ai essayé de me connecter un jour, cette erreur résulte:

~$ ssh -i"/home/kona/.ssh/aws_kona_id" [email protected] -p22 
Enter passphrase for key '/home/kona/.ssh/aws_kona_id': 
Received disconnect from [IP address] port 22:2: Too many authentication failures
Disconnected from [IP address] port 22
~$

kona est le seul compte activé sur ce serveur

J'ai essayé de redémarrer le serveur, de changer mon adresse IP et d'attendre.

ÉDITER:

kona@arcticjieer:~$ ssh -o "IdentitiesOnly yes" -i"/home/kona/.ssh/aws_kona_id" -v [email protected] -p22 
OpenSSH_8.1p1 Debian-1, OpenSSL 1.1.1d  10 Sep 2019
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to ec2-3-17-146-113.us-east-2.compute.amazonaws.com [3.17.146.113] port 22.
debug1: Connection established.
debug1: identity file /home/kona/.ssh/aws_kona_id type -1
debug1: identity file /home/kona/.ssh/aws_kona_id-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.1p1 Debian-1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.3
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.3 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug1: Authenticating to ec2-3-17-146-113.us-east-2.compute.amazonaws.com:22 as 'kona'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: Host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: [email protected] MAC: <implicit> compression: none
debug1: kex: client->server cipher: [email protected] MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server Host key: ecdsa-sha2-nistp256 SHA256:D3sIum9dMyyHNjtnL7Pr4u5DhmP5aQ1jaZ8Adsdma9E
debug1: Host 'ec2-3-17-146-113.us-east-2.compute.amazonaws.com' is known and matches the ECDSA Host key.
debug1: Found key in /home/kona/.ssh/known_hosts:41
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: /home/kona/.ssh/aws_kona_id  explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/kona/.ssh/aws_kona_id
Enter passphrase for key '/home/kona/.ssh/aws_kona_id': 
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
[email protected]: Permission denied (publickey).
kona@arcticjieer:~$
ubuntusshamazon-web-services
26
Arctic Kona

Cette erreur signifie généralement que vous avez trop de clés chargées dans votre ssh-agent.

Explication: Votre client ssh tentera d'utiliser toutes les clés de ssh-agent un par un avant d'utiliser la clé spécifiée avec -i aws_kona_id. Oui, c'est un peu contre-intuitif. Parce que chaque tentative de ce type est considérée comme un échec d'authentification et par défaut, seulement 5 tentatives sont autorisées par le serveur SSH, vous obtenez l'erreur que vous voyez: Trop d'échecs d'authentification.

Vous pouvez afficher les identités (clés) tentées avec ssh -v.

La solution consiste à dire à ssh de n'utiliser que les identités spécifiées sur la ligne de commande:

ssh -o "IdentitiesOnly yes" -i ~/.ssh/aws_kona_id -v [email protected]

Si cela n'aide pas à publier la sortie de cette commande ici.

48
MLu

Je pense que la réponse de MLu est probablement correcte dans ce cas. La façon de valider cela consiste à exécuter une commande ssh en ligne de commande en spécifiant la clé correcte pour le serveur.

ssh -i "keyfile.pem" [email protected]

Si cela ne fonctionne pas, et dans le cas général de "J'ai été verrouillé sur mon serveur, aidez-moi!", L'approche généralement recommandée consiste à monter le volume sur une autre instance en tant que volume de données.

  1. Arrêtez le serveur EC2.
  2. Montez le volume sur une nouvelle instance en tant que volume de données.
  3. Faites toute enquête ou réparation requise (consultez les journaux, ajoutez des clés, etc.). Cela peut inclure la création de nouveaux utilisateurs et de nouvelles clés, la modification de fichiers sur le système de fichiers, etc.
  4. Montez le volume en tant que volume racine sur l'instance d'origine.

Répétez jusqu'à ce que vous ayez accès. Si vous ne pouvez pas y accéder, vous avez au moins accès à vos données.

29
Tim

SSH par défaut essaie toutes les clés SSH disponibles. Il le fait dans un ordre "aléatoire". La spécification de l'option -i Indique simplement à SSH d'ajouter ce fichier de clés à la liste des clés à essayer.

Il fait pas:

  • limiter SSH à utiliser uniquement cette clé
  • dites à SSH d'essayer cette clé en premier

Ce qui finit par se produire (assez souvent si vous utilisez plusieurs clés) est que SSH essaie quelques clés aléatoires qui ne fonctionnent pas et que le serveur cesse d'accepter les tentatives d'authentification de votre client.

Si vous voulez dire à SSH de "n'utiliser que cette clé", vous devez spécifier l'option IdentitiesOnly yes:

ssh -o "IdentitiesOnly yes" -i"/home/kona/.ssh/aws_kona_id" [email protected] -p22

IdentitiesOnly yes Indique à SSH d'utiliser uniquement les clés explicitement spécifiées (dans ce cas, uniquement la clé spécifiée à l'aide de -i).

C'est pourquoi lorsque j'utilise des clés personnalisées pour différents hôtes, je je définis toujours la configuration de l'hôte dans .ssh/config. Cela me permet d'utiliser un alias simple et, plus important encore, de spécifier IdentitiesOnly yes Et quelle clé utiliser pour éviter ce genre d'erreur:

Host kona.server
    Hostname server.akona.me
    IdentityFile ~/.ssh/aws_kona_id
    IdentitiesOnly yes
    Port 22
    User kona

Avec ce qui précède dans votre .ssh/config, Vous devriez pouvoir vous connecter à votre serveur avec simplement:

$ ssh kona.server
26
Giacomo Alzetta

La sortie détaillée que vous venez d'ajouter montre que vous obtenez Permission denied pour ~/.ssh/aws_kona_id.

C'est un problème complètement différent de Too many authentication failures.

Peut-être que votre aws_kona_id n'est pas la bonne clé pour l'utilisateur (et c'est pourquoi il a continué à essayer toutes les autres identités de l'agent ssh) ou vous devez utiliser le compte utilisateur EC2 par défaut, par exemple ec2-user ou ubuntu ou quoi d'autre.

Essayez ces comptes ou essayez de trouver la bonne clé pour l'utilisateur kona.

5
MLu

L'instance Ubuntu EC2 dispose d'un compte utilisateur ubuntu installé avec votre clé ssh.

Si vous ne supprimez pas ce compte, vous pouvez toujours vous connecter avec:

ssh -i "/home/kona/.ssh/aws_kona_id" [email protected]

Et résolvez le problème de votre compte après Sudo -i et enquête /home/kona/.ssh/authorized_keys

1
profy