Autorisation refusée (publickey) lors de l'accès SSH à l'instance Amazon EC2 [fermé]

Je souhaite utiliser mon instance Amazon ec2 mais j'ai rencontré l'erreur suivante:

Permission denied (publickey).

J'ai créé ma paire de clés et téléchargé le fichier .pem .

Donné:

chmod  600 pem file.

Ensuite, cette commande

ssh -i /home/kashif/serverkey.pem  ubuntu@ec2-54-227-242-179.compute-1.amazonaws.com

Mais ayez cette erreur:

Permission denied (publickey)

De plus, comment puis-je me connecter avec filezilla pour télécharger / télécharger des fichiers?

Ce message d'erreur signifie que vous n'avez pas réussi à vous authentifier.

Ce sont des raisons courantes qui peuvent provoquer cela:

1. Essayer de se connecter avec la mauvaise clé. Êtes-vous sûr que cette instance utilise cette paire de clés?
2. Essayer de se connecter avec le mauvais nom d'utilisateur. ubuntuest le nom d' utilisateur pour la distribution de AWS basée ubuntu, mais sur certains autres , c'est ec2-user(ou adminsur certains de Debian, selon la réponse de Bogdan Kulbida) (peut également root, fedoravoir ci - dessous)
3. Essayer de connecter le mauvais hôte. Est-ce le bon hôte auquel vous essayez de vous connecter?

Notez que 1.cela se produira également si vous avez foiré le /home/<username>/.ssh/authorized_keysfichier sur votre instance EC2.

À propos 2., les informations sur le nom d'utilisateur à utiliser font souvent défaut dans la description de l'image AMI. Mais vous pouvez en trouver dans la documentation AWS EC2, puce 4.: http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

Utilisez la commande ssh pour vous connecter à l'instance. Vous spécifiez le fichier de clé privée (.pem) et nom_utilisateur @ nom_dns_public. Pour Amazon Linux, le nom d'utilisateur est ec2-user. Pour RHEL5, le nom d'utilisateur est root ou ec2-user . Pour Ubuntu, le nom d'utilisateur est ubuntu . Pour Fedora, le nom d'utilisateur est soit fedora ou EC2 utilisateur . Pour SUSE Linux, le nom d'utilisateur est root . Sinon, si l'utilisateur ec2 et root ne fonctionnent pas, consultez votre fournisseur AMI.

Enfin , sachez qu'il existe de nombreuses autres raisons pour lesquelles l'authentification échouerait. SSH est généralement assez explicite sur ce qui s'est mal passé si vous souhaitez ajouter l' -voption à votre commande SSH et lire le résultat, comme expliqué dans de nombreuses autres réponses à cette question.

Dans ce cas, le problème provient de la perte de la paire de clés. À propos de ça:

• Il n'y a aucun moyen de modifier la paire de clés sur une instance . Vous devez créer une nouvelle instance qui utilise une nouvelle paire de clés.
• Vous pouvez contourner le problème si votre instance est utilisée par une application sur Elastic Beanstalk .

Vous pouvez suivre ces étapes:

1. Accès à AWS Management Console
2. Ouvrir l' onglet Elastic Beanstalk
3. Sélectionnez votre application dans l' onglet Toutes les applications
4. Dans le menu de gauche, sélectionnez Configuration
5. Cliquez sur le Instances Gear
6. Sous forme de serveur, vérifiez l' entrée de la paire de clés EC2 et sélectionnez votre nouvelle paire de clés. Vous devrez peut-être actualiser la liste pour voir une nouvelle paire de clés que vous venez de créer.
7. sauver
8. Elastic Beanstalk créera pour vous de nouvelles instances associées à la nouvelle paire de clés.

En général, n'oubliez pas que vous devez autoriser votre instance EC2 à accepter le trafic SSH entrant.

Pour ce faire, vous devez créer une règle spécifique pour le groupe de sécurité de votre instance EC2. Vous pouvez suivre ces étapes.

1. Accès à AWS Management Console
2. Ouvrir l' onglet EC2
3. Dans la liste Instances, sélectionnez l'instance qui vous intéresse
4. Dans l' onglet Description, vérifiez le nom du groupe de sécurité que votre instance utilise.
5. Encore une fois dans l' onglet Description, cliquez sur Afficher les règles et vérifiez si votre groupe de sécurité a une règle pour le trafic ssh entrant sur le port 22
6. Sinon, dans le menu Réseau et sécurité, sélectionnez Groupe de sécurité
7. Sélectionnez le groupe de sécurité utilisé par votre instance et cliquez sur l' onglet Entrant
8. À gauche de l'onglet Inbound, vous pouvez composer une règle pour le trafic entrant SSH:
   • Créez une nouvelle règle : SSH
   • Source : adresse IP ou sous - réseau à partir duquel vous souhaitez accéder à l'instance
   • Remarque : Si vous souhaitez accorder un accès illimité à votre instance, vous pouvez spécifier 0.0.0.0/0 , bien qu'Amazon ne recommande pas cette pratique
9. Cliquez sur Ajouter une règle puis sur Appliquer vos modifications
10. Vérifiez si vous pouvez désormais vous connecter à votre instance via SSH.

J'espère que cela peut aider quelqu'un comme m'a aidé.

Voilà comment j'ai résolu le problème

ssh -i <key> ec2-user@<ec2 ip>

J'ai résolu le problème juste sudoavant

sudo ssh -i mykey.pem myec2.amazonaws.com

Mais la bonne solution consiste à changer d'abord la propriété, puis à se connecter en tant qu'utilisateur normal, comme Janus Troelsen l'a dit ci-dessous. Dans mon cas, ce serait:

chown wellington:wellington key.pem

Essayez d'utiliser

sudo ssh -i mykey.pem ubuntu@<ec2_ip_public_dns>

OU

sudo ssh -i mykey.pem ec2-user@<ec2_ip_public_dns>

Une autre cause possible de cette erreur:

Lorsque le répertoire personnel de l'utilisateur est accessible en écriture de groupe , l'utilisateur ne peut pas se connecter.

