Ubuntu/Debian: безопасный apt upgrade по SSH и план спасения через rescue/console

Почему apt upgrade по SSH иногда заканчивается «кирпичом»

На тестовом стенде обновления проходят незаметно. На проде достаточно одного неудачного совпадения: обновился openssh-server, перезапустился sshd, параллельно поменялась сеть (netplan/systemd-networkd), или прилетел новый initramfs и после перезагрузки что-то не смонтировалось. Итог предсказуем: SSH недоступен, а вы видите только rescue/console.

Эта инструкция — не про «как обновить пакеты», а про то, как обновлять безопасно и иметь план восстановления на случай, если всё пошло не так.

Подготовка перед обновлением: чеклист, который экономит часы

1) Убедитесь, что у вас есть альтернативный доступ

Минимум — доступ к провайдерской консоли (VNC/Serial) или rescue mode. Если есть только SSH — это лотерея, особенно при обновлениях ядра, сети и загрузчика. Для проектов, где простой критичен, удобнее держать сервис на VDS, где консоль/рескью обычно доступны в панели и спасают при сетевых ошибках.

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

2) Откройте «страховочную» сессию и не работайте без терминального мультиплексора

Перед apt upgrade зайдите на сервер и запустите tmux или screen. Если SSH оборвётся, вы переподключитесь и продолжите сессию.

tmux new -s upgrade

Дальше всю работу делайте внутри tmux.

3) Проверьте, что SSH реально переживёт обновление

Проверьте, что запущен именно тот демон, который вы ожидаете, и что он стартует при загрузке.

systemctl status ssh
systemctl is-enabled ssh
ss -lntp | grep -E ':(22)\s'

На Debian/Ubuntu юнит обычно называется ssh, а пакет — openssh-server. Если у вас кастомный порт — ищите по факту через ss.

4) Зафиксируйте текущее состояние сети и маршрутов

Восстановление «после» часто упирается не в пакеты, а в сеть. Сохраните вывод команд — это ваша шпаргалка в rescue.

ip a
ip r
resolvectl status 2>/dev/null || true
networkctl status 2>/dev/null || true

5) Проверьте место на диске и /boot

Классика: новое ядро не влезло в /boot, initramfs не собрался, обновление прервалось. Быстро оцените ситуацию:

df -h
df -h /boot || true
dpkg -l | grep -E '^ii\s+linux-image' | tail -n 20

6) На время апдейта включите «предохранители» APT

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

export DEBIAN_FRONTEND=noninteractive

Но помните: noninteractive не решает проблем, он лишь делает поведение предсказуемее. Конфликтующие конфиги всё равно нужно потом проверить.

Правильная тактика apt upgrade по SSH

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

apt update
apt list --upgradable

Если в списке есть openssh-server, пакеты сети, systemd или ядро — это не повод отменять, но повод быть особенно аккуратным и заранее решить, когда будет перезагрузка.

Шаг 2: выполняем обновление

apt -y upgrade

Если планируется более серьёзное изменение зависимостей (новое ядро, systemd, пакеты, меняющие состав системы), иногда разумнее использовать:

apt -y full-upgrade

Но full-upgrade повышает риск удаления пакетов. Перед подтверждением внимательно читайте, что будет удалено, особенно на серверах с нестандартным стеком.

Шаг 3: внимательно следим за перезапусками сервисов

При обновлении openssh-server демон может перезапускаться. Если у вас одна SSH-сессия без tmux — вы можете потерять контроль. В tmux это обычно переживается.

Полезно в отдельном окне tmux держать журнал:

journalctl -f

Шаг 4: если обновлялись ядро или initramfs — перезагрузка должна быть осознанной

После обновления ядра/модулей система может потребовать перезагрузку. Прежде чем ребутить, проверьте, что initramfs обновился без ошибок:

ls -lh /boot | tail -n 50
grep -R "update-initramfs" /var/log/apt/term.log | tail -n 50

Если initramfs собран неправильно или не включает нужные модули (диск/RAID/LVM), сервер может не загрузиться до нормального режима. Если у вас есть staging/тестовый контур, обновляйте сначала там; в контексте практик «почти без простоя» может пригодиться подход из материала про staging и переключение через DNS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Если после обновления SSH пропал: быстрый план диагностики

Первая задача — отделить проблему «сеть» от проблемы «sshd».

1) Проверьте доступность порта с вашей стороны

Если у вас есть другая машина в той же сети/ДЦ:

nc -vz SERVER_IP 22

Если порт закрыт или таймаут — идём в консоль/rescue.

2) В консоли проверьте, жив ли sshd и слушает ли он порт

systemctl status ssh
ss -lntp | grep -E ':(22)\s'
journalctl -u ssh -b --no-pager | tail -n 200

Если ssh не стартует — частая причина в синтаксисе /etc/ssh/sshd_config (после ручных правок) или в несовместимых опциях после обновления.

Проверьте конфиг тестом:

sshd -t

3) Если проблема в сети: netplan и «rollback» по-человечески

На Ubuntu серверы часто используют netplan. Если после обновления или правок сеть не поднялась, вспомните ключевую идею: при удалённой работе конфиги сети нужно применять так, чтобы был автооткат.

1. Если вы применяли конфигурацию через netplan try, откат сработает автоматически при неподтверждении.
2. Если применяли через netplan apply, откат уже ваша задача: вернуть рабочие файлы в /etc/netplan и применить повторно.

Для диагностики:

netplan --debug generate
netplan --debug apply
ip a
ip r

