Я создал экземпляр micro ec2. Установлено все необходимое программное обеспечение для сети, mysql и git. Создал AMI из этого экземпляра. Поскольку этот экземпляр использовал EBS в качестве своего корневого устройства, он также получил снимок EBS, когда я создавал AMI.
Я закончил этот исполняемый экземпляр. Затем я попытался создать экземпляр из образа машины Amazon (AMI), новый экземпляр начался вместе с добавлением нового экземпляра EBS к экземпляру.
Теперь, когда я использую свою пару ключей для входа в этот экземпляр с помощью моего ключа ssh на свой общедоступный DNS-адрес с помощью команды
ssh -i aws/mykey.pem [email protected]
говорится
ssh: connect to host <thepublickdnsname> port 22: Connection refused
Почему это происходит. Я смог подключиться к первому экземпляру с теми же ключами через ssh. Теперь новый экземпляр является точной копией, и я не могу войти в нее. Любая помощь в этом...? Я что-то пропустил?
Я использовал те же пары ключей, чтобы создать второй новый экземпляр из AMI.
Я обнаружил, что для экземпляра EC2 требуется переменное количество времени и инициализация. Один из них - время между вызовом экземпляров ec2-run-экземпляров до изменения состояния экземпляра от "ожидающего" до "запуска". После этого появляется дополнительное время, когда сервер ssh становится готовым. Это может быть пару минут.
Возможно, это не ответ на исходный вопрос, но поскольку это находится на вершине Google для проблем подключения к EC2, обязательно настройте свою группу безопасности, чтобы разрешить SSH2 с вашего компьютера:
У меня была одна и та же проблема: моя проблема заключалась в том, что у меня был том, прикрепленный к моему экземпляру, затем я отключил том и удалил его. Я следил за aws docs, чтобы смонтировать мой экземпляр и отредактировать /etc/fstab. Это была проблема: когда громкость отсоединена и вы пытаетесь перезагрузить (или остановить и запустить) экземпляр, он переходит к этому файлу и пытается подключить несуществующий том, а демон ssh не запускается.
Решение: мне пришлось создать еще один экземпляр, отсоединить том от проблемного экземпляра, а затем отредактировать файл mount_point/etc/fstab, чтобы прокомментировать строку, где он пытается установить несуществующий экземпляр, перезагрузите том в проблемный экземпляр, а затем все получилось отлично.
Еще одна потенциальная причина отказа в соединении с отказом 22-го канала - это неправильное обращение к публичному имени DNS. Например, моя часть содержала .compute., и я положил .computer., и он дал мне ошибку порта 22 вместо чего-то более разумного, как хост не существует.
AWS требует времени, чтобы вызвать экземпляр из AMI. Если вы пытаетесь подключиться слишком быстро и слишком часто, ящик не может ответить. Полный script ниже запускает AMI, определяет IP-адрес и ждет, пока система не будет готова к подключению. Он будет работать очень хорошо для случайных экземпляров, близких к или ниже текущих цен, так как время, необходимое для подключения, может сильно различаться.
Следующий цикл вызвал ошибку отказа соединения, когда оператор sleep был прокомментирован, и он начал слишком быстро после запуска экземпляра. Он также потреблял много CPU на сервере script и делал огромные журналы ошибок.
`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
Вот полный script, чтобы запустить экземпляр, пометить его, дождаться его полной загрузки и подключиться.
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
Вы проверяли ip-адрес экземпляра? Шахта меняется каждый раз, когда я запускаю ее, если я не выбрал фиксированный ip.
У меня была другая (и, честно говоря, очень глупая) проблема. Проводя этот ответ здесь, если он помогает кому-то другому.
В рамках моей отладки я запустил пару новых экземпляров, и ни один из них не смог подключиться, поэтому я просто перезагрузил свою машину!
Теперь он работает!: D