AWS – Disconnected: Aucune méthode d’authentification prise en charge disponible (serveur envoyé: publickey)

SSH sur mon serveur AWS vient de casser pour Putty et Filezilla. Je fais des efforts pour que cette publication soit une liste de dépannage complète, donc si vous partagez des liens vers d’autres pages de débordement de stack, je les modifierai dans la question.

Disconnected : No supported authentication methods available (server sent :publickey) 

L’erreur est familière depuis la configuration de la connexion il y a presque un an. Si vous configurez AWS SSH pour la première fois, les problèmes les plus courants sont résolus:

  • Nom d’utilisateur incorrect: Déconnecté: Aucune méthode d’authentification prise en charge disponible (serveur envoyé: publickey)
  • Fichier .ppk incorrect: impossible de se connecter au serveur amazon à l’aide de mastic

Cependant, la seule chose qui pourrait avoir un impact sur un système antérieur est:

  • Mauvaise adresse IP: le redémarrage d’une instance AWS (ou la création d’une image) ne garantit pas toujours la même adresse IP. Cela devrait évidemment être mis à jour dans le mastic.

Quelles sont les autres possibilités?

La solution à ce problème (selon le message accepté ci-dessous) est que pour AWS EC2, les trois doivent avoir les permissions appropriées (777 ne sont pas corrects pour aucun d’entre eux). Voici un exemple qui fonctionne:

 /home/ec2-user/ - 700 /home/ec2-user/.ssh/ - 600 /home/ec2-user/.ssh/authorized_keys - 600 

/ var / log / secure vous dira qui jette une erreur, consultez ce tutoriel vidéo pour avoir access si vous êtes complètement bloqué: http://d2930476l2fsmh.cloudfront.net/LostKeypairRecoveryOfLinuxInstance.mp4

Pour moi, cette erreur est apparue immédiatement après que j’ai changé le répertoire de base de l’utilisateur par

 sudo usermod -d var/www/html username 

Cela peut également se produire en raison de l’absence d’autorisation appropriée pour le fichier authorized_key dans ~ / .ssh. Assurez-vous que l’autorisation de ce fichier est 0600 et l’autorisation de ~ / .ssh est 700.

Vous recevrez également “Disconnected: Aucune méthode d’authentification prise en charge disponible (serveur envoyé: publickey)” lorsque vous avez un utilisateur Linux correct mais que vous n’avez pas créé le fichier .ssh / authorized_keys et enregistré la clé publique comme indiqué dans Gestion des comptes utilisateur Votre instance Linux

Une autre cause aurait un impact sur un système antérieur. J’ai recréé mes instances (en utilisant AWS OpsWorks) pour utiliser Amazon Linux au lieu d’Ubuntu et j’ai reçu cette erreur après l’avoir fait. Changer pour utiliser “ec2-user” comme nom d’utilisateur au lieu de “ubuntu” a résolu le problème pour moi.

PuTTY ne prend pas en charge de manière native le format de clé privée (.pem) généré par Amazon EC2. PuTTY a un outil nommé PuTTYgen, qui peut convertir les clés au format PuTTY requirejs (.ppk). Vous devez convertir votre clé privée dans ce format (.ppk) avant d’essayer de vous connecter à votre instance à l’aide de PuTTY.

Les étapes à suivre pour cela sont décrites ici: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html

Cela a résolu le problème.

J’ai eu le même problème, par erreur accidentelle. Je vais le partager ici, au cas où quelqu’un aurait fait la même erreur. Étapes de base, comme décrit. 1, téléchargez le mastic et le puttygen, ou le paquet de mastic et installez-le. 2, récupérez le fichier .pem à partir de votre instance AWS EC2. 3, utilisez puttygen pour convertir le fichier .pem de sorte que vous ayez une clé privée — une erreur est survenue ici. J’ai choisi l’onglet “Conversions” de PuttyGen et j’ai chargé mon fichier .pem. Après avoir chargé le fichier pem, ici, ne cliquez PAS sur “Générer”, mais directement sur “Enregistrer la clé privée”. C’est la clé dont vous avez besoin. Si vous cliquez sur Générer, vous aurez une paire de clés totalement différente. 4, en mastic, utilisez ec2-user@your.public.dns.that.you.get.from.aws.ec2.instance, et chargez la clé privée à SSH / Auth Bonne chance!

