Autorisation refusée (publickey) lorsque L'accès SSH à L'instance Amazon EC2 [fermé]

Dans ce cas, le problème provient d'une paire de clés perdue. À ce sujet:

• il n'y a aucun moyen de changer 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 Haricot Élastique Onglet
3. Sélectionnez votre application dans Toutes les Applications onglet
4. dans le menu de gauche sélectionnez Configuration
5. Cliquez sur leInstances Vitesse
6. dans le formulaire Server Vérifiez l'entrée EC2 key Pair 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. Enregistrer
8. Elastic Beanstalk créera pour vous de nouvelles instances associées à la nouvelle clé pair.

En général, rappelez-vous 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 onglet EC2
3. dans la liste Instances Sélectionnez l'instance qui vous intéresse
4. dans l'onglet Description chek le nom de la Groupe de sécurité 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. Si non, dans Network & Security menu select Groupe de Sécurité
7. Sélectionnez le groupe de sécurité utilisé par votre instance et cliquez sur onglet entrant
8. à gauche de L'onglet Inbound, vous pouvez composer une règle pour SSH inbound circulation:
   • Créer une nouvelle règle: SSH
   • Source: adresse IP ou sous-réseau à partir duquel vous souhaitez 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. Sur Ajouter une Règle, puis Appliquer Vos Modifications
10. Vérifiez si vous êtes maintenant en mesure de vous connecter à votre exemple via SSH.

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

C'est ainsi que j'ai résolu le problème

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

J'ai résolu le problème en mettant simplement sudo avant

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

Mais la bonne solution est de changer d'abord la propriété, puis de se connecter en tant qu'utilisateur normal, comme L'a dit Janus Troelsen 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 l'instance ubuntu 12.04 LTS micro, j'ai dû 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é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.

J'ai lutté avec la même erreur d'Autorisation refusée apparemment en raison 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'

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

... beaucoup de 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é au message de débogage quatre lignes du bas (ci-dessus) et j'ai été induit en erreur. Y n'est pas un problème avec la clé mais je l'ai testé 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 D'hôte 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 trouvera 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 libre.

Chaque fois que j'ai lancé une instance, j'ai la permission refusée. Je n'ai pas vérifié cela mais ma théorie est que le serveur n'est pas complètement configuré avant que j'essaie de ssh dedans. Après quelques essais avec la permission refusée, j'attends quelques minutes et puis je suis capable de me connecter. Si vous rencontrez ce problème, je suggère d'attendre cinq minutes et essayer à nouveau.

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

Si vous lancez une nouvelle instance à partir d'une AMI que vous avez créée d'une autre instance (par exemple 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 déroutant car pendant le processus étape par étape de création de la nouvelle instance, il vous est demandé de sélectionner ou de créer une clé (à la toute dernière étape) qui ne fonctionnera pas.

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

J'ai lutté avec cela pendant un moment aussi jusqu'à ce que je trouve ce qui suit:

eb ssh

Lorsque vous utilisez cela dans le répertoire du projet, bingo-bango no muss no chichi, 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 root@ part et j'ai eu cette invite:

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

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

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

Ssh-add-K

A 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 à Ubuntu box en utilisant la commande ci-dessous:

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

J'ai deux fois eu des clés et une ligne de commande ssh correcte (je sais parce que je duplique une instance Ubuntu 14.04), 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. Ce qui est arrivé à 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 cela.

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 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 avoir changé de nom d'utilisateur pour ubuntu. Dans la documentation AWS a été mentionné à l'utilisateur ec2-user mais en quelque sorte ne fonctionne pas pour moi.

Ma clé privée était définie sur permission 400 et résultait en une autorisation refusée en le définissant sur ' 644 ' m'a aidé .

Key_load_private_type: Permission denied est l'erreur que je recevais

Solution: Sudo chmod 644 <key.pem>

Note: mis à 644 est indispensable, il ne fonctionnait pas avec 400

Lorsque vous essayez de faire

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

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

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

Utilisez donc

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 croyez que vous faites tout le bien que de suivre ceci: Parfois, il y a confusion à propos de l'utilisateur pour L'instance EC2!! Parfois, vous obtenez ec2-user, ubuntu, centos etc. Alors vérifiez votre nom d'utilisateur pour le machie!!

La Connexion avec l'utilisateur root ssh -i yourkey.pem (400 permission) root@<ip> il lancera une erreur et vous donnera le nom d'utilisateur disponible . puis connectez-vous avec cet utilisateur.

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

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

Mais a 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, 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. c'est étrange bien sûr parce que je n'ai pas changé les autorisations dans mon ordinateur ou celui distant appartenant aux fichiers / répertoires du ssh. donc, à partir du bon archlinux wiki Voici:

Pour la machine locale, procédez comme suit:

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

Pour le la machine distante fait cela:

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

Après cela, mon ssh a commencé à fonctionner à nouveau sans la chose permission denied (publickey).

Un autre problème Possible: mauvais identifiant de connexion

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é-faite. Une fois l'instance démarrée, consultez les instructions d'utilisation. J'ai incorrectement utilisé l'id de connexion de la clé privée quand 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 ne démarrait pas correctement en raison d'une erreur sur le script d'exécution au démarrage de Step 3: Configure instance detail sous Advanced details:

Ce que je pensais être entré:

#include
 https://xxxx/bootstrap.sh


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

#include

https://xxxx/bootstrap.sh

Donc, la clé publique du côté de l'instance n'a pas été créée

C'est sensible à la casse.

Mauvais: 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 d'une machine, mais pas d'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 correspond pas à ce qui était dans ~/.ssh/authorized_keys sur L'instance EC2.

Toutes les réponses les mieux classées ci-dessus sont précises et devraient fonctionner dans la plupart des cas. Dans le cas où ils ne le font pas comme dans mon cas, je me suis simplement débarrassé de mon fichier ~/.ssh/known_hosts sur la machine à partir de laquelle j'essayais de ssh et cela a résolu le problème pour moi. J'ai été en mesure de se connecter par la suite.