(Reproduit sur l'instance Ubuntu.)

pour la micro-instance ubuntu 12.04 lts, ​​je devais définir le nom d'utilisateur comme option

ssh -i pemfile.pem -l ubuntu dns

Vous devez effectuer les étapes suivantes:

1. Ouvrez votre client ou terminal ssh si vous utilisez Linux.
2. Localisez votre fichier de clé privée et modifiez votre répertoire.
   cd <path to your .pem file>
3. Exécutez les commandes ci-dessous:
   chmod 400 <filename>.pem
ssh -i <filename>.pem ubuntu@<ipaddress.com>

Si l' ubuntuutilisateur ne fonctionne pas, essayez avec ec2-user.

J'ai eu du mal avec la même autorisation refusée, apparemment à cause de

key_parse_private2: missing begin marker 

Dans ma situation, la cause était le fichier de configuration ssh de l'utilisateur actuel (~ / .ssh / config).

En utilisant ce qui suit:

ssh -i ~/myKey.pem ec2-user@<IP address> -v 'exit'

Le résultat initial a montré:

debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug1: Hostname has changed; re-reading configuration
debug1: Reading configuration data /home/ec2-user/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config

... de nombreuses lignes de débogage coupées ici ...

debug1: Next authentication method: publickey
debug1: Trying private key: /home/ec2-user/somekey.pem
debug1: key_parse_private2: missing begin marker
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.

La troisième ligne ci-dessus est l'endroit où le problème réel a été identifié; cependant, j'ai cherché le message de débogage à quatre lignes du bas (ci-dessus) et j'ai été induit en erreur. Il n'y a pas de problème avec la clé mais je l'ai testée et comparé d'autres configurations.

Mon fichier de configuration ssh utilisateur réinitialise l'hôte via un paramètre global involontaire comme indiqué ci-dessous. La première ligne Host n'aurait pas dû être un commentaire.

$ cat config
StrictHostKeyChecking=no
#Host myAlias
        user ec2-user
        Hostname bitbucket.org
#        IdentityFile ~/.ssh/somekey
#        IdentitiesOnly yes

Host my2ndAlias
        user myOtherUser
        Hostname bitbucket.org
        IdentityFile ~/.ssh/my2ndKey
        IdentitiesOnly yes

J'espère que quelqu'un d'autre trouve cela utile.

J'ai oublié d'ajouter le nom d'utilisateur (ubuntu) lors de la connexion de mon instance Ubuntu. J'ai donc essayé ceci:

ssh -i /path/my-key-pair.pem my-ec2-instance.amazonaws.com

et la bonne façon était

ssh -i /path/my-key-pair.pem ubuntu@my-ec2-instance.amazonaws.com

Cela m'est arrivé plusieurs fois. J'ai utilisé Amazon Linux AMI 2013.09.2 et Ubuntu Server 12.04.3 LTS qui sont tous deux sur le niveau gratuit.

Chaque fois que j'ai lancé une instance, une autorisation m'a été refusée. Je n'ai pas vérifié cela, mais ma théorie est que le serveur n'est pas complètement configuré avant d'essayer de s'y connecter. Après quelques essais avec autorisation refusée, j'attends quelques minutes puis je peux me connecter. Si vous rencontrez ce problème, je vous suggère d'attendre cinq minutes et de réessayer.

Voici un scénario frustrant possible qui produit cette erreur:

Si vous installez une nouvelle instance à partir d'une AMI que vous avez créée d'une autre instance (par exemple, l'instance xyz), la nouvelle instance n'acceptera que la même clé que l'instance A utilisée. C'est tout à fait compréhensible mais cela devient confus car pendant le processus étape par étape de création de la nouvelle instance, vous êtes invité à sélectionner ou à créer une clé (à la toute dernière étape) qui ne fonctionnera pas.

Quelle que soit la clé que vous créez ou sélectionnez, seule la clé que vous utilisiez par exemple XYZ sera acceptée par la nouvelle instance.

Je me suis aussi débattu avec cela pendant un certain temps jusqu'à ce que je trouve ce qui suit:

eb ssh

Lorsque vous utilisez cela à partir du répertoire du projet, bingo-bango no muss no fuss, vous êtes dans

Dans mon propre cas, j'ai fait ce qui suit:

chmod 400 <key.pem>

ssh -i <key.pem> ec2-user@ec2_public_dns (for debian)

J'utilisais initialement une root@partie et j'ai reçu cette invite:

Please login as the user "ec2-user" rather than the user "root".

Je suis sous Windows avec WinSCP . Cela fonctionne très bien à la fois sur l'Explorateur de fichiers et sur PuTTY SSH Shell pour accéder à mon Amazon EC2-VPC Linux. Il n'y a rien à voir chmod pem filecar il utilise myfile.ppk converti par PuTTYgen à partir du fichier pem .

la même chose m'est arrivée, mais tout ce qui s'est passé, c'est que la clé privée s'est perdue du trousseau sur ma machine locale.

ssh-add -K

re-ajouté la clé, puis la commande ssh pour se connecter est retournée au travail.

Ce problème peut être résolu en vous connectant à la boîte Ubuntu à l'aide de la commande ci-dessous:

ssh -i ec2key.pem ubuntu@ec2-public-IP

J'ai eu deux fois les clés et la ligne de commande ssh correctes (je le sais parce que je duplique une instance Ubuntu 14.04 fonctionnelle), mais je n'ai tout simplement pas été capable de ssh dans une nouvelle instance, même après avoir attendu 5 minutes comme suggéré par Wade Anderson ci-dessus.

J'ai dû détruire et recréer la machine. Cela s'est produit à deux reprises. Comme je ne peux pas entrer au départ, je ne vois pas ce qui ne va pas.

Donc, si vous avez ce problème, essayez-le.

vous devez vérifier ces quelques choses:

1. Assurez-vous que votre adresse IP est correcte
2. Assurez-vous que vous utilisez la bonne clé
3. Assurez-vous que vous utilisez le nom d'utilisateur correct, vous pouvez essayer: 3.1. administrateur 3.2. utilisateur ec2 3.3. Ubuntu

J'ai eu le même problème et il a été résolu après avoir changé le nom d'utilisateur en ubuntu. Dans la documentation AWS a été mentionnée à l'utilisateur ec2-user mais ne fonctionne pas pour moi.

Ma clé privée a été définie sur permission 400 et il en résulte que l'autorisation refusée de la définir sur «644» m'a aidé.

key_load_private_type: autorisation refusée est l'erreur spécifique que j'obtenais

Solution: Sudo chmod 644 <key.pem>

Remarque: défini sur 644 est indispensable, il ne fonctionnait pas avec 400

Quand tu essaies de faire

ssh -i <.pem path> root@ec2-public-dns

Vous obtenez un message vous conseillant d'utiliser le ec2-user.

Please login as the user "ec2-user" rather than the user "root".

Alors utilisez

ssh -i <.pem path> ec2-user@ec2-public-dns

J'ai eu le même problème et c'est très étrange. Si vous pensez que vous faites tout ce qui est bien, suivez ceci: Parfois, il y a une confusion au sujet de l'utilisateur pour l'instance EC2 !! Parfois, vous obtenez ec2-user, ubuntu, centos, etc. Vérifiez donc votre nom d'utilisateur pour le machie !!

Connectez-vous avec l'utilisateur root ssh -i yourkey.pem (400 permission) root@<ip> Cela générera une erreur et vous donnera le nom d'utilisateur disponible . puis connectez-vous avec cet utilisateur.

C'est une chose basique, mais confirmez toujours quel utilisateur vous essayez de faire la connexion. Im mon cas était juste une distraction . J'essayais d'utiliser un utilisateur root :

ssh -i ~/keys/<key_name> root@111.111.111.111

Mais était un autre utilisateur :

ssh -i ~/keys/<key_name> dedeco@111.111.111.111

j'ai eu la même erreur mais une situation différente. pour moi, c'est arrivé à l'improviste après beaucoup de temps, j'ai pu réussir avec succès sur mon ordinateur distant. après beaucoup de recherches, la solution à mon problème était les autorisations de fichiers. c'est étrange bien sûr parce que je n'ai changé aucune permission sur mon ordinateur ou sur la télécommande appartenant aux fichiers / répertoires du ssh. donc du bon wiki archlinux le voici:

Pour la machine locale, procédez comme suit:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ecdsa

Pour la machine distante, procédez comme suit:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

après cela, mon ssh a recommencé à travailler sans l'autorisation refusée (publickey).

Un autre problème possible: ID de connexion incorrect

Cochez «Instructions d'utilisation»

Toutes les bonnes suggestions ci-dessus, mais ce que j'ai rencontré, c'est que j'ai sélectionné une instance prédéfinie. Une fois l'instance démarrée, consultez les instructions d'utilisation. J'ai utilisé de manière incorrecte l'identifiant de connexion de la clé privée lorsque, dans les instructions, j'étais censé utiliser «bitnami» (par exemple, bitnami @ domain -i key.pem)

J'ai eu une erreur similaire

debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: xxxx.pem
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
Permission denied (publickey).

Mon problème était que l'instance n'a pas démarré correctement en raison d'une erreur sur le script d'exécution au démarrage à partir de Step 3: Configure instance detail sousAdvanced details:

Ce que je pensais avoir entré:

#include
 https://xxxx/bootstrap.sh


Ce qui est réellement entré rompt la configuration de l'instance

#include

https://xxxx/bootstrap.sh

La clé publique côté instance n'a donc pas été créée

Il est sensible à la casse.

Incorrect: SSH EC2-user @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

Correct: SSH ec2-user @ XXX.XX.XX.XX -i MyEC2KeyPair.pem

J'ai pu SSH depuis une machine, mais pas depuis une autre. Il s'avère que j'utilisais la mauvaise clé privée.

La façon dont j'ai compris cela était en obtenant la clé publique de ma clé privée, comme ceci:

ssh-keygen -y -f ./myprivatekey.pem

Ce qui est sorti ne correspondait pas à ce qui était ~/.ssh/authorized_keyssur l'instance EC2.

Toutes les réponses les mieux classées ci-dessus sont exactes et devraient fonctionner dans la plupart des cas. Dans le cas où ils ne le seraient pas comme dans mon cas, je me suis simplement débarrassé de mon ~/.ssh/known_hostsfichier sur la machine que j'essayais de supprimer et cela a résolu le problème pour moi. J'ai pu me connecter par la suite.