Permission denied (publickey) lors de l'Accès SSH à l'instance Amazon EC2

Je veux utiliser mon instance Amazon ec2, mais confronté à l'erreur suivante:

Permission denied (publickey).

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

Donné:

chmod  600 pem file.

Puis, cette commande

ssh -i /home/kashif/serverkey.pem  [email protected]

Mais avoir cette erreur:

Permission denied (publickey)

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

concernant votre 2ème question, se connecter avec filezilla pour charger/télécharger des fichiers, vérifiez les instructions étape par étape - y2u.être/e9BDvg42-JI
êtes-vous sûr de ne pas utiliser "sudo chmod 600 fichier pem" ce serait la cause de cette erreur et dire que vous auriez besoin d'utiliser sudo avant de ssh
Aussi pour certains système d'exploitation Debian le nom d'utilisateur est admin. Au moins pour 6.5 et 7.0 versions.
Vous voulez un accès en lecture seule sur votre instance clé: chmod 400 private.pem
chmod 600 m'a aidé.! merci!
Si votre nom d'utilisateur est ec2-user, assurez-vous que vous n'utilisez pas ec2_user 🙂
Assurez-vous que le utilisateur que vous essayez de vous connecter a la clé indiquée dans son $HOME/.ssh/authorized_keys fichier.
Quel est votre sshd ressembler? Vous pouvez avoir besoin d'ajouter PermitRootLogin without-password PasswordAuthentication yes à elle.
J'ai supprimé par erreur .ssh/authorized_keys fichiers comment puis-je me connecter à nouveau?
Si AWS EC2 est correctement réglé, il n'y aura pas de restrictions à l'intérieur de ubuntu répertoire en lecture/écriture à la maison directeur aura la Permission de restrictions.

InformationsquelleAutor Kashiftufail | 2013-08-31

589

Ce message d'erreur signifie que vous avez omis de s'authentifier.

Ce sont des raisons les plus courantes qui peuvent provoquer que:
1. Essayez de vous connecter avec la mauvaise touche. Êtes-vous sûr que cette instance est à l'aide de cette paire de clés?
2. Essayez de vous connecter avec le mauvais nom d'utilisateur. ubuntu est le nom d'utilisateur d'ubuntu en fonction AWS distribution, mais sur d'autres, c'est ec2-user (ou admin sur certains Debians, selon Bogdan Kulbida de réponse)(peut aussi être root, fedora, voir ci-dessous)
3. Essayez de vous connecter le mauvais hôte. Est-ce le bon accueil que vous essayez de vous connecter à?
Noter que 1. également se produire si vous avez foiré la /home/<username>/.ssh/authorized_keys fichier sur votre instance EC2.

Sur 2., les informations sur le nom d'utilisateur que vous devez utiliser est souvent absente de l'AMI de la description de l'Image. Mais vous pouvez en trouver dans AWS EC2 documentation, point 4. :
http://docs.aws.amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html

Utiliser la commande ssh pour se connecter à l'instance. Vous pourrez spécifier la clé privée (.pem) de fichier et nom_utilisateur@public_dns_name. Pour Amazon Linux, le nom d'utilisateur est ec2-utilisateur. Pour RHEL5, le nom de l'utilisateur racine ou ec2-utilisateur. 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 racine. Sinon, si ec2 et de l'utilisateur root ne fonctionne pas, vérifiez auprès de votre AMI fournisseur.