La réponse complète est ici: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/putty.html

Votre problème peut être lié à une connexion incorrecte qui varie selon les AMI. Utilisez les connexions suivantes sur les AMI suivantes:

  • Ubuntu ou root sur les AMI Ubuntu
  • ec2-user sur Amazon Linux AMI
  • centos sur Centos AMI
  • debian ou root sur les AMI Debian
  • ec2-user ou fedora sur Fedora
  • ec2-user ou root sur: RHEL AMI, SUSE AMI, autres.

Si vous utilisez un système d’exploitation:

  • Windows – récupère la clé PEM sur le site Web AWS et génère un fichier PPK à l’aide de PuttyGen. Ensuite, utilisez Putty pour utiliser le PPK (sélectionnez-le en utilisant la colonne de gauche: Connection-> SSH-> Auth: clé privée pour autorisation)
  • Linux – Exécuter: ssh -i your-ssh-key.pem login@IP-or-DNS

Bonne chance.

dans la plupart des cas, aucune erreur de méthode d’authentification ne s’est produite lors de l’utilisation du nom d’utilisateur incorrect pour la connexion. Mais je trouve quelque chose d’autre si vous avez toujours du mal à vous connecter et que vous avez essayé toutes les options ci-dessus.

J’ai créé le couple Linux VM et essayer de reproduire un tel problème de connexion, une chose que j’ai trouvée est, lorsque AWS vous a demandé de nommer votre paire de clés, n’utilisez pas d’espace vide (“”) et point (“. AWS vous permet effectivement de le faire.

ex. Lorsque j’ai nommé la paire de clés en tant que “AWS.FREE.LINUX”, la connexion est toujours refusée. Lorsque j’ai nommé “AWS_FREE_LINUX”, tout fonctionne correctement.

J’espère que cela aidera un peu.

Sur la base de plusieurs instances, si le fichier de clés et le nom d’utilisateur sont corrects, cela semble se produire lors de la modification de certaines permissions de répertoire associées à l’utilisateur root.

Un problème similaire s’est produit avec moi aujourd’hui. J’avais aussi beaucoup cherché à ce sujet. Pas une aide. Je viens juste de faire deux changements et ça fonctionne bien aussi.

  1. J’avais visité la documentation d’Amazon où décrire soit Vérifier qu’il existe une règle autorisant le trafic de votre ordinateur vers le port 22 (SSH) et le cas échéant, le créer et éditer “Groupe de sécurité” et append “SSH” à mon IP. CA aidera.
  2. Dans mon cas, Dans le mastic, je dois autoriser à nouveau avec le fichier .ppk. Je ne sais pas pourquoi il demande à nouveau, sans aucun changement.

J’espère que cela vous aidera.

J’ai eu le même problème, j’ai utilisé Public DNS au lieu de Public IP . Cela a résolu maintenant.

Dans mon cas, le problème était que le fichier ppk était placé dans% USERPROFILE% \ Downloads au lieu du dossier% USERPROFILE% .ssh.

Après avoir déplacé le fichier, le problème a disparu.

En essayant de me connecter à un serveur SiteGround via Putty, j’ai rencontré le même problème. Leurs instructions sont assez complètes et doivent fonctionner pour certaines personnes, mais n’ont pas fonctionné pour moi.

Ils recommandent d’exécuter pageant.exe, qui s’exécute en arrière-plan. Vous enregistrez votre / vos clé (s) avec Pageant, et il est supposé que Putty connaisse les clés quand il essaie de se connecter.

À quelques endroits, j’ai trouvé des suggestions pour spécifier la clé directement dans la définition de session Putty: Putty Configuration> Connection> SSH> Auth> “Fichier de clé privée pour l’authentification”, puis accédez à votre fichier de clés au format .ppk.

Faire cela sans exécuter Pageant a résolu le problème pour moi.

Pendant la session ssh, ma connexion a été interrompue, car je ne peux plus ssh mon SRV, j’ai démarré une nouvelle instance et je suis capable de ssh la nouvelle instance (avec la même clé).

J’ai monté l’ancien volume sur la nouvelle machine et vérifié le fichier .ssh / authorized_key et n’ai trouvé aucun problème avec la permission ou le contenu.