web-dev-qa-db-fra.com

Amazon EC2 - Pas de SSH après le redémarrage, connexion refusée

J'ai reproduit cela deux ou trois fois, donc je suppose qu'il y a quelque chose qui ne va pas dans ce que je fais.

Voici mes étapes:

  1. Lancez une nouvelle instance via la console de gestion EC2 en utilisant: Ubuntu Server 13.10 - AMI-ace67f9c (64 bits)
  2. Lancer avec des valeurs par défaut (en utilisant ma paire de clés existante)
  3. L'instance démarre. Je peux le SSH en utilisant PuTTY ou le terminal Mac. Succès!
  4. Je redémarre l'instance

  5. 10 minutes plus tard, lorsque l'instance doit être de nouveau opérationnelle, ma connexion au terminal affiche:

    stead:~ stead$ ssh -v -i Dropbox/SteadCloud3.pem [email protected]
OpenSSH_5.6p1, Op`enSSL 0.9.8y 5 Feb 2013
debug1: Reading configuration data /etc/ssh_config
debug1: Applying options for *
debug1: Connecting to 54.201.200.208 [54.201.200.208] port 22.
debug1: connect to address 54.201.200.208 port 22: Connection refused
ssh: connect to Host 54.201.200.208 port 22: Connection refused
stead:~ stead$

Très bien, je comprends que l'adresse IP publique peut changer, donc en vérifiant la console de gestion EC2, je vérifie que c'est la même chose. Bizarre. Juste pour le plaisir, j'essaie de me connecter avec le nom d'hôte DNS public: ec2-54-201-200-208.us-west-2.compute.amazonaws.com. Pas de dés, même résultat.

Même en utilisant la connexion via Java client SSH intégré à la console EC2, je reçois une connexion refusée.

J'ai vérifié les groupes de sécurité. Cette instance se trouve dans le groupe launch-wizard-4. En regardant la configuration entrante pour ce groupe, le port 22 est autorisé à partir de 0.0.0.0/0, ce qui devrait être n'importe où. Je sais que je frappe mon instance et c'est le bon groupe de sécurité, car je ne peux pas cingler l'instance. Si j'active ICMP pour ce groupe de sécurité, tout à coup mes pings passent.

J'ai trouvé quelques autres messages sur Internet avec des messages d'erreur similaires, mais la plupart semblent être facilement résolus en ajustant les paramètres du pare-feu. J'en ai essayé quelques-uns, sans succès.

Je suppose qu'il me manque une étape EC2 simple. Merci pour toute aide que vous pouvez apporter et je suis heureux de vous fournir plus d'informations ou de tester plus avant!

Mise à jour - Voici mes journaux système de la console Amazon EC2: http://Pastebin.com/4M5pwGRt

sshamazon-ec2cloud
18
SteadH

J'ai eu un comportement similaire aujourd'hui sur mon instance ec2, et j'ai trouvé la chose à ceci: quand je fais Sudo reboot now la machine se bloque et je dois la redémarrer manuellement depuis la console de gestion aws quand je le fais Sudo reboot il redémarre très bien. Apparemment, "maintenant" n'est pas une option valide pour le redémarrage comme indiqué ici https://askubuntu.com/questions/397502/reboot-a-server-from-command-line

pensées?

7
oromoiluig

De le post du Forum des développeurs AWS sur ce sujet :

Essayez d'arrêter l'instance rompue, de détacher le volume EBS et de le joindre en tant que volume secondaire à une autre instance. Une fois que vous avez monté le volume cassé quelque part sur l'autre instance, vérifiez le fichier/etc/sshd_config (près du bas). J'ai eu quelques instances RHEL où Yum scrogged le sshd_config en insérant des lignes en double en bas qui a causé l'échec de sshd au démarrage à cause d'erreurs de syntaxe.

Une fois que vous l'avez corrigé, démontez simplement le volume, détachez-le, reconnectez-le à votre autre instance et redémarrez-le.

Décomposons cela, avec des liens vers la documentation AWS:

  1. Arrêtez l'instance cassée et détachez le volume EBS (racine) en allant dans la console de gestion EC2, en cliquant sur "Elastic Block Store"> "Volumes", le clic droit sur le volume associé à l'instance vous avez arrêté.
  2. Démarrez une nouvelle instance dans la même région et du même système d'exploitation que l'instance cassée puis attachez le volume racine EBS d'origine comme volume secondaire à votre nouvelle instance . Les commandes de l'étape 4 ci-dessous supposent que vous montez le volume dans un dossier appelé "données".
  3. Une fois que vous avez monté le volume cassé quelque part sur l'autre instance ,
  4. vérifiez le fichier "/ etc/sshd_config" pour les entrées en double en émettant ces commandes:
    • cd /etc/ssh
    • Sudo nano sshd_config
    • ctrl-v un tas de fois pour aller au bas du fichier
    • ctrl-k toutes les lignes en bas mentionnant "PermitRootLogin without-password" et "UseDNS no"
    • ctrl-x et Y pour enregistrer et quitter le fichier modifié
  5. @ Telegardsouligne (dans son commentaire) que nous avons seulement corrigé le symptôme. Nous pouvons corriger la cause en commentant les 3 lignes liées dans le fichier "/etc/rc.local". Donc:
    • cd /etc
    • Sudo nano rc.local
    • recherchez les lignes "PermitRootLogin ..." et supprimez-les
    • ctrl-x et Y pour enregistrer et quitter le fichier modifié
  6. Une fois que vous l'avez corrigé, juste démontez le volume ,
  7. détacher en allant dans la console de gestion EC2, en cliquant sur "Elastic Block Store"> "Volumes", le clic droit sur le volume associé à l'instance que vous avez arrêtée,
  8. rattachez à votre autre instance et
  9. tirez à nouvea .
19
Jeromy French

Cela n'aidera peut-être pas la situation, mais j'ai vu certains cas où un redémarrage sur EC2 est "bloqué". Si vous effectuez une "réinitialisation" sur le VM puis récupérez les journaux système, cela peut changer le comportement. Assurez-vous que les journaux proviennent du deuxième démarrage et non du premier - ils ont tendance être retardé sur les mises à jour.

Une autre chose à vérifier est de s'assurer que l'instance répond sur l'IP. Vous semblez obtenir une connexion refusée ci-dessus, ce qui semble être une instance, mais SSH ne fonctionne pas ou est protégé par un pare-feu, mais assurez-vous que l'instance a complètement redémarré.

Vous pouvez également essayer d'ouvrir tous les ports à partir d'un système de test et voir ce que "nmap" vous montre - d'autres services répondent-ils sur l'instance?.

0
Nathan Neulinger