Що викликає проблеми з SSH після перезавантаження сервера 14.04?

Чому перезавантаження сервера під управлінням Ubuntu 14.04 викликає помилки "Відключення підключення"?

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

Щоб зробити питання зрозумілішим, ось що для мене робить чи не працює:

• 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

Редагувати: Ось цілий syslog із щойно створеної машини . Я створив його, SSH'd в & видав reboot nowкоманду, потім отримав помилку підключення після очікування перезавантаження та спроби SSH вдруге. Важке перезавантаження через панель керування хостингом, і тепер з'єднання SSH знову працює.

Швидка відповідь:

SSH - це не проблема. Команда, яку ви використовуєте для перезавантаження, - це проблема: не робіть reboot now, не робіть rebootі shutdown -r nowне перезавантажуйте систему.

Синтаксис команд ( з 13.04 ):

reboot [OPTION]...  [REBOOTCOMMAND]

REBOOTCOMMANDНіколи не існувало. У 12.04 ваш nowігнорували, але зараз він використовується ... І це все порушує.

Довга відповідь з результатами моїх тестів та поясненнями:

У мене є аналогічна проблема з деякими серверами, що працюють 14.04 AND у VPS (розміщений у французького постачальника OVH - працює OpenVZ) ТА під час роботи reboot nowвсередині самого сервера.

Як ви, я видав команду reboot nowз консолі (увійшов у систему за допомогою SSH). Через кілька секунд після натискання RETURNсеанс автоматично відключається. Як і ви, я ніколи не зміг підключитися до сервера через SSH після видачі цієї команди.

Отже, я вирішив відкрити консоль KVM, надану OVH. (емуляція прямого доступу за допомогою клавіатури та екрана на фізичному сервері для цього типу віртуального сервера).

Мені вдалося підключитися до своєї машини, і я побачив, що вона переходить у єдиний користувальницький режим, чекаючи, коли я натисну CTRL+, Dщоб продовжити або ввести корінний пароль, щоб перейти в режим обслуговування. Я натиснув комбінацію клавіш, щоб продовжити процес, а потім знову зміг SSH в мою систему. Який мій сюрприз побачив після запуску uptime, що тривалість роботи не була 2 або 3 хвилини, але все-таки багато дня: reboot nowвиконана всередині Ubuntu 14.04 VPS насправді не перезавантажується, а просто просить перейти в режим єдиного користувача!

З цього я навчився ніколи не просити перезавантаження з мого VPS, а вимагати його з команди, наданої в інтерфейсі управління хостеру.

Таким чином, немає жодної проблеми з установкою SSH. Проблема полягає у введенні reboot now. Насправді я тестував це згодом також, якби ви ввели reboot(просто слово, жоден варіант), це зробило б те, що ви мали намір зробити: перезавантажте сервер.

За rebootдопомогою аргументу (зі сторінки man) викликайте команду shutdownіз заданими аргументами. І справді, якщо я виконую shutdown now, я маю таку ж поведінку: система не перезавантажується, вона переходить в режим єдиного користувача.

Зауваження: схоже, це призначена поведінка, оскільки повідомлення, яке з’являється на екрані після натискання на виконання цієї команди, говорить щось на зразок:

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

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

Це може заплутати, але зауважте, що правильне використання shutdown, наприклад shutdown -h now,: зупинити систему зараз або shutdown -r nowперезавантажити її зараз. Я не усвідомлював, що shutdown nowприведе систему лише в єдиний користувальницький режим. Я зазвичай роблю цього init Sдля досягнення.

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

Ще однією можливою причиною є 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)

У моїй системі проблема полягала в тому, що скрипт 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файлу вирішує проблему.