Почему apt спрашивает про sshd_config и что выбрать: разбор опасного диалога на свежем сервере

Так выглядит нулевой день в Linux Upskill Challenge от Black IT Academy: двадцать уроков, один сервер, чат в Slack и договорённость вести публичный журнал — что сделал, что сломалось. Задача первого дня звучит почти издевательски: поднять машину, зайти на неё, выложить скриншот. Десять минут работы. А потом посреди обычного обновления пакетов терминал замирает и задаёт вопрос, от которого зависит, попадёте ли вы на этот сервер снова.

Ниже — что означает диалог про sshd_config и какой пункт в нём выбирать.

Что такое sshd_config

Файл /etc/ssh/sshd_config управляет поведением SSH-сервера. На каком порту слушать, разрешён ли вход под root, пускает ли машина по паролю или только по ключу. Если совсем грубо — это файл, который решает, пустят ли вас обратно после того, как вы закроете текущую сессию.

Почему файл считается изменённым, если вы его не трогали

Сервер существует четыре минуты, ни одного конфига вы не открывали — а apt уверяет, что версия «locally modified». Логичный вопрос: кем изменён?

Провайдером. Когда создаётся дроплет, система провижининга DigitalOcean записывает в sshd_config настройки SSH — те самые, что вы выбрали в панели при создании машины. Для apt файл после такой правки перестаёт совпадать с тем, что поставляется в составе пакета openssh. Приходит новая версия openssh — пакетный менеджер останавливается и спрашивает, чью версию оставить.

A new version of configuration file /etc/ssh/sshd_config is available, but the version installed currently has been locally modified.

What do you want to do about modified configuration file sshd_config?

Ничего не сломалось: так работает аккуратность пакетного менеджера. Он не станет молча перезаписывать конфиг, который кто-то поменял осознанно. Сложность в том, что «кто-то» здесь — не вы, и узнаёте вы об этом ровно в момент принятия решения.

Что делают четыре пункта меню

Чем опасен неправильный ответ

Выберете версию сопровождающего — apt подменит файл стоковым дефолтом Ubuntu. Настройки, которые DigitalOcean туда положил, чтобы вы могли войти, пропадут. Как именно это ударит, зависит от того, что было прописано: может отключиться вход по паролю, а ключ вы не загружали; может закрыться вход под root, а другого пользователя на машине ещё нет.

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

Что делать после того, как оставили локальную версию

Главное, что стоит знать: «keep local» ничего не выбрасывает. apt кладёт версию из пакета рядом с вашей, обычно как /etc/ssh/sshd_config.dpkg-dist, иногда с суффиксом .ucf-dist. Потери нет — решение просто откладывается.

Разобрать это можно позже, когда сервер уже настроен и есть план на случай поломки:

1. Сравните файлы командой diff /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-dist — увидите, что дописал провайдер и что принесло обновление пакета.
2. Перенесите в рабочий конфиг только то, что понимаете и что вам действительно нужно.
3. Остальное не трогайте: стоковые значения по умолчанию сами по себе не улучшение.
4. Держите под рукой доступ через веб-консоль панели — это запасной вход, если SSH перестанет пускать.

Когда «оставить локальную» — неверный выбор

Правило из этой истории звучит жёстко: на машине, куда вы подключены по SSH, всегда оставлять локальную версию, а разбираться потом. Разумный дефолт, но не догма. Если файл правили вы сами, новая версия пакета закрывает известную дыру, а ваши изменения — пара комментариев, тянуть смысла нет. Разница в том, что решение принимается с открытыми глазами, а не наугад в паузе посреди обновления.

Чек-лист для первого дня на сервере

• Сразу после создания машины поставьте лимит на биллинг. Алерт на скромную сумму вроде $10 избавляет от сюрпризов в конце месяца.
• Не сравнивайте хостинги дольше десяти минут. Цель первого дня — работающий вход, а не идеальный выбор провайдера.
• Проверьте базу: whoami, uptime, затем sudo apt update && sudo apt upgrade -y.
• Увидели вопрос про конфиг, который сами не правили — сначала выясните, кто и зачем его менял. Обычно это провижининг провайдера.
• Заведите журнал. Две строки в день про то, что делали и что сломалось, через месяц экономят часы.

Вывод простой. Инфраструктура страшна не командами. Страшно то, что уже настроено за вас, о чём вы не знаете, — и первый раз вы узнаёте об этом, когда система просит принять решение.

Вопрос про sshd_config — встроенный тормоз пакетного менеджера, который не даёт молча снести настройки доступа к вашей машине. Если файл трогал не вы: оставить локальную версию, потом diff. Новая версия никуда не денется, она лежит рядом с расширением dpkg-dist — и разобрать её можно спокойно, когда сервер уже настроен.