Что вызывает проблемы с SSH после перезагрузки сервера 14.04?
Почему перезагрузка сервера под управлением Ubuntu 14.04 выдает ошибки «Отказано в соединении»?
Я вижу ssh: connect to host <IP-address-here> port 22: Connection refused, но только для 14.04 и только после перезагрузки. Я использую 12.04 Desktop дома. Как мне устранить эту проблему?
Чтобы прояснить вопрос, вот что у меня работает или не работает:
- SSH в новой установке 12.04> logout> SSH снова> работает
- SSH в новой установке 12.04> перезагрузка> SSH снова> работает
- SSH в новой установке 14.04> выход> SSH снова> работает
- SSH в новой установке 14.04> перезагрузка> SSH снова> Соединение отклонено
Проблема, с которой я столкнулся, уникальна для 14.04 и возникает только после перезагрузки. До этого у меня было несколько серверов, работающих под 12.04, и все по-прежнему работает отлично. У меня новый сервер, на котором я хочу использовать 14.04, и я хочу понять, что происходит не так. Есть предложения?
Вот что я пробовал до сих пор:
sudo traceroute -p 22 -T <IP-address-here>
Traceroute работает нормально, я получаю ответ от сервера через SSH-порт 22.
initctl list
...
ssh start/running, process 23371
...
Похоже, что ssh на сервере 14.04 настроен на запуск при загрузке (как и ожидалось).
tom@Desktop:~$ ssh -vvv root@<IP-address-here>
OpenSSH_5.9p1 Debian-5ubuntu1.4, OpenSSL 1.0.1 14 Mar 2012
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to <IP-address-here> [<IP-address-here>] port 22.
debug1: connect to address <IP-address-here> port 22: Connection refused
ssh: connect to host <IP-address-here> port 22: Connection refused
Редактировать: Вот весь системный журнал с только что созданного компьютера . Я создал его, выполнил команду SSH и выполнил команду reboot now, а затем получил сообщение об отказе в соединении после ожидания перезагрузки и повторной попытки SSH. Жесткая перезагрузка через панель управления хостингом, и теперь SSH-соединение снова работает.
4 ответа
Быстрый ответ:
SSH не является проблемой. Команда, которую Вы используете для перезагрузки, является проблемой: не делать reboot now, сделать reboot или shutdown -r now перезагружать Вашу систему.
Синтаксис команды (начиная с 13.04) был:
reboot [OPTION]... [REBOOTCOMMAND]
REBOOTCOMMAND никогда не существовал прежде. В 12,04, Ваш now был просто проигнорирован, но теперь это используется... И это повреждает все.
Длинный ответ, с моими тестовыми результатами и объяснением:
У меня есть подобная проблема с некоторыми серверами, работающими 14.04 И в VPS (размещенный во французском поставщике OVH - рабочий OpenVZ) И при выполнении reboot now в самом сервере.
Как Вы я дал команду reboot now от консоли (вошел в систему с помощью SSH). Некоторые вторые после того, как я нажал RETURN, моя сессия, автоматически разъединяются. Как Вы я никогда не мог снова соединиться с сервером через SSH после выдачи этой команды.
Так, я решил открыть консоль KVM, обеспеченную OVH. (эмуляция прямого доступа с помощью клавиатуры и экрана на физическом сервере для этого вида виртуального сервера).
Я смог соединиться со своей машиной, и я видел, что она вводила в Однопользовательский режим, ожидая меня для нажатия CTRL+D, чтобы продолжить или ввести пароль root для входа в режим техобслуживания. Я нажал, сочетание клавиш для движения позволило процессу продолжиться, и затем смог к SSH в мою систему снова. Что мой surpise должен был видеть после выполнения uptime, то, что время работы не составляло 2 или 3 минуты но много дня: reboot now выполняемый в VPS Ubuntu 14.04 действительно не перезагружает, но просто просит входить в Однопользовательский режим!
От этого я учился никогда не спрашивать перезагрузку из своего VPS, но запрашивать это от команды, обеспеченной на интерфейсе управления hoster.
Таким образом нет никакой проблемы с Вашей установкой SSH. Проблема состоит в том, когда Вы вводите reboot now. На самом деле я протестировал его позже также, если Вы ввели reboot (просто слово, никакая опция), это сделало бы то, что Вы намеревались сделать: перезагрузите сервер.
Используя reboot с аргументом (из страницы справочника) называют команду shutdown с данными аргументами. И действительно, если я выполняюсь shutdown now, У меня есть то же поведение: система не перезагружается, она входит в однопользовательский режим.
Комментарий: похоже, что это - намеченное поведение, поскольку в сообщении, появляющемся на экране после удара выполнения этой команды, говорится что-то как:
Система будет принесена к режиму техобслуживания
Режим техобслуживания или однопользовательский режим, это представляет то же, runlevel с замечанием больше, чем оболочка, никакая сеть, никакие сетевые процессы...
Это может сбивать с толку, но отметить что корректное использование shutdown например: shutdown -h now остановить систему теперь или shutdown -r now перезагружать его теперь. Я не знал это shutdown now только принес бы систему в однопользовательский режим. Я обычно делаю init S достигнуть этого.
Для моей системы проблема состояла в том, что ssh init сценарий /etc/init.d/ssh был единственной проверкой присутствие новомодной версии init.
Так /etc/init.d/ssh не запускается ssh,, потому что это полагает, что будет запущено upstart.
В моем случае, выскочка не запускает из-за моей конкретной конфигурации:
была корректная конфигурация в /etc/init/ssh.conf, но также был /etc/init/ssh.override файл, содержащий manual, что означает ssh, как, ожидают, будет запущен вручную.
Этот файл был создан get-remnux.sh сценарий установки.
Запуск вручную или удаление /etc/init/ssh.override файл решает проблему.
Другая потенциальная причина ufw потеря конфигурации правила порта SSH. Это произошло со мной по крайней мере в одном или двух случаях, где после применения обновлений и перезагрузки, конфигурация брандмауэра блокировала меня получающий доступ к серверу. Используя VPS моего поставщика услуг хостинга средство консоли позволило мне добираться на машину и диагностировать проблему. Пример ниже показа проблемы (т.е. никакая запись для порта 22):
user@host:~$ sudo ufw status verbose
[sudo] password for user:
Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
80,443/tcp (Nginx Full) ALLOW IN Anywhere
25/tcp ALLOW IN Anywhere
143 ALLOW IN Anywhere
110 ALLOW IN Anywhere
993/tcp (Dovecot Secure IMAP) ALLOW IN Anywhere
995/tcp (Dovecot Secure POP3) ALLOW IN Anywhere
25/tcp (Postfix) ALLOW IN Anywhere
465/tcp (Postfix SMTPS) ALLOW IN Anywhere
80,443/tcp (Nginx Full (v6)) ALLOW IN Anywhere (v6)
25/tcp (v6) ALLOW IN Anywhere (v6)
143 (v6) ALLOW IN Anywhere (v6)
110 (v6) ALLOW IN Anywhere (v6)
993/tcp (Dovecot Secure IMAP (v6)) ALLOW IN Anywhere (v6)
995/tcp (Dovecot Secure POP3 (v6)) ALLOW IN Anywhere (v6)
25/tcp (Postfix (v6)) ALLOW IN Anywhere (v6)
465/tcp (Postfix SMTPS (v6)) ALLOW IN Anywhere (v6)
Перевключение порта следующим образом добивается цели:
user@host:~$ sudo ufw allow ssh
Rule added
Rule added (v6)
Я могу опоздать, и может быть очевидно, но что работало на меня, должен был проверить конфигурационный файл /etc/ssh/sshd_config: выполнение демона с /etc/init.d/ssh start или любая другая комбинация показало, что услуга работала даже при том, что это не было, но если я запускаю исполняемый файл с его полным путем (в моем случае /usr/sbin/sshd), я видел, что был "0B", добавленный в конце конфигурационного файла, который вызвал ошибку, когда запуск, удаление его решили проблему.