Enfin, être conscient qu'il ya beaucoup d'autres raisons pour lesquelles l'authentification échoue. SSH est généralement assez explicite sur ce qui s'est passé, si vous le soin d'ajouter la -v option de votre commande SSH et de lire la sortie, comme expliqué dans de nombreux autres réponses à cette question.
- J'ai supprimé une clé précédente. Maintenant, j'ai créer un autre. Mais dans istance description, il est de l'affichage que cette instance est à l'aide de "wer hare" clé. Alors que j'ai supprimer cette clé. Et créer un "nouveau-clés". Comment instance pouvez utiliser la nouvelle clé.
- Alors que j'ai de la lecture si vous avez perdu la clé que vous générez sur la création de l'instance. Ensuite, vous pouvez créer un autre pour accéder à votre instance.
- Eh bien, vous ne devriez jamais supprimer une clé à utiliser, parce que la seule façon pour vous d'avoir accès à la machine est avec cette clé, vous ne pouvez donc pas ajouter une nouvelle clé dans la authorizedkeys fichier sans l'ancien.
- Je ne pense pas que l'interface vous propose d'ajouter une touche à une instance en cours d'exécution de sorte que vous aurez à commencer une nouvelle si vous avez perdu la clé de votre instance en cours d'exécution.
- #2 fixe ma question, merci!
- Cette réponse résolu pour moi. Le nom d'utilisateur par défaut pour cette instance est "ubuntu", pas ec2-user comme il l'a dit dans l'AWS manuel. Essayez d'utiliser 'ec2-user@_your_EC2_IP.amazonaws.com
- +1 ec2-utilisateur résolu
- Sujet n ° 1, la mauvaise touche, l'ajout d'-v (verbose) pour le ssh en ligne de commande m'a montré que les touches sur lesquelles il a essayé et qui m'a conduit à réaliser qu'il n'essayait pas la clé que j'ai eu parce que j'avais nommé il autre chose que id_rsa ou id_dsa.
- chmod peut également être en cause. J'ai accidentellement changé les autorisations de root sur mon ec2-user dossier. Lol.
- Merci pour suggérer une modification pour cela, mais je pense qu'un utilisateur n'ayant pas accès à son répertoire personnel assez rare et peut-être pas la raison principale pour laquelle on obtient le "permission denied (clé publique)" erreur.
- 2ème point a fonctionné pour moi. Merci une tonne.
- ec2-l'utilisateur a fonctionné pour moi, mais comment pouvons-nous connaître le nom de l'instance?
- Je pense qu'il manque des informations dans la description de l'Image. Vous pouvez par ailleurs trouver dans AWS de la documentation: docs.aws.amazon.com/AWSEC2/latest/UserGuide/... au point 4. "[...] Il vous spécifiez la clé privée (.pem) de fichier et nom_utilisateur@public_dns_name. Pour Amazon Linux, le nom d'utilisateur est ec2-utilisateur. Pour RHEL5, le nom de l'utilisateur racine ou ec2-utilisateur. 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 ec2 et de l'utilisateur root ne fonctionne pas, vérifiez auprès de votre AMI fournisseur."
- J'ai accidentellement supprimé /home/<username>/.ssh/authorized_keys est-il un moyen de résoudre ce problème? j'ai besoin d'au moins télécharger tous les fichiers pour faire une sauvegarde...
- Il n'y a aucune façon vous pouvez vous connecter à votre instance, c'est la sécurité. Mais vous pouvez prendre une photo de votre instance et en commencer une nouvelle avec le "même" EBS et une nouvelle clé.
- "ubuntu est le nom d'utilisateur d'ubuntu en fonction AWS distribution," c'est Ce qui m'. A été utilisé pour ec2-utilisateur, juste supposé que c'était toujours le nom d'utilisateur.
- Pouvez vous s'il vous plaît aidez-moi avec la question suivante posté par moi stackoverflow.com/questions/39806657
- Merci @ThibaultD.
- Voulais juste un deuxième (ou troisième, ou quatrième...) le fait que je ne savais pas ec2-user était pas le nom d'utilisateur par défaut sur Ubuntu EC2 serveurs.
- Trois ans plus tard, ils n'ont pas encore fait ce assez clair... Mais depuis j'ai découvert d'Azur à la documentation et je pense toujours que AWS est beaucoup mieux documentée.
- #2 est le cas pour moi. merci@ThibaultD.
- #2 fixe la mienne, AWS, faut vraiment avoir correctement documentées dans leur instance de la page. Merci
- Vous devez également vous assurez-vous que le fichier authorized_keys a l'autorisation correcte, j'.e 644. C'est ce qui a résolu ce problème pour moi
- /home/<username>/.ssh/authorized_keys fichier a résolu mon problème. Il suffit de copier et coller votre propre ordinateur portable) clé SSH au serveur, dans ce fichier.
- Pour moi, c'était un .pem fichier avec le bon nom, mais de toute façon ne fonctionne pas. Après re-télécharger le fichier de clé et de le remplacer dans la ~/.ssh il a travaillé
- vous êtes le véritable MVP
InformationsquelleAutor Thibault D.
48

