Debian/Ubuntu: как исправить sshd re-exec requires execution with an absolute path

Ошибка sshd re-exec requires execution with an absolute path в Debian и Ubuntu неприятна не только формулировкой. Чаще всего она появляется в момент, когда вы перезапускаете SSH и понимаете, что сервис не поднимается так, как должен. На рабочем сервере это уже не просто баг, а потенциальная потеря доступа.

Хорошая новость в том, что причина обычно вполне конкретная: sshd запущен не по абсолютному пути, переопределён ExecStart в ssh.service, сломан drop-in для systemd или кто-то тестировал демон вручную через PATH и потом перенёс этот способ запуска в unit.

Ниже разберём безопасный сценарий: как понять источник ошибки, что проверить в systemd, где искать override, как вернуть корректный запуск /usr/sbin/sshd и как не отрезать себе текущую SSH-сессию во время исправления.

Если вы уже подключены к серверу по SSH, не закрывайте текущую сессию, пока не проверите новый вход. Это главное правило для любых работ с OpenSSH.

Что означает эта ошибка

OpenSSH умеет выполнять повторный запуск собственного процесса, так называемый re-exec. Для этого демон должен быть запущен по абсолютному пути, например /usr/sbin/sshd. Если же процесс стартовал как просто sshd, без полного пути, OpenSSH не может корректно выполнить re-exec и завершает запуск с сообщением requires execution with an absolute path.

На Debian и Ubuntu в штатной установке это обычно не происходит: systemd запускает сервис корректно, а в unit-файле уже указан нужный путь. Поэтому ошибка почти всегда говорит о локальной правке или нестандартном сценарии запуска.

• Изменён ExecStart в unit-файле или override.
• Кто-то запускает демон вручную как sshd, а не как /usr/sbin/sshd.
• Unit-файл перенесли с другой системы и не проверили путь.
• Пакет OpenSSH переустанавливали или правили вручную, и состояние сервиса стало нештатным.

Если коротко: проблема почти всегда не в сети, не в порте 22 и не в правилах фаервола, а именно в том, как запущен бинарник sshd.

Безопасный порядок действий перед исправлением

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

Если сервер размещён на виртуальном хостинге, подобные правки уровня systemd обычно недоступны, а сама ошибка характерна именно для полноценных VPS/VDS или выделенных машин, где вы управляете сервисами самостоятельно.

Рабочий порядок такой:

1. Проверить синтаксис конфигурации SSH.
2. Посмотреть статус сервиса и журнал.
3. Вывести итоговый unit вместе с drop-in.
4. Исправить путь в ExecStart, если он неверный.
5. Сделать daemon-reload и только потом перезапускать сервис.

Частая ошибка — сразу редактировать /etc/ssh/sshd_config, хотя проблема сидит не в конфиге демона, а в systemd.

Сначала проверяем сам конфиг SSH

Даже если текст ошибки намекает на путь к бинарнику, начать лучше с проверки конфигурации. Это занимает меньше минуты и отсеивает вторичные проблемы.

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -T | head

Команда sshd -t проверяет синтаксис /etc/ssh/sshd_config и всех подключаемых файлов. Если вывода нет и код возврата равен нулю, синтаксис в порядке. Команда sshd -T показывает итоговую эффективную конфигурацию, что удобно при сложных include-цепочках.

Если здесь уже есть ошибка, сначала исправляйте её. Если же конфиг проходит проверку, а systemctl restart ssh всё равно падает, почти наверняка дело в unit-файле или override.

Кстати, если вы параллельно усиливаете настройки SSH, пригодится материал про безопасные шифры, KEX и MAC для OpenSSH. Но сначала нужно вернуть сервис в рабочее состояние.

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

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

Подробнее

Смотрим статус сервиса и journal

Теперь нужно понять, какую именно команду запускает systemd и в каком месте сервис ломается.

sudo systemctl status ssh --no-pager -l
sudo journalctl -u ssh -n 100 --no-pager

В журнале ищите строки, где виден запуск процесса. Если там фигурирует просто sshd -D без полного пути, диагноз почти готов.

Следующая обязательная команда:

sudo systemctl cat ssh

Она показывает базовый unit и все подключённые drop-in-файлы. Именно здесь чаще всего всплывает /etc/systemd/system/ssh.service.d/override.conf с неудачным переопределением ExecStart.

Как должен выглядеть правильный ExecStart

Ключевое правило простое: OpenSSH должен запускаться как /usr/sbin/sshd, а не как просто sshd.

Проверить путь к бинарнику можно так:

command -v sshd
ls -l /usr/sbin/sshd
dpkg -S /usr/sbin/sshd

Типичный корректный фрагмент unit-файла выглядит так:

[Service]
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS

Если вы видите ExecStart=sshd -D, ExecStart=/sbin/sshd -D или запуск через лишнюю обёртку, это и есть вероятная причина ошибки.

Для shell достаточно найти команду через PATH, но для re-exec OpenSSH важно, чтобы сам процесс изначально был запущен по абсолютному пути.

