Что вызывает проблемы с SSH после перезагрузки сервера 14.04?

15

Почему перезагрузка сервера под управлением Ubuntu 14.04 выдает ошибки «Отказано в соединении»?

Я вижу, ssh: connect to host <IP-address-here> port 22: Connection refusedно только для 14.04 и только после перезагрузки. Я использую 12.04 Desktop дома. Как мне устранить это?

Чтобы прояснить вопрос, вот что у меня работает или не работает:

  • SSH в новой установке 12.04> выход> 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

Редактировать: Вот весь системный журнал с недавно созданной машины . Я создал его, выполнил reboot nowкоманду SSH и выполнил команду, а затем получил сообщение об отказе в соединении после ожидания его перезагрузки и попытки выполнить SSH во второй раз. Жесткая перезагрузка через панель управления хостингом, и теперь SSH-соединение снова работает.

server 14.04 ssh openssh Том Броссман
источник
У меня похожая проблема, но в совершенно ином контексте. Кажется, что-то изменилось, но я не могу понять, что. Я знаю, что с udev произошли изменения, но я точно не понимаю, как это будет иметь значение, потому что в других случаях, похоже, работает сеть. Просто sshd хлопотно.
Джо-Эрленд Шинстад
1
@ Jo-ErlendSchinstad Сегодня я потратил 2 часа на тестирование этого с серверами AWS, DigitalOcean и OVH и могу воспроизводить его 100% времени. 12.04 = нормально, 14.04 = нет SSH после перезагрузки. Если бы это была ошибка, я ожидаю, что мы услышим от многих других, заблокированных на своих серверах! Надеюсь, я что-то пропустил, но с новой установкой и одним SSH-логином для перезагрузки, здесь не так много места для человеческих ошибок. Только что проверил это сейчас на моем ноутбуке 14.04 (на случай, если это было 12.04) и без изменений, тот же результат. Очень надеюсь это выяснить в ближайшее время ...
Том Броссман
1
О, у меня много серверов, на которых работает sshd без каких-либо проблем. Это проблема, о которой я говорил: askubuntu.com/questions/479448/…
Джо-Эрленд Шинстад

Ответы:

17

Быстрый ответ:

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 для перехода в режим обслуживания. Я нажал комбинацию клавиш, чтобы продолжить, чтобы продолжить процесс, а затем снова смог войти в мою систему. После того, как я запустил uptime, я удивился, увидев, что время безотказной работы составляло не 2 или 3 минуты, а, тем не менее, много дня: reboot nowвыполнение в Ubuntu 14.04 VPS на самом деле не перезагружается, а просто просит перейти в однопользовательский режим!

Исходя из этого, я научился никогда не запрашивать перезагрузку из моего VPS, а запрашивать ее с помощью команды, предоставленной в интерфейсе управления хостера.

Таким образом, нет проблем с вашей установкой SSH. Проблема в том, когда вы печатаете reboot now. Фактически, я также проверил это позже, если бы вы ввели reboot(просто слово, без опции), он бы сделал то, что вы намеревались сделать: перезагрузите сервер.

Использование rebootс аргументом (со страницы руководства) вызывает команду shutdownс заданными аргументами. И действительно, если я выполняю shutdown now, у меня такое же поведение: система не перезагружается, она переходит в однопользовательский режим.

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

Система будет переведена в режим обслуживания

Режим обслуживания или однопользовательский режим, это то же самое, уровень выполнения с отметкой больше, чем оболочка, нет сети, нет сетевых процессов, ...

Это может сбивать с толку, но обратите внимание, что правильное использование shutdown, например, это: shutdown -h nowостановить систему сейчас или shutdown -r nowперезагрузить ее сейчас. Я не знал, что shutdown nowэто переведет систему только в однопользовательский режим. Я обычно делаю init Sдля этого.

Benoit
источник
Спасибо за этот самый интересный ответ! Я собираюсь проверить все это сейчас, так как я на выделенном сервере (не VPS), но у меня была проблема с обоими типами - до 14.04, а не 12.04. sudo reboot nowотлично работает в 12.04 и uptimeсоответствует последнему разу, когда я это делаю. Очень интересное изменение для 14.04, хотя.
Том Броссман
1
возникла та же проблема после обновления сервера до 14.04.1, и перезагрузка не решает ее.
chhantyal
Это исправило это для меня. Пришлось вручную перезагрузить сервер. Вау, это супер раздражает! С какой стати теперь приравнивать к однопользовательскому режиму? Какой тупой выбор. Почему бы не sudo reboot --single-userполучить эту функциональность ???
Jcollum
2

Я могу опоздать, и это может быть очевидно, но для меня сработала проверка файла конфигурации /etc/ssh/sshd_config: запуск демона с помощью /etc/init.d/ssh startили любой другой комбинации показал, что служба запущена, хотя это не так, но если я запускаю исполняемый файл с по его абсолютному пути (в моем случае /usr/sbin/sshd) я увидел, что в конце файла конфигурации был добавлен «0B», что вызвало ошибку при запуске, устранение проблемы решило проблему.

тама
источник
Очень полезно - в моем случае я набрал ошибочный символ в начале файла. Очень загадочно, как не выдается ошибка, если в конфиге есть проблема, и кажется, что все запускается, даже если не запущен процесс.
Андрей Мао
2

Другая потенциальная причина - 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)
Джон Рикс
источник
-1

Для моей системы проблема заключалась в том, что сценарий 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файла решает проблему.

Михал Амброз
источник