Dans ce cas, le problème se pose de la perte de la Paire de Clés. À ce sujet:
- Il n'y a aucun moyen de changer de 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 Elastic Beanstalk Onglet
3. Sélectionnez votre application de Toutes les Applications Onglet
4. De gauche côté menu, sélectionnez Configuration
5. Cliquez sur le Instances Engins
6. Dans Serveur Formulaire de vérifier la EC2 Paire de Clés d'entrée et de sélectionner votre nouvelle Paire de Clés. Vous pourriez avoir à actualiser la liste afin de voir une nouvelle Paire de Clés, vous êtes juste créé.
7. Enregistrer
8. Elastic Beanstalk créons pour vous de nouvelles instances associées à la nouvelle paire de clés.
En général, n'oubliez pas que vous devez permettre à votre instance EC2 d'accepter entrant trafic SSH.

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 EC2 Onglet
3. De Instances liste, sélectionnez l'instance que vous êtes intéressé à
4. Dans le Onglet Description chek le nom de la Groupe de Sécurité de l'instance à l'aide.
5. De nouveau dans Onglet Description cliquez sur les règles de Vue et vérifiez si votre Groupe de Sécurité a une règle pour le trafic ssh sur le port 22
6. Si non, dans Réseau & Sécurité menu sélectionnez Groupe de Sécurité
7. Sélectionnez le Groupe de Sécurité utilisé par votre exemple et cliquez sur Onglet entrée
8. Sur la gauche de l'Onglet entrée, vous pouvez composer une règle pour SSH trafic entrant:
  - Créer une nouvelle règle: SSH
  - Source: adresse IP ou sous-réseau à partir de laquelle vous voulez accéder à l'instance
  - Note: Si vous voulez accorder accès illimité à votre exemple, vous pouvez spécifier 0.0.0.0/0, bien que Amazon recommande pas cette pratique
9. Cliquez sur Ajouter une Règle et puis Appliquer Vos Modifications
10. Vérifier si vous êtes maintenant en mesure de vous connecter à votre instance via SSH.
J'espère que cela peut aider quelqu'un d'aussi m'a aidé.
- La deuxième partie de votre réponse est fausse. Vous ne pouvez pas obtenir de "Permission denied (publickey)." si vous n'avez pas réglé correctement les paramètres du pare-feu (Groupes de Sécurité). "Permission denied (publickey)." c'est un message d'erreur de SSH et c'est une preuve que vos Groupes de Sécurité de la configuration est à droite. Au lieu de cela, vous obtenez "ssh: connect to host x.x.x.x port 22: Connexion refusée"
- Longue histoire courte: Le message d'erreur indique que cette question n'a rien à voir avec vos Groupes de Sécurité de la configuration.
- Vous avez raison. La deuxième partie traite un autre type de problème. J'ai corrigé le post.
- Si vous avez perdu la clé, je pense, un moyen possible de le résoudre serait de prendre un instantané de l'instance et en commencer une nouvelle avec une nouvelle clé. Dans ce cas, Amazon ajoute la nouvelle clé publique .ssh/authorized_keys alors assurez-vous de supprimer l'ancienne version par la suite. (et attention à ne pas supprimer le nouveau ou vous êtes de retour à votre première question)
InformationsquelleAutor Matteo Ceserani
43

C'est comment j'ai résolu le problème
```
ssh -i <key> ec2-user@<ec2 ip>
```
- Il semblait pour moi, l'essentiel ici est l'adresse DNS de l'hôte vs IP. ec2-utilisateur@<ip> a fonctionné pour moi.
- La Solution ainsi.
InformationsquelleAutor Deepti Kohli
26

J'ai résolu le problème vient de mettre sudo avant
```
sudo ssh -i mykey.pem myec2.amazonaws.com
```
Mais la bonne solution est de changer la propriété d'abord, et ensuite vous connecter en tant qu'utilisateur normal que Janus Troelsen dit ci-dessous. Dans mon cas, ce serait:
```
chown wellington:wellington key.pem
```
- A fonctionné pour moi (dû mettre à jour certains paquets après tout de même)!
- la bonne solution est de changer la propriété d'abord, et ensuite vous connecter en tant qu'utilisateur normal. utilisation sudo chown wellington:wellington key.pem.
- il est au travail, dans votre cas parce que vous tentez de vous connecter cette machine virtuelle à Amazon qui soutien racine utilisateur
- J'avais fait whoami puis sudo chown user_name_given_by_whoami xxxx.pem
InformationsquelleAutor Wellington Lorindo

Essayez d'utiliser

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

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

Cela m'a aidé. Merci pour l'astuce! 😀

