Назад | Перейти на главную страницу

Экземпляры EC2 становятся недоступными через SSH, в чем может быть проблема? Могу ли я использовать эластичный балансировщик нагрузки для проверки подключения по SSH?

Это в основном проблема для моего сервера разработки ec2, так как кажется, что мой экземпляр продолжает становиться недоступным через SSH. Это случилось вчера, поэтому я убил этого и начал новый, и это повторилось позже сегодня. Сервер по-прежнему работает, мое веб-приложение доступно в веб-браузере, но всякий раз, когда я пытаюсь подключиться через SSH, я получаю permission denied (private key) сообщение об ошибке в моем терминале. Я на 100% уверен, что не делаю ничего плохого, так как могу создать новый экземпляр того же самого AMI (это персональный пользовательский AMI), ничего не менять, в том числе используя тот же .pem key, а затем я могу подключиться к этому новому экземпляру по SSH, используя ту же команду, что и раньше (просто изменив IP-адрес).

Я понимаю, что с ec2 могут возникать проблемы, но то, что это происходит каждый день, кажется немного странным. Я использую m2.xlarge Например, я не знаю, имеют ли они тенденцию быть нестабильными, в прошлом я использовал небольшой экземпляр, и он месяцами работал без проблем, поэтому я нахожу это таким странным.

Я изучаю использование балансировки нагрузки, но кажется, что единственные предлагаемые ими проверки «работоспособности» - это протоколы http или tcp, поэтому я не уверен, смогу ли я сделать так, чтобы они отслеживали подключение по SSH. Это важно для разработки, так как я могу делать 1-2 новых нажатия приложения в день и использовать для этого SSH. У меня есть дизайнер, которому необходимо, чтобы приложение всегда было доступно, поскольку он работает с интерфейсными файлами для тестирования вывода с живым приложением. В любом случае, любой совет / информация приветствуются

Я стараюсь прикреплять и сохранять один и тот же общедоступный эластичный IP-адрес в экземплярах, поэтому отсутствие стабильного IP-адреса, в зависимости от настроек вашего клиента, может быть в определенной степени связано с проблемой.

В зависимости от используемого вами дистрибутива вы можете заглянуть в /var/log/auth.log или / var / log / syslog, чтобы получить дополнительную отладочную информацию о том, что происходит ...

Используете ли вы для входа в систему терминал Unix или какое-либо другое терминальное приложение?