sshd в systemd: отказы запуска и сохранение доступа
У службы ssh цена ошибки выше обычной: неудачный перезапуск может оставить сервер без удалённого доступа. Поэтому порядок работы с ней отдельный: сначала проверка конфигурации, потом перезапуск, и никогда не наоборот. Имя unit различается: ssh.service в Debian и Ubuntu, sshd.service в RHEL.
О службе
Главное правило: перед перезапуском выполняйте sshd -t. Проверка разбирает конфигурацию и печатает строку с ошибкой. Перезапуск с неверной конфигурацией оставит службу остановленной, а текущее соединение при этом не разорвётся — и вы узнаете о проблеме только при следующем подключении, когда починить будет уже нечем.
Вторая особенность — сокет-активация. В части дистрибутивов ssh может работать через ssh.socket: тогда порт слушает systemd, а не сам sshd, и директива Port в sshd_config игнорируется. Порт в этом случае меняется в unit-файле сокета, и попытки править конфигурацию sshd не дают эффекта.
Третья — права на ключи хоста и на файлы пользователей. sshd строго проверяет права: закрытый ключ хоста должен быть доступен только root, а домашний каталог и файл authorized_keys не должны быть доступны для записи группе и остальным. Отказ по этой причине выглядит как отклонённая аутентификация, а не как сбой службы.
Как устроена
| Имя unit | ssh.service в Debian и Ubuntu, sshd.service в RHEL и Fedora |
|---|---|
| Проверка конфигурации | sudo sshd -t (расширенно — sshd -T) |
| Сокет-активация | при активном ssh.socket порт задаётся в сокете, а не в sshd_config |
| Права на ключи хоста | закрытый ключ — 0600 и владелец root, иначе sshd не запустится |
| Безопасный порядок | проверка sshd -t, затем systemctl reload ssh; отдельная сессия для страховки |
Частые ошибки
20 записей базы отмечены за этой службой.
Сообщения журнала
- Address already in use при запуске службыПорт или адрес уже занят: bind() failed (98: Address already in use). Как найти владельца порта и что делать с остатками прежнего процесса.
- Permission denied в журнале службыОтказ в доступе у службы systemd: права на файл, каталоги по пути, пользователь службы, параметры изоляции, SELinux и AppArmor.
- bind: Permission denied при привязке к портуОтказ при привязке к порту: обычно порт ниже 1024 у службы от непривилегированного пользователя. Как дать возможность CAP_NET_BIND_SERVICE.
- Connection closed by authenticating user: вход обрываетсяКлиент отключается на этапе проверки подлинности: не тот ключ, перебор или ограничение по адресу.
- System is booting up, unprivileged users are not permitted to log in yetВход отклоняется на время загрузки: обычные пользователи не пускаются, пока система не готова.
- systemd-logind: не удалось создать сеанс пользователяВход не проходит или сеанс неполный: не создаётся срез сеанса, исчерпаны пределы или нет каталога времени работы.
- Вход по доменной учётной записи не проходит: служба в автономном режимеДоменные пользователи не могут войти: служба не видит каталог и перешла в автономный режим.
- Загрузка задерживается на ожидании случайных чиселСлужба ждёт минуты при старте: генератору случайных чисел не хватает энтропии, что заметно в виртуальных машинах.
Коды выхода
- status=1/FAILURE в systemdКод 1/FAILURE означает, что программа запустилась и сама завершилась с ошибкой. Как найти настоящую причину в журнале службы.
- status=224/PAM в systemdКод 224/PAM: не удалось открыть сеанс PAM для службы. Обычно нет нужного файла настроек в /etc/pam.d.
Сигналы
- signal=HUP (status=1/HUP) в systemdПроцесс службы завершён сигналом HUP. Обычно это перезагрузка настроек, которую программа поняла как команду выйти.
Ошибки служб
- Host key verification failed при подключении к серверуКлиент отказывается подключаться: ключ хоста изменился. Когда это переустановка, а когда повод насторожиться.
- sshd: Bad configuration option и отказ запускаsshd не запускается из-за ошибки в sshd_config: неизвестный параметр, устаревшая настройка, ошибка в include.
- sshd: Too many authentication failuresСоединение обрывается до ввода пароля: клиент перебрал все ключи из агента. Как ограничить набор ключей.
- sshd: pam_unix и ошибки открытия сеансаВход по ssh не завершается: ошибки PAM при открытии сеанса. Полный диск, закрытый домашний каталог, ограничения модулей.
- sshd: отказ аутентификации из-за прав на файлыВход по ключу не работает: слишком широкие права на домашний каталог или authorized_keys. Разбор через журнал sshd.
- sshd: отказ в подключении из-за MaxStartupsЧасть подключений отклоняется под нагрузкой: предел незавершённых аутентификаций. Как считать значение.
- sshd: смена порта не действует из-за ssh.socketПорт в sshd_config игнорируется, потому что адрес слушает systemd через сокет-активацию. Где менять порт.
- Служба передачи файлов отказывает при входе: каталог доступен для записиПользователь не может войти: защита не разрешает корневой каталог, доступный для записи.
- Служба хостинга репозиториев: доступ по ssh не работаетКлонирование по ssh отказывает: встроенный сервер не запущен, порт занят или ключи недоступны.
Коды выхода этой службы
Числа в status=N ниже 200 назначает сама программа, 200 и выше — systemd, когда не смог подготовить запуск.
Диагностика
Обязательная команда перед перезапуском: печатает ошибку с номером строки.
sudo sshd -tИтоговая конфигурация со всеми include и значениями по умолчанию.
sudo sshd -T | head -30Состояние службы; для RHEL — sshd вместо ssh.
systemctl status ssh --no-pager -lРаботает ли сокет-активация: от этого зависит, где задаётся порт.
systemctl status ssh.socket --no-pager | head -8Права на закрытые ключи хоста: должны быть 0600 и root.
sudo ls -l /etc/ssh/ssh_host_*_keyПараметры unit, которые тут важны
- ExecReload=перезагрузка настроек без разрыва существующих сессий
- Restart=для ssh обычно on-failure: важно, чтобы доступ восстанавливался сам
- Type=notify в современных сборках, forking в старых
Частые вопросы
Поменял Port в sshd_config, перезапустил — порт не изменился. Почему?
Скорее всего активна сокет-активация: порт слушает ssh.socket, и конфигурация sshd тут не при чём. Проверьте systemctl status ssh.socket и меняйте ListenStream в сокете.
Как безопасно перезапускать ssh на удалённом сервере?
Сначала sshd -t. Затем reload вместо restart — существующие сессии не рвутся. Держите вторую открытую сессию до проверки нового подключения: она позволит откатить правку, если что-то пойдёт не так.
Источники
- Документация OpenSSH: sshd_config
- systemd.socket(5)
- Воспроизведено на тестовой машине, systemd 255 (Ubuntu 24.04)