Sshd не запускается после перезагрузки

Обновлено: 06.07.2024

в течение последних 6 часов я искал информацию. У меня есть виртуальная машина, которая работает нормально в течение последних шести месяцев. Я был счастлив ssh'ing в это, и это управляло базой данных и некоторыми небольшими приложениями. Сегодня вечером ssh перестал работать, поэтому я решил перезагрузить машину. У меня сейчас следующая ситуация:

Я попытался:- перезагрузить компьютер еще раз (не повезло)- смонтировать файловую систему и проверить /etc/ssh/sshd.conf (не изменился с рабочей ситуации)- установить консоль virsh, однако это не похоже на работу

Когда я монтирую fs напрямую с помощью losttup, странно то, что даты файлов кажутся замороженными в /var /log / во время сбоя. Если я смотрю в /var / run /, я вижу sshd.pid, но время 6 часов назад (и многочисленные перезагрузки).

Мой virsh xml выглядит так:

Я в некотором роде растерялся относительно того, куда я могу обратиться, чтобы снова запустить и запустить машину.

На том же экземпляре KVM у меня работает другой сервер, который работает нормально. Оба Ubuntu 12.04.

Любая помощь приветствуется .

1 ответ 1

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

Ситуация: У меня есть сервер Ubuntu 12.04 LTS (M для мастера), на котором запущены два виртуальных сервера (V1 и V2), оба Ubuntu 12.04 LTS. На хост-машине у меня есть три IP-адреса, поэтому к каждой машине можно получить доступ через собственный публичный IP-адрес. Серверы установлены на основе LVM.

Вчера один из виртуальных серверов прекратил принимать SSH-соединения. Также я не смог подключиться к работающей на нем базе данных. Когда я исследовал, я обнаружил:

Моим первым инстинктом было отключение питания компьютера, возможно, какой-то процесс застрял (у меня на сервере работает какое-то собственное программное обеспечение), поэтому я сделал:

Это привело к тому же статусу:

Ок, так что-то другое дело. В это время я начал немного беспокоиться о том, что мой сервер мог быть взломан, однако я вообще не мог получить к нему доступ. Я был немного менее обеспокоен, когда nmap -sS -v -v не показывал странных открытых портов, но никто не знает.

Теперь мой боевой план изменился на две основные цели:

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

Проблема, однако, заключалась в том, что большинство этих сайтов используют работающий и доступный сервер, чего у меня не было. Поэтому мне сначала нужно было найти способ получить доступ к LVM. Опять же, есть много учебных пособий, однако все они, казалось, работали вплоть до того места, где я хотел смонтировать файловую систему. Он будет постоянно терпеть неудачу с «mount: вы должны указать тип файловой системы». Даже указание файловой системы с -t не решило эту проблему.

Шаги, которые я предпринял, чтобы смонтировать мои логические тома:

перечислите LVM с помощью: lvs

список разделов в LVM: fdisk -l /dev /disk01 /virtual2

Это дало мне стартовые сектора, чтобы иметь возможность монтировать разделы.

Создан каталог монтирования: mkdir / mnt / tempfs

Теперь я могу смонтировать два раздела, используя:

Если ваши стартовые блоки отличаются, вы можете рассчитать offste (опция -o), умножив начальную позицию (63 для первого раздела и 19529728 для третьего) на размер сектора, указанный в выводе fdisk -l.

Теперь я могу смонтировать раздел: mount /dev /loop0 /mnt /tempfs /

Теперь у меня был доступ к моим файлам. Позже я обнаружил, что есть также инструмент под названием guestfish. Вы можете использовать это, чтобы получить доступ к файлам, выполнив: guestfish -d virtual2 -i. Если вы хотите доступ только для чтения, добавьте --ro в конце).

Чтобы вернуть раздел в состояние, в котором я чувствовал себя комфортно, запустив виртуальную машину, которую я выпустил:

Итак, сначала я хотел посмотреть, действительно ли мой сервер был скомпрометирован, поэтому я подключил оба раздела (по одному за раз) и:

К счастью, это не показало странных вещей, поэтому я начал думать, что что-то идет не так во время загрузки. Странно было то, что ни один из файлов журнала фактически не обновлялся при загрузке, поэтому я не мог получить никакой информации от этого. Мне нужен был доступ к консоли.

В 7-м посте nullzone описывает довольно простой способ установить это. Итак, я пошел на работу:

Это будет постоянно зависать после 'Escape персонажа ^]'. У меня нет вывода и нет ответа на любой ключ. Затем я попробовал различные комбинации последовательных скоростей, разные / dev / pts / devices, ничего не получалось.

Затем, наконец, меня осенило, у меня был еще один сервер, который все еще работал и имел доступ по SSH. Я сделал то же самое изменение в XML для этой машины и добавил /etc/init/ttyS0.conf. На этой машине я мог бы просто перезагрузить ttyS0 с помощью команды sudo ttyS0 start.

Вернуться к virsh, перезагрузил libvert-bin, уничтожил сервер, запустил сервер, консоль virtual1 и точно так же. Застрял после побега персонажа. К счастью, я смог проверить файлы журнала на этом компьютере и заметил ошибку в /var/log/auth.log: «22 ноября, 03:46:11 virtual1 getty [1272]: /dev /–L: такого файла или каталога нет» , Казалось, что getty не принимает параметры командной строки, поэтому я поиграл с ними и, наконец, обнаружил, что мой /etc/init/ttyS0.conf должен выглядеть так:

Таким образом, последовательное устройство и скорость должны быть переключены на месте. Когда я теперь перезагрузил все, я получил консольный доступ к серверу virtual1, но все еще не к серверу virtual2.

К этому времени я уже почти вырывал свои волосы, и было 4 часа утра. До меня дошло, что, возможно, машина не входит в установленный режим, если бы она автоматически загружала файл /etc/init/ttyS0.conf. Некоторые дальнейшие исследования показали, что можно также изменить файл /boot/grub/menu.lst и добавить вывод консоли в grub:

После перезагрузки и перезагрузки у меня наконец появился вывод на консоль, а также на процесс загрузки. Оказалось, что монтировать NFS невозможно. К счастью, Ubuntu настолько умен, что затем останавливает загрузку и начинает ждать ввода от пользователя. Следовательно, машина может быть проверена (сеть запущена), но она никогда не завершает процесс загрузки, поэтому SSH не запускается и так далее.

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

Требования

Убедитесь, что можете подключиться к виртуальному серверу через консоль.
Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.

Основные ошибки

Разрешение имени хоста

Большинство ошибок подключения возникает тогда, когда ссылка на хост SSH не может быть сопоставлена с сетевым адресом. Это почти всегда связано с DNS, но первопричина часто бывает не связана с DNS.

На клиенте OpenSSH эта команда:

может выдать ошибку:

В PuTTY может появиться такая ошибка:

Чтобы устранить эту ошибку, можно попробовать следующее:

Если у вас возникают проблемы с разрешением DNS на любом уровне, в качестве промежуточного решения можно использовать IP-адрес сервера, например:

Истечение времени соединения

Эта ошибка значит, что клиент попытался установить соединение с SSH-сервером, но сервер не смог ответить в течение заданного периода ожидания.

На клиенте OpenSSH следующая команда:

выдаст такую ошибку:

ssh: connect to host 111.111.111.111 port 22: Connection timed out

В PuTTY ошибка выглядит так:

Network error: Connection timed out

Убедитесь, что IP-адрес хоста указан правильно.
Убедитесь, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт. Это поможет вам определить, не связана ли проблема с самим сервером.
Проверьте правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP.

Отказ в соединении

Эта ошибка означает, что запрос передается на хост SSH, но хост не может успешно принять запрос.

На клиенте OpenSSH следующая команда выдаст ошибку:

ssh user@111.111.111.111
ssh: connect to host 111.111.111.111 port 22: Connection refused

В PuTTY ошибка появится в диалоговом окне:

Network error: Connection refused

Убедиться, что IP-адрес хоста указан правильно.
Убедиться, что сеть поддерживает подключение через используемый порт SSH. Некоторые публичные сети могут блокировать порт 22 или пользовательские SSH-порты. Чтобы проверить работу порта, можно, например, попробовать подключиться к другим хостам через этот же порт.
Проверить правила брандмауэра. Убедитесь, что политика по умолчанию – не DROP, и что брандмауэр не блокирует этот порт.
Убедиться, что сервис запущен и привязан к требуемому порту.

4 ответа

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

SSH не проблема. Команда, которую вы используете для перезагрузки, - это проблема: не делайте reboot now , do reboot или shutdown -r now , чтобы перезагрузить систему.

REBOOTCOMMAND ранее не существовало. В 12.04 ваш now был просто проигнорирован, но теперь он используется . И он разбивает все.

Длинный ответ, с результатами моих испытаний и объяснением:

У меня есть аналогичная проблема с некоторыми серверами с 14.04 и VPS (размещенными на французском поставщике OVH - с запуском OpenVZ) И при выполнении reboot now внутри самого сервера.

Как и вы, я выпустил команду reboot now из консоли (вошел в систему с использованием SSH). Через несколько секунд после нажатия RETURN мой сеанс автоматически отключается. Как и вы, я никогда не мог повторно подключиться к серверу через SSH после выдачи этой команды.

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

Мне удалось подключиться к моей машине, и я увидел, что она входила в режим одиночного пользователя, ожидая, чтобы я нажал CTRL + D , чтобы продолжить или ввести пароль root для перехода в режим обслуживания. Я нажал комбинацию клавиш, чтобы продолжить процесс, а затем снова смог 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 : запуск daemon с /etc/init.d/ssh start или любая другая комбинация показала, что служба работает, хотя это не так, но если я запустил исполняемый файл с его абсолютным путем (в моем случае /usr/sbin/sshd ) Я увидел, что в конце файла конфигурации добавлено «0B», которое вызвало ошибку при запуске , устраняя проблему, решена проблема.

Другая потенциальная причина: ufw потеряет конфигурацию правила порта SSH. Это произошло со мной, по крайней мере, в один или два раза, когда после применения обновлений и перезагрузки конфигурация брандмауэра блокировала доступ к серверу. Использование консоли VPS консоли моего хостинга позволило мне выйти на компьютер и диагностировать проблему. Пример ниже показывает проблему (т.е. нет записи для порта 22):

Повторное включение порта следующим образом: трюк:

Для моей системы проблема заключалась в том, что скрипт ssh init /etc/init.d/ssh был единственным, кто проверял наличие выверенной версии init .

So /etc/init.d/ssh не запускается ssh, , потому что он считает, что он будет запущен с помощью upstart .

В моем случае выскочка не запускается из-за моей конкретной конфигурации:

Читайте также: