J'ai créé une instance micro ec2. Installé tous les logiciels Web nécessaires, mysql et git. Création d'une AMI à partir de cette instance. Étant donné que cette instance utilisait EBS comme périphérique racine, elle a également pris un instantané EBS lors de la création de mon AMI.
J'ai terminé cette instance en cours d'exécution. J'ai ensuite essayé de créer une instance en tant qu'AMI (Amazon Machine Image), la nouvelle instance a démarré avec un nouveau volume EBS attaché à l'instance.
Maintenant, lorsque j'utilise ma paire de clés pour me connecter à cette instance via ma clé ssh à son adresse DNS publique avec une commande en tant que
ssh -i aws/mykey.pem ubuntu@thepublicdnsname
ça dit
ssh: connect to Host <thepublickdnsname> port 22: Connection refused
Pourquoi cela arrive-t-il. J'ai pu me connecter à ma première instance avec les mêmes clés via ssh. Maintenant, la nouvelle instance est la copie exacte et je ne parviens pas à me connecter. Toute aide sur ce ...? Est-ce que je manque quelque chose?
J'ai utilisé les mêmes paires de clés pour créer la deuxième nouvelle instance à partir de l'AMI.
J'ai constaté qu'il faut un temps variable pour qu'une instance EC2 apparaisse et s'initialise. L'un est le temps entre l'appel ec2-run-instances jusqu'à ce que l'état de l'instance passe de "en attente" à "en cours d'exécution". Après cela, il reste un délai supplémentaire lorsque le serveur ssh est prêt. Ce temps peut être quelques minutes.
J'avais le même problème: mon problème était qu'un volume était lié à mon instance, puis je l'avais détaché et supprimé. J'ai suivi aws docs pour monter mon instance et édité/etc/fstab. C'était le problème: lorsque le volume est détaché et que vous essayez de redémarrer (ou d'arrêter et de démarrer) l'instance, il va dans ce fichier et tente de joindre le volume inexistant et le démon ssh n'est pas démarré.
La solution est: je devais créer une autre instance, dissocier le volume de l'instance problématique, puis éditer le fichier pointe_montée/etc/fstab pour commenter la ligne où il essayait de monter l'instance inexistante, le réattachement du volume à l'instance problématique et alors tout a bien fonctionné.
Ce n’est probablement pas la réponse à la question initiale, mais comme il s’agit du point le plus préoccupant de Google pour les problèmes de connexion à EC2, veillez à configurer votre groupe de sécurité pour autoriser SSH2 à partir de votre ordinateur, comme indiqué dans
AWS met du temps à faire apparaître une instance à partir d'AMI. Si vous essayez de vous connecter trop rapidement et trop souvent, la boîte de dialogue ne peut pas répondre. Le script complet ci-dessous lance une AMI, détermine l'adresse IP et attend que le système soit prêt à se connecter. Cela fonctionnerait très bien pour des instances ponctuelles proches ou inférieures au prix actuel, car le temps requis pour se connecter peut varier considérablement.
La boucle suivante a provoqué une erreur de connexion refusée, lorsque l'instruction sleep a été mise en commentaire, et a démarré trop rapidement après le démarrage de l'instance. Il a également consommé beaucoup de ressources processeur sur le serveur de script et créé d’énormes journaux d’erreurs.
`nc -z $ip_address -w 20 22` 1>/dev/null 2>&1; result=$?;
while [ $result -eq 1 ]
do
#echo $ip_address booting
`nc -z $ip_address -w 30 22` 1>/dev/null 2>&1; result=$?;
sleep 30
done
Voici un script complet pour démarrer une instance, la baliser, attendre qu'elle démarre complètement et se connecter.
instance_id=$(aws ec2 run-instances --region us-east-1 --count 1 --instance-type $AMItype --image-id $AMI --security-group-ids $sg_group --output text --query 'Instances[*].InstanceId' )
aws ec2 create-tags --resources $instance_id --tags "Key=Name, Value=$AMIname
#delay until AWS says instance is running
start_state=0
while [ $start_state -ne 16 ]
do
start_state=$(aws ec2 start-instances --instance-ids $instance_id --query 'StartingInstances[*].PreviousState[*].Code[*]' )
start_state=$(echo $start_state | tr -d '" []')
sleep 10
done
ip_address=$(aws ec2 describe-instances --instance-ids $instance_id --output text --query 'Reservations[*].Instances[*].PrivateIpAddress')
`nc -z $ip_address -w 20 22` 1>/dev/null 2>&1; result=$?;
while [ $result -eq 1 ]
do
#waiting for routing updates and connectivity
`nc -z $ip_address -w 30 22` 1>/dev/null 2>&1; result=$?;
sleep 30
done
Une autre cause potentielle d'erreur de connexion refusée du port 22 est une mauvaise orthographe du nom public DNS. Par exemple, une partie de la mine contenait .compute.
et je mettais .computer.
et cela me donnait une erreur de port 22 au lieu de quelque chose de plus sensé, comme l'hôte n'existe pas.
Avez-vous vérifié l'adresse IP de l'instance? Le mien change à chaque fois que je l'exécute, à moins que je ne choisisse une adresse IP fixe.
J'ai rencontré un problème similaire, j'ai remarqué que l'instance avait été créée avec la virtualisation de paravirtual et, après avoir répété avec hvm, le problème était résolu.
J'ai eu un problème différent (et honnêtement très stupide). Afficher cette réponse ici au cas où cela aiderait quelqu'un d'autre.
Dans le cadre de mon débogage, j'ai lancé deux nouvelles instances et aucune d'entre elles ne pouvait se connecter. Je viens de redémarrer ma machine!
Ça fonctionne maintenant! :RÉ