Где чаще всего ломается systemd-конфигурация

У сервиса может быть не только основной unit, но и локальные override. Поэтому смотреть один файл недостаточно.

sudo systemctl show -p FragmentPath ssh
sudo systemctl show -p DropInPaths ssh
sudo find /etc/systemd/system -maxdepth 3 -type f | grep ssh.service

На практике чаще всего встречаются такие варианты:

• в override записано ExecStart=sshd -D;
• старое значение сбросили и добавили новое, но с неверным путём;
• сервис завернули в /bin/sh -c, где запускается просто sshd;
• unit перенесли с другого дистрибутива или старого образа.

Если override не нужен, проще удалить его и вернуться к пакетному unit-файлу.

sudo rm -f /etc/systemd/system/ssh.service.d/override.conf
sudo systemctl daemon-reload

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

Как правильно исправить ExecStart

Если проблема именно в ExecStart, исправление обычно сводится к корректному override. В systemd новое значение нужно задавать правильно: сначала сбросить старое, потом указать новое.

[Service]
ExecStart=
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS

Редактировать override удобнее так:

sudo systemctl edit ssh

После сохранения сразу проверьте итоговую конфигурацию:

sudo systemctl cat ssh

И только затем применяйте изменения:

sudo systemctl daemon-reload
sudo systemctl restart ssh
sudo systemctl status ssh --no-pager -l

Если вы когда-то правили основной unit напрямую в системном каталоге, лучше уйти от такого подхода. Пакетные файлы перезаписываются обновлениями, а override сопровождать гораздо проще.

Когда ошибка возникает из-за ручного запуска

Иногда systemd вообще ни при чём. Администратор останавливает сервис и для диагностики запускает демон вручную:

sudo sshd -D -d

Такой запуск нежелателен. Для теста нужно указывать полный путь:

sudo /usr/sbin/sshd -D -d

Если хотите аккуратно проверить конфиг на нестандартном порту, используйте такой сценарий:

sudo /usr/sbin/sshd -t
sudo /usr/sbin/sshd -D -d -p 2222 -f /etc/ssh/sshd_config

После этого из другой сессии можно проверить подключение на порт 2222. Если такой экземпляр стартует нормально, а unit через systemd — нет, значит проблема почти точно в описании сервиса.

Переустановка openssh-server, если состояние совсем сомнительное

Если путь существует, но unit и бинарник выглядят подозрительно, проще проверить пакет и при необходимости переустановить серверную часть OpenSSH.

dpkg -l | grep openssh
sudo apt update
sudo apt install --reinstall openssh-server

После этого снова выполните базовые проверки:

sudo systemctl daemon-reload
sudo /usr/sbin/sshd -t
sudo systemctl restart ssh
sudo systemctl status ssh --no-pager -l

Важно помнить: переустановка пакета обычно не удаляет локальные override в /etc/systemd/system. Если drop-in остался сломанным, ошибка вернётся.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Короткий сценарий восстановления за 5 минут

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

sudo /usr/sbin/sshd -t
sudo systemctl cat ssh
sudo systemctl edit ssh

В override-файле оставьте:

[Service]
ExecStart=
ExecStart=/usr/sbin/sshd -D $SSHD_OPTS

Затем примените и проверьте:

sudo systemctl daemon-reload
sudo systemctl restart ssh
sudo systemctl status ssh --no-pager -l
sudo ss -tlpn | grep ':22 '

Если сервис поднялся и порт слушается, откройте новую SSH-сессию. Старую закрывайте только после успешного входа.

Как не поймать эту проблему снова

• Не редактируйте пакетный unit-файл напрямую без крайней необходимости.
• Любые изменения в ssh.service делайте через systemctl edit.
• Всегда указывайте абсолютный путь: /usr/sbin/sshd.
• Перед перезапуском проверяйте конфиг через /usr/sbin/sshd -t.
• Не закрывайте текущую SSH-сессию, пока не протестируете новую.
• Фиксируйте такие изменения в automation или хотя бы в документации.

Если вы управляете несколькими серверами, полезно периодически сверять локальные override и шаблоны деплоя. Это особенно актуально после миграций. Если переносите проекты между машинами, пригодится и инструкция про миграцию сайта без простоя, чтобы не тащить старые системные ошибки в новый контур.

Итог

Ошибка sshd re-exec requires execution with an absolute path почти всегда означает одно: OpenSSH запущен не тем способом, который ожидает сам демон. Обычно виноват неправильный ExecStart в ssh.service, неудачный drop-in или ручной запуск без полного пути.

Нормальный путь восстановления в Debian и Ubuntu такой: проверить /usr/sbin/sshd -t, посмотреть systemctl status ssh и journalctl -u ssh, затем обязательно изучить systemctl cat ssh, вернуть абсолютный путь в ExecStart и выполнить daemon-reload. В большинстве случаев этого достаточно, чтобы вернуть рабочий SSH за несколько минут и без потери доступа.