Amazon EC2 Permission refusée (publickey)
Cela semble être un problème commun, mais mon cas spécifique semble un peu différent.
J'ai configuré une nouvelle instance Amazon EC2 à l'aide des outils de ligne de commande, connecté via SSH, et effectué certains travaux de configuration.
Au début, cependant, je ne pouvais pas utiliser SSH sur l'instance, je devais arrêter et redémarrer l'instance pour pouvoir me connecter. Avant de redémarrer je viens de recevoir la réponse.
Permission denied (publickey).
C’était la nuit dernière, ce matin, je reviens au même cas et maintenant je n’ai plus que
Permission denied (publickey).
J'ai essayé de redémarrer l'instance sans joie.
Quelqu'un peut-il me diriger dans la bonne direction ici? La même commande qui a fonctionné la nuit dernière ne fonctionne plus, je me connecte depuis mon Macbook Pro.
Je vais répondre à ma propre question au cas où quelqu'un d'autre verrait la même chose ... La nuit dernière, je l'avais fait:
ssh-add ~/.ssh/[keypair name]
puis été connecté avec:
ssh ec2-user@[ec2 instance ip]
Ce matin, j'ai essayé la même chose et je ne pouvais pas me connecter. Mais faire
ssh -i ~/.ssh/[keypair name] ec2-user@[ec2 instance ip]
me fait entrer.
Utiliser à nouveau ssh-add sur la paire de clés me rentre. Je suppose que ssh-add ne fonctionne que dans le shell dans lequel je l'avais publié. Lorsque j'ai fermé la fenêtre du terminal et ouvert une autre, je n'avais plus cette paire de clés disponible sans être explicite.
Cela se passait pour moi parce que je n'utilisais pas le bon nom d'utilisateur. Je pouvais me connecter lors de l'utilisation d'une AMI utilisée dans un tutoriel que je suivais, mais lorsque j'essayais d'utiliser une AMI différente (ubuntu + LAMP de Bitnami), l'erreur Permission denied (public key). m'échappait. J'ai finalement réalisé que si je changeais le nom d'utilisateur pour le tutoriel AMI de ubuntu à ec2-user, j'obtiendrais la même erreur.
Donc, un rapide Google dit que le nom d'utilisateur pour les AMI Bitnami est bitnami. Problème résolu.
J'ai rencontré un problème similaire et il s'est avéré qu'il s'agissait d'autorisations sur le dossier personnel. Heureusement, une autre connexion ssh était toujours ouverte et j'ai donc pu consulter le journal de l'instance ec2:
$ Sudo moins/var/log/secure
qui contenait:
Dec 9 05:58:20 ... sshd[29816]: Authentication refused:
bad ownership or modes for directory /home/ec2-user
Ceci a été corrigé en lançant la commande:
$ chmod og-rwx/home/ec2-user
J'espère que cela aide quelqu'un d'autre.
Veuillez noter qu'après le redémarrage de l'instance, le nom du DNS a changé. Je suis tombé pour cela plusieurs fois. Le fichier de clés était toujours valide, mais le "nom de serveur" a changé.
Je vous remercie!
J'apprécie vraiment la réponse de @ Trevor ici. Je vais ajouter ce petit truc que j'utilise maintenant pour éviter ce problème à l'avenir.
Commodité
Étant donné que vous devez créer une paire de clés différente pour chaque zone de disponibilité, il devient très fastidieux de toutes les gérer, ainsi que les commandes qui les utilisent. Avec la configuration appropriée dans ~/.ssh/config, ma commande ssh est aussi simple que:
ssh ec2-52-10-20-30.us-west-2.compute.amazonaws.com
C'est le DNS public complet d'un serveur de la zone de disponibilité US West 2. Le nom d'utilisateur et la clé appropriés sont sélectionnés pour cette raison:
## ~/.ssh/config
Host *.us-west-2.compute.amazonaws.com
User ec2-user
IdentityFile ~/.ssh/bruno-bronosky-aws-us-west-2.pem
Si l'instance EC2 utilise Ubuntu AMI 14.04. Essayez d'ajouter 'ubuntu @' avant l'adresse IP de l'instance EC2.
ssh -i [key name] ubuntu@[EC2 instance ip]
Assurez-vous que le chemin d'accès à votre clé privée est correct.
Si votre client ssh ne peut pas trouver la clé privée que vous essayez de fournir, curieusement cela ne vous donnera pas d'erreur! il ne veut tout simplement pas utiliser cette clé. Il utilisera toutes les clés que vous avez sous .ssh/id_dsa et .ssh/id_ecdsa, ce qui, bien sûr, rendra l’authentification de la clé publique faible.
J'ai aussi reçu: permission refusée.
J'ai utilisé :
ssh -v -i ~/.ssh/pemfile [email protected]
et la réponse fut:
debug1: No more authentication methods to try.
Entrez la commande:
ssh-add -l
Mais la réponse était vide
Donc, je pense que le fichier de plume a quelque chose de mal à propos du format. Ensuite, j'ai trouvé le fichier de stylo téléchargé à partir d'ec2 web et je l'ai déplacé. Avant cela, j’avais créé un nouveau fichier et analysé le texte du fichier pem téléchargé dans le répertoire ".ssh", puis:
ssh-add filename
Ce qui a réussi.
J'ai résolu ce problème en copiant le contenu de ~/.ssh/id_rsa.pub dans ~/.ssh/allowed_keys sur l'instance EC2.
Ceci est spécifié dans la documentation: http://docs.aws.Amazon.com/opsworks/latest/userguide/security-ssh-access.html
Ensuite, je pourrais utiliser ssh avec cette commande:
ssh ec2-user@[ip.address]
J'ai passé toute la journée à chercher la réponse sur Internet. Mon problème est exactement le même. Après avoir testé avec une nouvelle clé et démarré/terminé une ou deux instances, j'ai finalement trouvé qu'il s'agissait du même nom de clé dans différentes régions.
Voici comment "Permission denied (publickey)" m'est arrivé:
1. Suivez le cahier d’exercices, sélectionnez la zone us-east-1 par défaut
2. Créez un nom de clé "mykey"
3. Exploration du monde AWS en suivant les exemples de ce livre.
4. Un jour, essayez de tester les vitesses de la zone de Sydney, passez à Sydney Zone par défaut.
5. Créez une autre clé, nommée "mykey" sans y penser, mais ne l'utilisez pas pour vous connecter via cli pendant quelques jours.
6. Essayez de vous connecter à AWS à l'aide de cli.
7. Got "Permission refusée (publickey)".
8. J'ai passé de nombreuses heures à résoudre le problème ssh jusqu'à ce que je remarque le problème clé/zone.
J'espère que cela pourrait aider les débutants comme moi.
Pour éviter ce problème, je pense que la meilleure pratique pour nommer une clé est d'y associer une région.
Se connecter à EC2 depuis cli est un peu délicat, du moins pour la première fois. Si vous allez à `
Services -> Calcul -> EC2 -> Exécution d'instances> et sélectionnez le fichier par exemple vous voulez ssh -> connect
`vous verrez alors la boîte de dialogue décrivant comment vous y connecter. Une partie est illustrée ci-dessous.
Si vous utilisez le numéro 4 sans le précéder de ec2-user@, vous obtiendrez
Permission denied (publickey).
Il suffit de copier et coller celui mentionné ci-dessous dans le `Exemple :.
J'ai changé les autorisations à 600, bien que les autorisations sur le fichier pem soient déjà 644. Et cela a fonctionné: p espérons que cela aide
Si vous aviez le même problème, voici ce que vous devriez faire. Tout d’abord, si vous avez Windows, utilisez la ligne de commande Babun, qui est semblable à celle de Linux . Une fois que vous avez cette ligne de commande, ouvrez-la et tapez ssh-i [key pair path] [username]@[EC2 public IP].Pour trouver le chemin de la paire de clés, accédez au fichier dans lequel votre clé est stockée, maintenez la touche Maj enfoncée, cliquez avec le bouton droit de la souris et cliquez sur Copier le chemin, puis collez-le dans le chemin indiqué dans la commande ci-dessus. Vous obtiendrez probablement des "" marques à l'extérieur du chemin que vous avez collé et des barres obliques inverses. Supprimez les marques "" et remplacez les barres obliques inverses par des barres obliques /. Cela a fonctionné dans une situation comme celle-ci que j'ai eu, bonne chance à vous.
Dans mon cas, la raison en était que j'avais changé les autorisations du dossier du répertoire racine avec chmod. Dans le site Web AWS, ils décrivent un long chemin pour restaurer les autorisations avec une autre instance temporaire. Cependant, je viens juste de terminer l'ancienne instance et d'en lancer une autre et cette fois, je n'ai apporté aucune modification aux autorisations du répertoire racine et tout va bien.