InformationsquelleAutor Abhishek Gupta

22

Une autre cause possible de cette erreur:

Lorsque l'utilisateur répertoire de base du groupe est accessible en écriture, l'utilisateur ne peuvent pas se connecter.

(Reproduit sur Ubuntu instance.)
- Cela a été très utile, merci! Résolu ma question ici: stackoverflow.com/questions/31418785/...
- +1 j'avais lu cette 4 heures!!! Résolu mon problème où rsync -a est l'écrasement de la permission de mon ec2-dossier de l'utilisateur.
- Après je mv mon répertoire home, je n'ai pas de connexion.
- Alors, comment voulez-vous vous connecter sur une machine qui a ainsi touché, et vous ne pouvez pas vous connecter à tout?
- Réparer les autorisations sur le répertoire /home fonctionne pour moi aussi, merci! @AlexPetralia, votre lien est cassé =/ mais a un post dans aws forum parler à ce sujet: forums.aws.amazon.com/message.jspa?messageID=334402
- Quelqu'un peut comme Alex Petralia ou @Michael Hobbs reposter (ou de retraiter) la solution?
- chmod 755 sur le répertoire de base d'utilisateurs
- Pouvez vous s'il vous plaît aidez-moi avec la question suivante posté par moi stackoverflow.com/questions/39806657
InformationsquelleAutor Stepan
7

pour ubuntu 12.04 lts instance micro j'ai dû mettre le nom d'utilisateur de l'option
```
ssh -i pemfile.pem -l ubuntu dns
```
- cela a fonctionné pour moi, je suis surpris qu'il ne fait pas partie de l'aws documentation pour en discuter les utilisateurs qui peuvent être nécessaires.
InformationsquelleAutor dc10
7

Vous devez faire les étapes suivantes:
1. Ouvrez votre client ssh terminal ou si vous utilisez Linux.
2. Localiser votre fichier de clé privée et de changer votre répertoire.
  
  cd <path to your .pem file>
3. Exécuter les commandes ci-dessous:
  
  chmod 400 <filename>.pem
  
  ssh -i <filename>.pem ubuntu@<ipaddress.com>
Si ubuntu utilisateur ne fonctionne pas, essayez avec ec2-user.

InformationsquelleAutor Rabinarayan Panigrahi

J'ai du mal avec la même erreur permission denied apparemment en raison de

key_parse_private2: missing begin marker

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

Utilisant les éléments suivants:

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

La sortie initiale 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 couper 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 où le problème réel a été identifié; toutefois, j'ai cherché dans le message de débogage quatre lignes à partir du bas (ci-dessus) et a été induit en erreur. Il n'y a pas un problème avec la clé, mais je l'ai testé et comparé à d'autres configurations.

Mon utilisateur ssh fichier de config de réinitialisation de l'hôte via involontaire d'un paramètre global, comme illustré ci-dessous. Le premier Hôte de la ligne ne doit pas avoir été 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.

Génial!! Merci!!

InformationsquelleAutor Ben Paz

4

J'ai oublié d'ajouter le nom d'utilisateur (ubuntu) lors de la connexion de mon Ubuntu instance. J'ai donc essayé ceci:
```
ssh -i /path/my-key-pair.pem my-ec2-instance.amazonaws.com
```
et la manière correcte a été
```
ssh -i /path/my-key-pair.pem [email protected]
```
- Pièce de théâtre débutant erreur. Si vous oubliez d'ajouter le nom d'utilisateur, puis il va utiliser le nom d'utilisateur de l'utilisateur que vous êtes connecté avec votre ordinateur local.
InformationsquelleAutor JohnP
3

Ce qui m'est arrivé plusieurs fois. J'ai utilisé de l'AMI Amazon Linux 2013.09.2 et le Serveur Ubuntu 12.04.3 LTS qui sont à la fois sur le niveau gratuit.

Chaque fois que j'ai lancé un exemple, j'ai la permission refusé de se présenter. Je n'ai pas vérifié cela, mais ma théorie est que le serveur n'est pas complètement mis en place avant j'ai essayer de faire un ssh sur elle. Après quelques essais avec la permission refusée, j'attends quelques minutes et puis je suis en mesure de se connecter. Si vous rencontrez ce problème, je suggère d'attendre cinq minutes et essayez de nouveau.
- J'ai attendu 5 minutes. et cela a fonctionné. suis sur niveau gratuit trop. merci
InformationsquelleAutor Wade Anderson
2

