Ситуация знакома каждому дежурному: мониторинг показывает, что сервер жив - пинг проходит, порты отвечают, - но SSH-сессия не открывается или зависает после приветствия. Загадочность именно в этом контрасте: сеть работает, а войти нельзя. В статье разбираем, что это значит технически, как добраться до сервера через серийную консоль или IPMI, что смотреть в первую очередь после входа и какие типовые причины вызывают это состояние. Отдельно - о настройке, которая должна быть сделана заранее, чтобы запасной вход всегда существовал.
Что означает живой ping при мёртвом SSH
Ping отвечает стек сетевого протокола в ядре, который работает независимо от пользовательских программ. Если ping идёт, значит ядро живо, драйвер сети работает и с сетевым оборудованием порядок. SSH при этом требует большего: выделения памяти под сессию, запуска процесса sshd, ответа аутентификации и порождения оболочки. Отказ на любом из этих этапов выглядит одинаково снаружи - соединение открылось и повисло.
Отсюда диагностическая ценность контраста: ping жив - ядро цело; SSH мёртв - проблема либо в ресурсах, либо в sshd, либо в подсистеме, от которой он зависит. Чаще всего на практике встречается первое: исчерпана память, диск переполнен, нагрузка запредельная - и именно поэтому сценарий этой статьи часто пересекается с зависаниями из соседней темы. Но есть и специфические причины, связанные с аутентификацией и DNS, о которых ниже.
Серийная консоль и IPMI как запасной вход
Первый вопрос при такой аварии - есть ли запасной вход, не зависящий от сети и пользовательских сервисов. На серверном железе их два. Серийная консоль - UART-порт материнской платы, к которому подключается кабель USB-TTL или штатный порт сервера; в ядре заранее настраивается вывод через console=ttyS0, и тогда по консоли доступен тот же вход в систему, что и локально. IPMI/BMC - отдельный процессор на плате со своей сетью и своим IP-адресом: он даёт веб-интерфейс и виртуальную консоль, работающие, даже когда основная система стоит.
В облаках роль запасного входа играет серийная консоль провайдера: у большинства есть кнопка Emergency Console или аналог, и заранее стоит проверить её работу на каждом образе. Именно поэтому в шаблоны виртуальных машин закладывается console=ttyS0 - параметр, превращающий серийную консоль в полноценный интерфейс входа.
Вход через любой из запасных путей даёт оболочку - и дальше начинается собственно диагностика по живой, но страдающей системе.
Анализ нагрузки по консоли
После входа первая пятёрка команд рисует картину состояния. uptime - load average: значения, в разы превышающие число ядер, говорят, что системе тесно в самой себе. free -m - память: если доступная память около нуля, а swap замучен вводом-выводом, перед нами классика истощения. df -h - место: переполненный корень или раздел /var ломает множество служб, включая аутентификацию, которая пишет логи. ps aux --sort=-%cpu | head и ps aux --sort=-rss | head - главные потребители процессора и памяти.
Тонкий признак для именно этого сценария: SSH открывается, но пароль не принимается или сессия закрывается сразу. Так бывает, когда заполнен диск и PAM не может записать в utmp, или когда система деградировала до состояния, в котором порождение процессов иногда срабатывает, а иногда нет. Анализ по консоли отвечает на этот вопрос за минуту.
Типичные причины живого пинга и мёртвого входа
Первая причина - исчерпание ресурсов: память кончилась, OOM-киллер гасит процессы, и в такой гонке sshd проигрывает чаще прочих. Вторая - переполненный диск: /tmp или /var забит, и SSH не может создать сессию. Третья - зависший DNS: sshd настроен на обратное разрешение адресов, и при мёртвом резолвере каждый вход подвисает на таймауте - классика, которую лечит UseDNS no в конфигурации.
Четвёртая - переполненные MaxStartups или лимиты PAM: bruteforce-атаки съедают все слоты, и честные подключения получают отказ. Пятая - зависший ФС-слой: если домашний раздел на NFS стал недоступен, вход выглядит повисшим, и выход - починка монтирования или вход от пользователя с локальным домашним каталогом. Каждая причина распознаётся одной-двумя командами по консоли.
Восстановление доступа без перезагрузки
Через консоль у администратора есть все инструменты: убить процесс-пожиратель через kill, освободить место удалением больших логов через find /var/log -size +500M, перезапустить sshd через systemctl restart sshd, временно поднять sshd на другом порту. Цель - вернуть вход по сети, чтобы дальнейшая работа шла в привычном терминале с приёмами из повседневного арсенала.
Перезагрузка остаётся последним средством, и её уместность оценивается по риску: системы с базами и некорректно завершающимися сервисами перезагружать больно, и если консоль даёт управление, всегда стоит сначала попробовать спасти систему без рестарта. Если рестарт неизбежен - по консоли выполняются корректные shutdown с таймаутом, а не выдёргивание питания.
Профилактика через настройку консоли заранее
Самое важное в статье происходит не в момент аварии. На каждом сервере заранее: включается серийная консоль через параметры ядра; IPMI настраивается на отдельный сегмент управления с собственным паролем; UseDNS no прописывается в sshd; лимиты MaxStartups осмысливаются; мониторинг отслеживает свободное место и память, чтобы приходить раньше исчерпания. Команда, которая проделала этот десяток настроек однажды, просто не сталкивается с сценарием из этой статьи - у неё впереди только лёгкие ночные дежурства.
Памятка
Короткий порядок: живой ping означает живое ядро; вход ищется через серийную консоль или IPMI; по консоли - uptime, free, df, ps; типовые причины - память, диск, DNS, лимиты; цель - вернуть SSH без перезагрузки; перезагрузка - только с корректным shutdown; все важные настройки консоли делаются заранее. Три минуты по этой памятке заменяют час блуждания между догадками и делают аварию управляемой.
Как работает вход по IPMI на практике
IPMI-интерфейс открывается в браузере по отдельному адресу управления, и в нём есть всё нужное для полного цикла: виртуальная консоль показывает экран сервера так, будто вы стоите перед ним; виртуальная клавиатура передаёт нажатия; кнопка питания даёт корректное выключение и жёсткий рестарт; журнал событий BMC фиксирует перебои питания и температуры. Ключевой момент эксплуатации - отдельность: сеть управления не зависит от главной сети сервера, и потому заторы трафика или ошибки конфигурации сетевого стека основной системы не отрезают вас от консоли.
Для удалённых площадок без удобного веб-доступа существует текстовая альтернатива - ipmitool: команды ipmitool -H адрес -U пользователь chassis power status читают состояние, sol activate поднимают серийную консоль прямо в терминале. По сути это тот же IPMI, только без браузера - идеальный вариант для работы с ноутбука в дороге или из скриптов мониторинга.
Ограничения серийной консоли
У серийной консоли есть свои пределы, о которых стоит знать заранее. Скорость передачи низкая, и полэкрана текста печатается с задержкой - но для диагностики этого достаточно. Некоторые дистрибутивы по умолчанию не запускают Getty-вход на ttyS0, и тогда консоль показывает загрузку, но не даёт приглашения входа: лечится включением
Эти три ограничения известны каждому, кто настраивал консоли в масштабе парка, и именно они объясняют, почему профилактический раздел этой статьи стоит в конце - но выполняется первым: без заранее включённой консоли весь ваш арсенал диагностических команд остаётся теорией, к которой нет доступа.
SSH на другом порту как временный ход
Если sshd жив, но его порт забит или страдает от лимитов, через консоль поднимается копия на другом порту: /usr/sbin/sshd -p 2222 -o UseDNS=no -o MaxStartups=100. Это даёт запасной вход до перезагрузки и позволяет работать с полноценным SSH-клиентом, копировать файлы и читать логи без тесноты серийной консоли. После восстановления основной конфигурации временная копия выключается, и в беглом разборе аварии она остаётся лишь строкой в истории shell.
Разбор реального случая
Характерный вечер: сервер пингуется, SSH виснет после пароля, мониторинг green. Серийная консоль с входом по ttyS0 показала систему на грани: 14 гигабайт swap из 16, load под сорок на восьми ядрах, и процесс сборки аналитики в состоянии R, съедающий всё. По консоли процесс был остановлен, место в /var/log освобождено от двадцатигигабайтного лога, и через минуту SSH принял новое соединение. Причина истории оказалась двойной - runaway-процесс и лог, который он же и порождал, - и обе были устранены за один заход через консоль без перезагрузки сервера.
Чек-лист настройки нового сервера
Всё, что защищает от сценария этой статьи, выполняется один раз на новом сервере. В параметры ядра добавляется console=ttyS0; активируется serial-getty@ttyS0; в sshd прописывается UseDNS no; IPMI получает отдельный адрес, свой пароль и место в менеджере секретов; мониторинг получает алерты на память, диск и load за гору до исчерпания. Пятнадцать минут настройки закрывают целый класс аварий - и по зрелому размышлению это лучший обмен в профессии: часы спокойного сна в обмен на четверть часа однажды вечером.
Тонкости аутентификации по консоли
Серийная консоль даёт вход той же учётной записью, что и локальный терминал, но с двумя практическими нюансами. Первый - консольный вход не проходит через PAM-сессии с их окружением, и PATH может быть минимальным, поэтому полные пути к командам вроде /usr/bin/systemctl стоит произносить целиком. Второй - на системах, где вход root по консоли ограничен (securetty), стоит заранее проверить, что ttyS0 входит в разрешённые терминалы, иначе в момент аварии консоль предложит пароль и отвергнет его. Оба нюанса проверяются за минуту на живой системе - и именно поэтому статья начинается с рекомендации проверять запасной вход до аварии.
Организация доступа к IPMI в команде
IPMI - ключ ко всем серверам сразу, и обращение с ним соответствующее. Пароль BMC хранится в менеджере секретов команды, а не в табличке на общем диске; адрес сети управления вносится в CMDB рядом с адресом основной сети; для консолей, доступных из интернета, включается ограничение по адресам и мониторинг неудачных входов. В зрелых командах ежеквартальная проверка IPMI входит в регламент: залогиниться, открыть консоль, убедиться в отклике - три минуты на сервер, которые гарантируют, что запасной вход сработает именно тогда, когда понадобится.
Финальный акцент темы
Всё сказанное в статье сводится к одному принципу: доступность входа важнее скорости реакции. Инженер с настроенной консолью и знанием пяти диагностических команд спасает сервер за десять минут; инженер без консоли в той же ситуации стоит перед выбором между жёсткой перезагрузкой в слепую и поездкой в дата-центр. Разница между этими сценариев создаётся не в момент аварии - она создаётся заранее, одной строкой параметров ядра и одним вечером настройки.
Финальная строка темы
Живой пинг при мёртвом SSH - не загадка, а приглашение к системной диагностике: ядро цело, и задача лишь в том, чтобы добраться до него путём, который вы сами себе оставили заранее. Инженер, однажды потративший вечер на настройку консолей, больше не смотрит на такие аварии как на лотерею - он смотрит на них как на план работ из шести пунктов.
Знание этих шести пунктов и заранее настроенный запасной вход - и ночью вместо тишины в эфире будет спокойный текстовый отчёт о том, что сервер возвращён в строй за десять минут без единого лишнего движения.
Конец истории - и пусть все ваши консоли останутся теорией!