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


355

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?


1
concernant votre 2ème question, connectez-vous avec filezilla pour télécharger / télécharger des fichiers, consultez ceci pour des instructions étape par étape - y2u.be/e9BDvg42-JI
Yasitha Chinthaka

2
êtes-vous sûr que vous n'avez pas utilisé "sudo chmod 600 pem file" cela provoquerait cette erreur et signifierait que vous auriez besoin d'utiliser sudo avant ssh
felbus

Pour certains systèmes d'exploitation Debian, le nom d'utilisateur est également admin. Au moins pour les versions 6.5 et 7.0.
Développeur

2
Si votre nom d'utilisateur est ec2-user, assurez-vous que vous n'utilisez pas ec2_user:)
grisaitis

2
Assurez-vous que l' utilisateur auquel vous essayez de vous connecter possède la clé répertoriée dans son $HOME/.ssh/authorized_keys fichier.
ILMostro_7

Réponses:


589

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.


2
Je ne pense pas que l'interface vous propose d'ajouter une clé à une instance en cours d'exécution, vous devrez donc en démarrer une nouvelle si vous avez perdu la clé de votre instance en cours d'exécution.
Thibault D.

81
# 2 a résolu mon problème, merci!
rckehoe

4
Cette réponse l'a résolu pour moi. Le nom d'utilisateur par défaut pour cette instance était "ubuntu", pas ec2-user comme indiqué dans le manuel AWS. Essayez d' utiliser'ec2-user@_your_EC2_IP.amazonaws.com
fem

7
Concernant # 1, mauvaise clé, l'ajout de -v (verbose) à la ligne de commande ssh m'a montré quelles clés il essayait et cela m'a amené à réaliser qu'il n'essayait pas la clé que j'avais générée parce que je l'avais nommée autre chose que id_rsa ou id_dsa.
KC Baltz

3
"ubuntu est le nom d'utilisateur pour la distribution AWS basée sur ubuntu," C'est ce qui m'a attiré. A été utilisé pour ec2-user, supposait juste que c'était toujours le nom d'utilisateur.
Nate Reed

48

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é.


1
La deuxième partie de votre réponse est fausse. Vous ne pouvez pas obtenir «Autorisation refusée (publickey)». si vous n'avez pas correctement défini les paramètres du pare-feu (groupes de sécurité). "Autorisation refusée (publickey)." est un message d'erreur de SSH et est une preuve que la configuration de vos groupes de sécurité est correcte. Au lieu de cela, vous obtiendrez "ssh: connectez-vous au port xxxx de l'hôte 22: connexion refusée"
Thibault D.

En bref: le message d'erreur indique que ce problème n'a rien à voir avec la configuration de vos groupes de sécurité.
Thibault D.

Tu as raison. La deuxième partie traite un autre type de problème. J'ai corrigé le poste.
Matteo Ceserani

Si vous avez perdu la clé, je pense qu'un moyen possible de le résoudre serait de prendre un instantané de l'instance, puis d'en démarrer une nouvelle avec une nouvelle clé. Dans ce cas, Amazon ajoute la nouvelle clé publique dans .ssh / authorized_keys, alors assurez-vous de supprimer l'ancienne par la suite. (et attention à ne pas supprimer le nouveau sinon vous revenez à votre premier numéro)
Thibault D.

43

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

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

1
Il me semblait que la clé pour moi ici était l'adresse DNS de l'hôte vs IP. ec2-user @ <ip> a fonctionné pour moi.
Zack

1
Solution aussi.
Tpojka

26

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

A fonctionné pour moi (a dû mettre à jour certains packages par la suite)!
user1429980

4
la solution appropriée consiste à modifier d'abord la propriété, puis à vous connecter en tant qu'utilisateur normal. utiliser sudo chown wellington:wellington key.pem.
Janus Troelsen

cela fonctionne, dans votre cas, car vous essayez de vous connecter à cette machine virtuelle sur Amazon qui prend en charge l' utilisateur root
Taimoor Changaiz

J'avais fait whoami puis sudo chown user_name_given_by_whoami xxxx.pem
Chirag Purohit

23

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>

1
Cela m'a aidé. Merci pour le conseil! : D
jehzlau

22

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.)


1
+1 J'aimerais avoir lu ça il y a 4 heures !!! Résolu mon problème où rsync -a remplaçait l'autorisation de mon dossier ec2-user.
Michael Hobbs,

Après avoir mv mon répertoire personnel, je n'ai pas pu me connecter.
Robert Moon

Alors, comment vous connectez-vous sur une machine qui est ainsi affectée, et vous ne pouvez pas vous y connecter du tout?
PKHunter

Corriger les autorisations sur le répertoire / home fonctionne aussi pour moi, merci! @AlexPetralia, votre lien est rompu = / mais a un post sur le forum aws en parlant de cela: forums.aws.amazon.com/message.jspa?messageID=334402
Liko

Quelqu'un comme Alex Petralia ou @Michael Hobbs peut-il republier (ou reformuler) la solution à cela?
Jakub Langr

7

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

cela a fonctionné pour moi, je suis surpris que cela ne fasse pas partie de la documentation aws pour discuter réellement des utilisateurs qui peuvent être nécessaires.
Ben

7

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.


5

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.


4

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

Erreur de débutant légitime. Si vous oubliez d'ajouter le nom d'utilisateur, il utilisera le nom d'utilisateur de l'utilisateur avec lequel vous êtes connecté sur votre ordinateur local.
Thibault D.

3

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.


J'ai attendu 5 minutes. et ça a marché. suis sur le niveau gratuit aussi. merci
Emeka Mbah

2

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.


Wow, je n'y ai jamais pensé. L'utilisation de l'ancienne clé a résolu le problème pour moi. Merci.
tolgamorf

Il ajoute généralement la nouvelle clé publique au fichier authorized_keys, rendant ainsi les deux utilisables. Cela fait un moment que je n'ai pas testé, mais c'est ce à quoi je m'attendrais.
Thibault D.20

2

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


2

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".

2

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 .


2

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.


Cela se produit à chaque fois après le redémarrage et j'ai besoin de réexécuter la commande ci-dessus pour toute solution de contournement.
silentsudo

1
je n'ai pas vérifié cela moi-même, mais la réponse vérifiée ici pourrait aider: apple.stackexchange.com/questions/254468/…
eiTan LaVi

1

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

1
Veuillez donner quelques détails.
Syeda Zunaira

1

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.


1

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.


1

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


1

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


1

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.


1

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

1

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).


0

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)


0

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


0

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


-1

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.


-1

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.


Bien que la suppression known_hostspuisse résoudre un problème lors de la connexion à un serveur qui a changé sa clé d'hôte (même si c'est une mauvaise approche de toute façon), je suis presque sûr qu'elle ne peut pas résoudre l' erreur "Autorisation refusée (publickey)" .
Martin Prikryl
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.