Ici est possible frustrant scénarios qui produit cette erreur:

Si vous êtes déjeunant une nouvelle instance d'un AMI que vous avez créé d'une autre instance (instance dire xyz), puis la nouvelle instance n'acceptera la même clé que l'exemple utilisé. Ce qui est totalement compréhensible, mais il devient source de confusion, car lors de l'étape par étape le processus de création de la nouvelle instance, vous êtes invité à sélectionner ou créer une clé (à la dernière étape) qui ne fonctionnera pas.

Quelle que soit la touche que vous créez ou sélectionnez, seule la touche que vous utilisez par exemple XYZ sera accepté par la nouvelle instance.
- Wow, je n'ai jamais pensé à ce sujet. À l'aide de la clé ancienne résolu le problème pour moi. Merci.
- Habituellement, il ajoute la nouvelle clé publique pour le fichier authorized_keys, ce qui rend à la fois utilisable. Il a été un moment depuis que j'ai testé, mais c'est ce que je m'attends à arriver.
InformationsquelleAutor Seeker
2

J'ai du mal avec ce trop pendant un certain temps jusqu'à ce que j'ai trouvé le suivant:
```
eb ssh
```
Lorsque vous l'utilisez qu'à partir du répertoire du projet, bingo bango pas muss pas de chichi, vous êtes dans

InformationsquelleAutor JedA

Dans mon propre cas, j'ai fait la suivante:

chmod 400 <key.pem>

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

J'ai d'abord été à l'aide de root@ partie et j'ai eu ce message:

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

InformationsquelleAutor AJNinja

2

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

InformationsquelleAutor Chetabahana
2

même chose m'est arrivé, mais tout ce qui se passait, c'est que la clé privée s'est perdu depuis le trousseau de clés sur ma machine locale.

ssh-add -K

re-ajout de la clé, puis la commande ssh pour se connecter retourné au travail.
- Il arrive à chaque fois après le redémarrage et j'ai besoin de ré-exécuter la commande ci-dessus aucune solution de contournement pour ce.
- n'ai pas vérifié moi-même, mais le vérifiée réponse ici pourraient vous aider: apple.stackexchange.com/questions/254468/...
InformationsquelleAutor eiTan LaVi
1

Ce problème peut être résolu par vous connecter à Ubuntu à l'aide de la boîte de commande ci-dessous:
```
ssh -i ec2key.pem ubuntu@ec2-public-IP
```
- Veuillez Donner quelques détails.
InformationsquelleAutor Prajith
1

J'ai deux fois avait les clés et ssh en ligne de commande correcte (je le sais car je suis la duplication d'un travail Ubuntu 14.04 exemple), mais tout simplement pas été en mesure de ssh dans une nouvelle instance, même après une attente de 5 minutes, comme suggéré par Wade Anderson ci-dessus.

J'ai eu à le détruire et de le re-créer la machine. Ce qui est arrivé à deux reprises. Puisque je ne peux pas obtenir dans un premier temps, je ne vois pas quel est le problème.

Donc, si vous rencontrez ce problème, essayez que.

InformationsquelleAutor Greg Bell
1

vous devez vérifier ces quelques points:
1. Assurez-vous que votre adresse IP est correcte
2. Assurez-vous d'utiliser la bonne Clé
3. Assurez-vous que vous utilisez le bon nom d'utilisateur, vous pouvez essayer:
  3.1. admin
  3.2. ec2-utilisateur
  3.3. ubuntu
J'ai eu le même problème, et il a résolu après j'ai changé de nom d'utilisateur d'ubuntu. Dans AWS de la documentation mentionnée à l'utilisateur ec2-utilisateur mais de toute façon ne fonctionne pas pour moi.

InformationsquelleAutor Mehran
1

Ma clé privée a été mis à l'autorisation 400 et résultant de refus d'Autorisation paramètre à '644' m'a aidé .

key_load_private_type: Permission denied est l'erreur que je recevais

Solution:
Sudo chmod 644 <key.pem>

Remarque: pour 644 se doit, il ne travaillait pas avec 400

InformationsquelleAutor Kuldeep Dangi
1

Lorsque vous essayez de faire

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

Vous obtenez un message vous indiquant l'utilisation de la ec2-user.

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

Donc utiliser

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

InformationsquelleAutor Jerome Anthony
1

