SSH EC2 demandant un mot de passe
Je viens de configurer mon serveur EC2 en suivant exactement cette vidéo ici - http://www.youtube.com/watch?v=bBajLxeKqoY
J'ai même choisi le même type de serveur, tout s'est bien passé jusqu'à ce qu'il demande le mot de passe root à mon serveur EC2 ...
Aucune suggestion?
Mise à jour
Mise à jour de cette réponse en raison de l'activité:
Selon que le système est Ubuntu ou Rhel, l'utilisateur varie.
Pour Ubuntu c'est
ssh -i my-pem-file.pem ubuntu@my-ec2-instance-address
Pour RHEL, c'est
ssh -i my-pem-file.pem root@my-ec2-instance-address
La connexion à une instance ec2 ne nécessite pas de mot de passe, elle ne nécessiterait qu'un fichier pem et c'est ainsi que vous vous connectez
ssh -i my-pem-file.pem ec2-user@my-instance-address
et n'oubliez pas de chmod 400 votre fichier pem avant ssh'ing
Si vous devez faire les choses en tant que root une fois que vous êtes en tant qu'utilisateur ec2, utilisez Sudo su - qui vous permet de rooter et n'a pas besoin de mot de passe. Quelque chose dont vous avez besoin, comme regarder les fichiers journaux de Tomcat
J'ai eu le même problème et après beaucoup de lutte, j'ai relu cette page:
http://docs.aws.Amazon.com/AWSEC2/latest/UserGuide/AccessingInstancesLinux.html
Remarquez dans le 4ème sujet qu'il parle du nom d'utilisateur. C'est généralement ec2-user mais si vous utilisez la distribution RHEL5, cela peut être root et si vous utilisez Ubuntu le nom d'utilisateur sera ubuntu - ce qui était mon cas.
Essayez donc alternativement ceux-ci:
ssh -i my-pem-file.pem ubuntu@my-ec2-instance-address pour Ubuntu
ou
ssh -i my-pem-file.pem root@my-ec2-instance-address pour RHEL5
J'espère que ça aide!
Si vous avez déplacé/copié le fichier pem depuis une autre machine, le propriétaire du fichier peut être différent de l'utilisateur qui exécute le client ssh. Pour changer le propriétaire du fichier:
Sudo chown <currentusername> <filename.pem>
Un mot de passe vous sera demandé lorsque vous activez PasswordAuthentication yes dans votre sshd_config. Essayez de changer cela en non. cela devrait le réparer.
Juste pour quelqu'un d'autre qui pourrait avoir le même problème
Fais juste
Sudo su -
Travaillé pour moi
Veuillez utiliser --query 'KeyMaterial' lors de la génération de la clé.
Info:
keyMaterial - une clé privée RSA codée PEM non chiffrée.
Dans mon cas, nous avions copié un fichier texte pour conserver une clé omniprésente. Quelqu'un a accidentellement ajouté des caractères à ce fichier et nous avons commencé à recevoir un mot de passe à partir du fichier .pem maintenant corrompu, alors que nous n'avions jamais défini de mot de passe.
C'est le moyen de se connecter:
ssh -i /path/my-key-pair.pem ec2-user@public-ip
Maintenant, au lieu de ec2-user, il peut s'agir de root, ou centos, ou ubuntu, ou autre chose. Vous pouvez vérifier sous les "Instructions d'utilisation". Si ce n'est pas le cas et que vous avez essayé tous les utilisateurs ci-dessus, consultez la documentation fournie avec l'AMI.
Il y a un bogue sur AWS qui m'a coûté beaucoup de temps. Si vous lancez une instance à partir d'une AMI enregistrée sous "Images> AMI", notez qu'elle utilise les clés d'origine de l'instance en cours d'exécution à partir de laquelle elle a été créée. Lors du lancement de l'AMI, il vous demandera de choisir une nouvelle clé, et même d'afficher une telle clé sous la description, mais la vérité est que ces clés ne fonctionneront jamais!
Donc, si vous utilisez une AMI personnalisée/enregistrée, vous devrez soit obtenir les clés d'origine et les utiliser, soit simplement en créer une toute nouvelle à partir d'AWS ou du marché. Si vous n'avez pas créé l'AMI ou ne vous souvenez pas d'où elle vient, regardez sous l'onglet détails. Vous pouvez ensuite lancer une nouvelle instance ou créer une nouvelle AMI à partir de la même source. Cela utilisera ensuite les clés que vous spécifiez.
chmod 400 pem_file
ssh -i /path_to_the_pem_file ec2-user@ServerIP
ou
ssh -i /path_to_the_pem_file ubuntu@ServerIP
l'accès root est interdit par défaut par les AMI AWS.
j'espère que ça aide.
Vous devez utiliser le * .pem au lieu d'un mot de passe root. Une fois connecté, utilisez passwd pour définir un mot de passe.
J'utilise l'instance TurboLinux, sur le système Mac OS, veuillez essayer cette commande: ssh -i xxxxx.pem [email protected] (adresse publique de la machine virtuelle allouée) Je peux passer sans demander de mot de passe.
Dans mon cas, le problème était le type de rupture du fichier. Essaye ça:
1.- Ouvrez le fichier .pem avec TextWrangler
2.- En bas de l'application, vérifiez si le type de rupture est "Windows (CRLF)".
Cordialement
Ce pourrait être un problème Linux . Mais il y a aussi une chance que vous utilisiez la mauvaise adresse/clé (vous avez démarré une nouvelle instance mais toujours en utilisant l'ancienne adresse; ou 2 pem ont un nom similaire, utilisé la mauvaise), "ssh avec inexistant utilisateur " .
Pour moi, le problème était que j'avais créé une AMI à partir d'une instance existante, donc quand j'ai lancé l'AMI, même si j'ai sélectionné une nouvelle clé, la clé d'origine de l'instance a fonctionné.
Au cas où quelqu'un d'autre se heurterait à cela, la solution à mon problème était que je devais l'exécuter avec Sudo:
Sudo ssh -i my-pem-file.pem root@my-ec2-instance-address