Erreur d'autorisations lors de la connexion à EC2 via SSH sous Mac OSx
Je suis nouveau sur EC2. J'ai créé mes identifiants de sécurité à partir de ce site:
http://paulstamatiou.com/how-to-getting-started-with-Amazon-ec2
Cela a très bien fonctionné, j'ai redémarré et maintenant, lorsque j'essaie de me connecter, je reçois une invite de connexion/mot de passe. (Ce que je n'ai jamais mis en place.) Après plusieurs tentatives, j'obtiens cette erreur:
Autorisation refusée (publickey, gssapi-with-mic).
Qu'est-ce que je fais mal?
Je peux penser à deux possibilités, bien qu’elles soient toutes deux mentionnées dans le lien que vous avez mentionné:
Vous ne spécifiez pas le fichier de paire de clés SSH ou le nom d'utilisateur correct dans la commande ssh que vous utilisez pour vous connecter au serveur:
ssh -i [chemin d'accès complet au fichier de paire de clés] root @ [nom d'hôte ou adresse IP de l'instance EC2]
Vous ne disposez pas des autorisations appropriées sur le fichier de paire de clés; Tu devrais utiliser
chmod 600 [fichier de paire de clés]
pour vous assurer que vous seul pouvez lire ou écrire le fichier.
Essayez d’utiliser l’option -v avec ssh pour obtenir plus d’informations sur l’échec exact et publiez-la ici si vous souhaitez obtenir de l’aide.
[Mise à jour]: OK, c’est ce que vous devriez auriez vu si tout était configuré correctement:
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Trying private key: ec2-keypair
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey).
Exécutez-vous la commande ssh à partir du répertoire contenant le fichier ec2-keypair? Si tel est le cas, essayez de spécifier -i ./ec2-keypair simplement pour éliminer les problèmes de chemin. Vérifiez également le fichier "ls -l [chemin complet de ec2-keypair]" et assurez-vous que les autorisations sont 600 (affiché sous la forme rw -------). Si rien de tout cela ne fonctionne, je soupçonne le contenu du fichier de paire de clés, essayez donc de le recréer en suivant les étapes de votre lien.
La clé pour que je puisse me connecter était d'utiliser l'utilisateur "utilisateur ec2" plutôt que root. C'est à dire.:
ssh -i [full path to keypair file] ec2-user@[EC2 instance hostname or IP address]
Dans mon cas, c'est parce que l'autorisation pour mon répertoire personnel est 775 et que SSH n'en est pas satisfaite. Cela devrait fonctionner après avoir exécuté:
server$ chmod go-w ~/
server$ chmod 700 ~/.ssh
server$ chmod 600 ~/.ssh/authorized_keys
J'ai eu une expérience très similaire cet après-midi. J'étais en train de configurer Django sur EC2 et, tout à coup, je ne peux plus utiliser SSH dans la boîte. Heureux d'avoir toujours une connexion active, j'ai donc modifié /etc/ssh/sshd_config pour définir:
PasswordAuthentication yes
et définir le mot de passe pour ec2-user, je peux alors me connecter en entrant le mot de passe.
Cependant, après quelques recherches sur Google, j'ai trouvé ce fil de discussion: http://ubuntuforums.org/showthread.php?t=577279 . Il s’est avéré que lors de la configuration de Django, j’ai modifié l’autorisation pour mon répertoire personnel, et SSH est très strict à ce sujet. Donc, l'autorisation du fichier doit être définie correctement.
J'avais rencontré ce problème aussi.Et j'ai trouvé que c'était parce que j'avais oublié d'ajouter le nom d'utilisateur avant le nom d'hôte: Comme ceci:
ssh -i test.pem ec2-32-122-42-91.us-west-2.compute.amazonaws.com
et j'ajoute le nom d'utilisateur:
ssh -i test.pem [email protected]
Ça marche!
Marquage de la réponse à la mecca831:
ssh -v -i générer-key.pem [email protected]
[[email protected]] ~ $ Sudo passwd ec2-user newpassword newpassword
[[email protected] ~] $ Sudo vi /etc/ssh/sshd_config Modifiez le fichier comme suit:
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication yes
#PermitEmptyPasswords no
# EC2 uses keys for remote access
#PasswordAuthentication no
Sauvegarder
[[email protected]] ~ service Sudo sshd stop [[email protected] ~] $ service Sudo sshd start
vous devriez pouvoir quitter et ssh comme suit:
ssh [email protected]
et être invité pour mot de passe n'a plus besoin de la clé.
Êtes-vous sûr d'avoir utilisé la bonne instance? J'ai rencontré ce problème et me suis rendu compte qu'environ 4 des instances d'ubuntu que j'ai essayées ne disposaient pas de serveurs SSH installés.
Pour une liste de bons serveurs, voir "Récupération des images" à mi-chemin. On dirait que vous utilisez peut-être autre chose ... le nom d'utilisateur par défaut est Ubuntu sur ces images.
Après environ une demi-heure de recherche et d’essai de déboguer ceci, j’ai été capable de le comprendre. Ma situation impliquait que j'utilise le même fichier pem pour deux instances ec2 différentes et que cela fonctionne pour l'une et non pour l'autre.
Mon premier exemple sur lequel je travaillais était le standard aws linux AMI amzn-AMI-hvm-2014.03.2.x86_64-ebs. J'ai simplement utilisé
ssh -i mypemfile.pem ec2-user@myec2ipaddress
et cela a fonctionné.
J'ai ensuite lancé une instance de Fedora Fedora-x86_64-19-20-20140407-sda et essayé la même commande, mais j'ai continué à obtenir:
Permission denied (publickey,gssapi-keyex,gssapi-with-mic).
Après avoir changé mon nom d'utilisateur d'ec2-user en Fedora, cela a fonctionné!
ssh -i mypemfile.pem Fedora@myec2address
+1
J'ai remarqué que pour certaines AMI telles qu'Amazon Linux, [email protected] fonctionnerait. Mais pour une image d'ubuntu, je devais utiliser ubuntu @ à la place. Cela n’a jamais posé de problème avec le .pem, mais uniquement avec le nom de l’utilisateur.
J'ai pu me connecter en utilisant ec2-user
ssh -i [chemin d'accès complet au fichier de paire de clés] ec2-user @ [nom d'hôte ou adresse IP de l'instance EC2]
Rien de ce qui précède ne m'a aidé, mais le fait de jouer avec l'utilisateur m'a semblé prometteur. Pour ma config utilisant 'Ubuntu' avait raison .....
ssh -i [chemin d'accès complet au fichier de paire de clés] ubuntu @ [nom d'hôte ou adresse IP de l'instance EC2]
Je déconseille de définir un mot de passe, comme le suggèrent d’autres réponses. L'utilisation du fichier de clé est à la fois plus sûre (personne ne peut deviner vos mots de passe) et plus pratique (une fois que vous avez configuré un fichier de configuration). Voici un ~/.ssh/config de base:
Host my-ec2-server
HostName 11.11.11.11
User ec2-user
IdentityFile /path/to/generated-key.pem
Maintenant, vous pouvez simplement taper ssh my-ec2-server et vous y êtes! Et comme mentionné également dans d'autres réponses, utilisez -v pour obtenir des informations supplémentaires lorsque votre connexion ne fonctionne pas.
Si le problème est cohérent et s'est produit environ 10 à 15 fois d'affilée, même après avoir modifié les autorisations de fichiers en 400 ou 600, il est très probable que quelque chose ne va pas sur l'instance ec2. Assurez-vous donc que: 1. vérifiez les journaux lorsque vous essayez de ssh en utilisant l'instance en ajoutant -v à la fin et voyez si l'un ou l'autre donne quelque chose de spécifique. 2. Assurez-vous que vous utilisez le nom correct pour ssh, comme Ubuntu. Cela dépend peut-être de la distribution Linux et des utilisateurs que vous avez ajoutés et soit vous avez donné l’autorisation pour "utilisateur root" ssh . Si rien ne vous aide, suivez la documentation ici https://docs.aws.Amazon.com/ AWSEC2/latest/UserGuide/TroubleshootingInstancesConnecting.html # TroubleshootingInstancesConnectingMindTerm Pour résoudre ce problème. Cela a aidé dans mon cas, et cela est dû à des autorisations de répertoires/fichiers gâchées.
Si un fichier PPK fonctionne sur un PC, exportez-le en tant que fichier OpenSSH en utilisant puttygen.exe pour PC et utilisez-le sur Mac (n’importe quel ordinateur Unix).
J'avais la même erreur -
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: Next authentication method: publickey
debug1: Trying private key: ec2-keypair
debug1: read PEM private key done: type RSA
debug1: Authentications that can continue: publickey,gssapi-with-mic
debug1: No more authentication methods to try.
Permission denied (publickey,gssapi-with-mic)
Comme j'utilisais un fichier PPK sous Windows, j'ai suivi les étapes décrites ci-dessus et Bingo!
$ ssh -i ec2-openssh-key racine @ ec2-instance-ip
J'ai eu le même problème en utilisant AWS Toolkit for Eclipse. J'ai créé l'instance de prise en main OK et ouvert un shell. Cependant, l'utilisateur était défini sur ec2-user. J'ai utilisé la commande Open Shell As ... et défini l'utilisateur sur root. Ensuite cela a fonctionné.