J'ai eu le même problème et sa très étrange. Si vous croyez que vous faites toutes les bonnes que de suivre ce:
Quelques fois il y a confusion à propos de l'utilisateur pour l'instance EC2!! Quelques fois, vous aurez ec2-utilisateur, ubuntu, centos, etc. Donc, vérifiez votre nom d'utilisateur pour la machie!!

Connecter avec l'utilisateur root
ssh -i yourkey.pem (400 permission) root@<ip>
Qu'il va jeter l'erreur et va vous donner le nom d'utilisateur disponibles. ensuite vous connecter avec cet utilisateur.

InformationsquelleAutor Manoj Sahu
1

C'est une chose de base, mais toujours de confirmer l'utilisateur que vous essayez de faire la connexion. Im mon cas était juste une distraction. J'ai essayé à l'aide d'un racine utilisateur:
```
ssh -i ~/keys/<key_name> [email protected]
```
Mais a été un autre utilisateur:
```
ssh -i ~/keys/<key_name> [email protected]
```
InformationsquelleAutor Andre Araujo
1

j'ai eu la même erreur, mais la situation est différente. pour moi, il est arrivé à l'improviste après beaucoup de temps je pourrais ssh avec succès pour mon ordinateur distant là-bas. après beaucoup de recherche de la solution à mon problème étaient les autorisations de fichier. il est étrange, bien sûr, parce que je n'ai pas modifier les autorisations dans le poste de travail ou à distance l'un appartenant à l'ssh fichiers/répertoires. donc, à partir de la bonne wiki archlinux ici, il est:

Pour la machine locale ce faire:
```
$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ecdsa
```
Pour la machine distante faire:
```
$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys
```
après que mon ssh commencé à travailler à nouveau, sans la permission denied (publickey) chose.

InformationsquelleAutor Azriel
0

Un autre Problème: la Mauvaise ID de connexion

Cochez La Case 'Instructions D'Utilisation'

Toutes les bonnes suggestions ci-dessus, mais ce que j'ai rencontré était que j'ai sélectionné un pré-faites de l'instance. Après que l'instance a commencé , regardez les instructions d'utilisation. J'ai utilisé de manière incorrecte id de connexion de la clé privée lorsque, dans les instructions, je devais utiliser 'bitnami" (par exemple, bitnami@domaine -j'ai la clé.pem)

InformationsquelleAutor Mike Q
0

J'ai eu la même erreur
```
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 de l'erreur sur la course-sur-script de démarrage de Step 3: Configure instance detail sous Advanced details:

Ce que je pensais, j'ai entré:

#include  https://xxxx/bootstrap.sh 

Ce qui s'est réellement entré dans les pauses de l'instance d'installation

#include

https://xxxx/bootstrap.sh

Donc la clé publique sur l'instance côté n'a pas été créé

InformationsquelleAutor RNA
0

Il est sensible à la casse.

Mal : SSH EC2-utilisateur@XXX.XX.XX.XX -je MyEC2KeyPair.pem

Correct : SSH ec2-utilisateur@XXX.XX.XX.XX -je MyEC2KeyPair.pem

InformationsquelleAutor Tanmay
-1

J'ai été en mesure de SSH depuis un ordinateur, mais pas de l'autre. En fait, j'ai l'utilisation de la mauvaise clé privée.

La façon dont j'ai pensé que c'était par l'obtention de la clé publique à partir de ma clé privée, comme ceci:

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

Ce qui vient de sortir ne correspond pas à ce qui était dans ~/.ssh/authorized_keys sur l'instance EC2.

InformationsquelleAutor Petko M
-1

Tous les meilleurs classé les réponses ci-dessus sont exacts et devrait fonctionner pour la plupart des cas. Dans le cas où ils ne sont pas comme dans mon cas, j'ai tout simplement eu débarrasser de mon ~/.ssh/known_hosts fichier sur la machine que j'essayais de ssh depuis et qui a résolu le problème pour moi. J'ai été en mesure de se connecter par la suite.
- Lors de la suppression de known_hosts peut résoudre un problème lors de la connexion au serveur qui a changé sa clé d'hôte (alors que c'est une mauvaise approche de toute façon), je suis sûr qu'on ne peut pas résoudre "Permission denied (publickey)" d'erreur.
InformationsquelleAutor pbegle

Vous devez vous connecter pour publier un commentaire.