Лучший «netplan rollback» — это заранее: использовать netplan try всегда, когда вы работаете по SSH.

Когда система загрузилась в rescue mode или emergency: что это и как выйти

В Debian/Ubuntu «rescue mode» и «emergency mode» обычно означают, что systemd не смог смонтировать файловые системы, поднять нужные сервисы или корректно пройти цели загрузки. Часто вы видите сообщение про необходимость ввести root-пароль для обслуживания или лог о падении какого-то монтирования.

1) Посмотрите, какая цель systemd активна и что задано по умолчанию

Иногда сервер «застревает» в режиме обслуживания из-за временно выставленной цели или неудачной смены поведения.

systemctl get-default
systemctl list-units --failed
systemctl status --no-pager

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

systemctl set-default multi-user.target

Но не делайте это «наугад»: сначала убедитесь, что проблема не в диске/FS или в сетевой конфигурации.

2) Частые причины падения в rescue: /etc/fstab и диски

Проверьте, что UUID/диски на месте, и что нет «жёстких» монтирований сетевых хранилищ, из-за которых система не проходит загрузку.

cat /etc/fstab
blkid
lsblk -f
mount -a

Если mount -a ругается — это прямой указатель на проблемную строку в /etc/fstab.

3) Если проблема в initramfs: пересоберите и проверьте загрузчик

Подозрение на initramfs оправдано, когда после обновления ядра сервер перестал видеть диск, mdraid/LVM не собирается, или root-раздел не находится.

В рабочей системе (или в chroot из rescue) имеет смысл пересобрать initramfs и обновить конфигурацию загрузчика:

update-initramfs -u -k all
update-grub

Если у вас root на LVM/RAID/crypto — убедитесь, что соответствующие пакеты и хуки на месте, а модули попадают в initramfs.

Запасной SSH в initramfs: dropbear как «парашют»

Один из самых практичных способов не остаться без доступа после неудачного апдейта ядра или initramfs — поднять SSH прямо в initramfs. На Debian/Ubuntu это часто делают через dropbear.

Смысл dropbear: даже если система не загрузилась полностью, вы можете подключиться по SSH на ранней стадии, посмотреть логи и починить root/fs/network без физического доступа.

1) Установка и базовая настройка

Типовой набор на Debian/Ubuntu выглядит так:

apt update
apt -y install dropbear-initramfs

Добавьте публичный ключ для входа в initramfs:

mkdir -p /etc/dropbear/initramfs
cat /root/.ssh/authorized_keys > /etc/dropbear/initramfs/authorized_keys
chmod 600 /etc/dropbear/initramfs/authorized_keys

После этого пересоберите initramfs:

update-initramfs -u

2) Важные нюансы безопасности и доступности

Dropbear в initramfs — сильный инструмент, но требующий дисциплины. Минимальный набор здравого смысла:

• используйте отдельный ключ (не тот же, что для обычного доступа), храните его защищённо;
• понимайте, на каком интерфейсе и адресе он будет доступен (особенно на серверах с несколькими IP);
• учитывайте firewall/фильтрацию у провайдера: ранний SSH должен быть доступен только с вашей админской сети.

Если сомневаетесь — потренируйтесь на тестовой машине и сделайте контрольную перезагрузку в окно обслуживания.

Восстановление через rescue/console: рабочий runbook

1) Загрузитесь в rescue и смонтируйте систему

Конкретика зависит от панели провайдера, но логика одинаковая: загрузились в rescue, нашли разделы, смонтировали root, сделали chroot.

lsblk -f
mount /dev/sda2 /mnt
mount /dev/sda1 /mnt/boot 2>/dev/null || true
mount --bind /dev /mnt/dev
mount --bind /proc /mnt/proc
mount --bind /sys /mnt/sys
chroot /mnt /bin/bash

Дальше вы как будто «внутри» своей системы.

2) Почините пакеты, если обновление оборвалось

dpkg --configure -a
apt -f install
apt -y upgrade

3) Верните SSH, если он сломан или удалён

apt -y install openssh-server
systemctl enable ssh

Если в chroot нельзя стартовать сервисы — это нормально. Главное, чтобы пакет стоял и конфиг был валиден.

Проверьте конфиг:

sshd -t

4) Проверьте systemd-цель

systemctl get-default
systemctl set-default multi-user.target

5) Завершите: пересоберите initramfs/grub и перезагрузитесь

update-initramfs -u -k all
update-grub
exit
reboot

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Практика: как снизить риск в следующий раз

Делайте обновления «маленькими порциями»

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

Используйте netplan try для любых изменений сети по SSH

Даже если задача «просто поменять DNS» — делайте через механизм, который умеет сам откатываться. Это закрывает целый класс инцидентов «потерял SSH из-за сети».

Держите минимум один подтверждённый путь восстановления

Rescue/console или dropbear в initramfs — выбирайте, что вам ближе. Важно не наличие «в теории», а проверка «на практике»: тестовая перезагрузка, проверка входа, понимание последовательности действий. Для дополнительных идей по админке и доступу к серверу смотрите обзор панелей управления для VDS и их возможностей консоли.

Короткий итог

apt upgrade по SSH на Ubuntu/Debian безопасен ровно настолько, насколько вы подготовились: tmux, контроль сети, место на /boot, валидный sshd и понятный план восстановления. Если всё же прилетели в rescue mode — не паникуйте: проверяйте systemd-цели, /etc/fstab, initramfs и поднимайте SSH обратно через chroot. А для систем, где простой недоступен, имеет смысл заранее настроить dropbear в initramfs как «парашют».