web-dev-qa-db-fra.com

L'exécution de l'instance EC2 refuse soudainement la connexion SSH

J'ai mis en place l'instance EC2 il y a quelques jours et même hier soir, j'ai pu y accéder sans aucun problème. Aujourd'hui matin, je ne peux pas y aller. Le port 22 est déjà ouvert dans le groupe de sécurité et je n’ai rien changé depuis hier soir.

Erreur:

ssh: connect to Host [ip address] port 22: Connection refused

J'avais un problème similaire récemment et je ne pouvais pas comprendre pourquoi cela se produisait. J'ai donc dû créer une nouvelle instance, la configurer à nouveau, puis connecter et configurer tous les stockages EBS au nouveau. Ça m'a pris deux heures ... et maintenant ça se reproduit. Dans la version précédente, j’ai installé denyhost, ce qui m’a peut-être bloqué, mais dans la version actuelle, seuls Apache2 et mysql sont en cours d’exécution.

L'instance actuelle est active depuis 16 heures maintenant, donc je ne pense pas que c'est parce qu'elle n'a pas fini de démarrer ... De plus, le port 22 est ouvert à toutes les sources (0.0.0.0/0) et utilise le protocole TCP. 

Des idées?

Merci.

apachesshamazon-web-servicesamazon-ec2connection
19
Sherzod

Avec l’aide de @ abhi.gupta200297, nous avons pu résoudre le problème.

Le problème était l'erreur dans /etc/fstab, et sshd était censé être démarré après que fstab eut réussi. Mais ce n'était pas le cas, par conséquent, sshd ne voulait pas démarrer et c'est pourquoi il refusait la connexion. La solution consistait à créer une instance temporaire, à monter l'EBS racine à partir de l'instance d'origine et à commenter des éléments de la variable fstab et le tour est joué, cela me permettait de me reconnecter. Et pour l’avenir, j’ai juste cessé d’utiliser fstab et créé un ensemble de commandes Shell pour monter les volumes EBS dans des répertoires. Je les ai ajoutés au fichier /etc/init.d/ebs-init-mount, puis j’ai exécuté update-rc.d ebs-init-mount defaults pour l’initialiser. Je n’ai plus de problèmes avec ssh verrouillé.

UPDATE 4/23/2015

L'équipe Amazon a créé un didacticiel vidéo sur un problème similaire et montre comment déboguer à l'aide de cette méthode: https://www.youtube.com/watch?v=_P29ZHu_feU

25
Sherzod

On dirait que sshd pourrait s'être arrêté pour une raison quelconque. L'instance EBS est-elle soutenue? Si c'est le cas, essayez de l'éteindre et de le redémarrer. Cela devrait résoudre le problème.

De plus, pouvez-vous utiliser SSH depuis la console Web AWS? Ils ont un plugin Java pour ssh dans l'instance.

6
abhi.gupta200297

Pour ceux d'entre vous qui sont tombés sur ce message parce que vous ne parvenez pas à SSH dans votre instance EC2 après un redémarrage, ceci est partagé à une question similaire à serverfault :

De message publié sur le forum des développeurs AWS sur ce sujet : 

Essayez d’arrêter l’instance endommagée, de détacher le volume EBS et de L’attacher en tant que volume secondaire à une autre instance. Une fois que vous avez monté le volume endommagé quelque part sur l'autre instance, vérifiez le fichier /Etc/sshd_config (en bas). J'ai eu quelques instances RHEL Où Yum a scrogué sshd_config en insérant des lignes dupliquées au bas de Qui ont entraîné l'échec de sshd au démarrage en raison d'erreurs de syntaxe.

Une fois que vous avez résolu le problème, il suffit de démonter le volume, de le détacher, de le rattacher à Et de le réactiver.

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 accédant à la console de gestion EC2, en cliquant sur "Elastic Block Store"> "Volumes", en cliquant avec le bouton droit de la souris sur le volume associé à l'instance que vous avez sélectionnée. arrêté.
  2. Démarrez une nouvelle instance dans la même région et sous le même système d'exploitation que l'instance rompue then attachez le volume racine EBS d'origine en tant que 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. recherchez dans le fichier "/ etc/sshd_config" les entrées en double en exécutant les commandes suivantes:
    • cd /etc/ssh
    • Sudo nano sshd_config
    • ctrl-v un tas de fois pour aller au bas du fichier
    • ctrl-k toutes les lignes du bas mentionnant "PermitRootLogin sans mot de passe" et "UseDNS no"
    • ctrl-x et Y pour enregistrer et quitter le fichier modifié
  5. _ { @Telegard } _ fait remarquer (dans son commentaire) } que nous n'avons corrigé que le symptôme. Nous pouvons corriger le cause en commentant les 3 lignes associées dans le fichier "/etc/rc.local". Alors:
    • 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 avez corrigé, il vous suffit de démonter le volume }, 
  7. détachez-vous en accédant à la console de gestion EC2, en cliquant sur "Elastic Block Store"> "Volumes", en cliquant avec le bouton droit de la souris sur le volume associé à l'instance arrêtée, 
  8. se rattache à votre autre instance et 
  9. _ { le rallume } _.
5
Jeromy French

Cela m'est arrivé sur une instance Red Hat EC2 parce que ces deux lignes étaient automatiquement ajoutées à la fin du fichier/etc/ssh/sshd_config chaque fois que j'ai lancé mon instance:

PermitRootLogin sans mot de passe
UseDNS no

Une de ces opérations d’ajout a été effectuée sans saut de ligne, la queue du fichier sshd_config ressemblait à ceci:

PermitRootLogin sans mot de passe
UseDNS noPermitRootLogin sans mot de passe
UseDNS no

Cela a empêché sshd de démarrer au prochain lancement. Je pense que cela a été causé par le bogue signalé ici: https://bugzilla.redhat.com/show_bug.cgi?id=956531 La solution consistait à supprimer toutes les entrées en double au bas du fichier sshd_config, et ajoutez des sauts de ligne supplémentaires à la fin.

4
ianmcook

Accédez à votre console de gestion AWS> sélectionnez une instance> cliquez avec le bouton droit de la souris et sélectionnez "Obtenir les journaux du système" . Ceci répertoriera les erreurs. 

1
Stewie

J'ai eu un fichier SSH similaire verrouillé en détachant un EBS mais j'ai oublié de modifier le fichier/etc/fstab

0
wdanxna