Как устранить неполадки, если systemctl не перезапускает службу sshd?

Вопрос или проблема

Короче говоря: я хочу перезапустить службу sshd, потому что думаю, что это может решить проблему с использованием ssh на localhost. Но я не могу перезапустить службу sshd; это проблема, с которой я прошу помочь. Смотрите вывод терминала ниже.

Я искал и пробовал любые предложения, которые казались бы работающими, в течение нескольких часов сегодня. Я даже восстановил мой компьютер из резервной копии, дважды. Один раз на момент до появления исходной проблемы сегодня утром. Это не помогло. И один раз на резервную копию, сделанную до моего вчерашнего изменения конфигураций ssh. Даже после восстановления системы из этой резервной копии я всё равно не могу перезапустить службу sshd, и я не могу использовать ssh на localhost.

Единственная “подсказка”, которую я вижу в журнале, это строка, указывающая /etc/ssh/sshd_config: Permission denied. Но это, кажется, ничего не значит. Права доступа к этому файлу были 600. Я попробовал открыть доступ на все 777. Всё равно, та же строка /etc/ssh/sshd_config: Permission denied добавляется в журналы.

Пожалуйста, если вы знаете другой набор логов, где я мог бы найти подсказки о проблеме, дайте мне знать. Если вы столкнулись с этой проблемой и решили её, пожалуйста, поделитесь.

В случае, если ваш совет специфичен для дистрибутива, мой компьютер в данный момент работает на Fedora 37.

P.S. Я попытался запустить команду /usr/sbin/sshd самостоятельно в терминале. Насколько я могу судить, это та же команда, которую должна выполнить служба. Когда я запускаю эту команду в терминале, она работает! Команда не завершает выполнение. Пока она работает, я могу использовать ssh без проблем. Мне нужно использовать crtl+c, чтобы завершить команду /usr/sbin/sshd. Так почему sshd.service не удаётся запустить?

Ниже приведены фрагменты соответствующих команд и их выводы:

$ sudo systemctl restart sshd
Job for sshd.service failed because the control process exited with error code.
See "systemctl status sshd.service" and "journalctl -xeu sshd.service" for details.
$ systemctl status sshd.service
● sshd.service - OpenSSH server daemon
     Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; preset: disabled)
     Active: activating (auto-restart) (Result: exit-code) since Sun 2023-01-22 13:17:17 EST; 13s ago
       Docs: man:sshd(8)
             man:sshd_config(5)
    Process: 101315 ExecStart=/usr/sbin/sshd -D $OPTIONS (code=exited, status=1/FAILURE)
   Main PID: 101315 (code=exited, status=1/FAILURE)
        CPU: 16ms

$ journalctl -xeu sshd.service
...
Jan 22 13:19:22 fedora systemd[1]: Stopped sshd.service - OpenSSH server daemon.
   Subject: A stop job for unit sshd.service has finished
   Defined-By: systemd
   Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
   
   A stop job for unit sshd.service has finished.
   
   The job identifier is 11286 and the job result is done.

Jan 22 13:19:22 fedora systemd[1]: Starting sshd.service - OpenSSH server daemon...
   Subject: A start job for unit sshd.service has begun execution
   Defined-By: systemd
   Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
   
   A start job for unit sshd.service has begun execution.
   
   The job identifier is 11286.
Jan 22 13:19:22 fedora sshd[101395]: /etc/ssh/sshd_config: Permission denied
Jan 22 13:19:22 fedora systemd[1]: sshd.service: Main process exited, code=exited, status=1/FAILURE
   Subject: Unit process exited
   Defined-By: systemd
   Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
   
   An ExecStart= process belonging to unit sshd.service has exited.
   
   The process' exit code is 'exited' and its exit status is 1.
Jan 22 13:19:22 fedora systemd[1]: sshd.service: Failed with result 'exit-code'.
   Subject: Unit failed
   Defined-By: systemd
   Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
   
   The unit sshd.service has entered the 'failed' state with result 'exit-code'.
Jan 22 13:19:22 fedora systemd[1]: Failed to start sshd.service - OpenSSH server daemon.
   Subject: A start job for unit sshd.service has failed
   Defined-By: systemd
   Support: https://lists.freedesktop.org/mailman/listinfo/systemd-devel
   
   A start job for unit sshd.service has finished with a failure.
   
   The job identifier is 11286 and the job result is failed.

Единственная “подсказка”, которую я вижу в журнале, это строка, указывающая /etc/ssh/sshd_config: Permission denied. Но это, кажется, ничего не значит.

Это значит, что ваш ssh не может запуститься. Нашли вашу причину!

Но это, кажется, ничего не значит. Права доступа к этому файлу были 600. Я попробовал открыть доступ на все 777

Не делайте этого, OpenSSH, как правило, блокирует запуск, когда некоторые конфигурационные файлы, которые не должны быть доступны, имеют права на запись всем (и это обоснованно; с правами 777 каждый пользователь мог бы настроить sshd на разрешение входа root без проверки каких-либо учетных данных).

Подсказка здесь в том, что это не происходит, но что сервер SSH всё равно не может прочитать файл конфигурации.

Я полагаю, что как-то (я никогда с таким не сталкивался) SELinux домен файла sshd.config был поврежден.

 sudo fixfiles onboot

после перезагрузки, вероятно, это исправит.

С моей стороны, я не могу найти, так как при запуске команды, появляется sudo: fixfiles: command not found

Кто-нибудь здесь может помочь?

Ответ или решение

Теория

Когда системная служба sshd не запускается или не перезапускается через systemctl, это может быть связано с несколькими причинами. Главной, как показывает ваша ситуация, является ошибка "Permission denied" при попытке доступа к файлу конфигурации /etc/ssh/sshd_config. В вашей ситуации это сообщение ясно указывает на проблему с правами доступа к этому файлу. Такое сообщение об ошибке обычно связано либо с некорректной установкой прав доступа, либо, как в вашем случае, с несоответствием политик безопасности SELinux.

SELinux может блокировать доступ к файлам, если у них неправильные контексты безопасности. Это может произойти, если файлы были изменены, перемещены или восстановлены, как это произошло у вас.

Пример

Как показывают выводы ваших команд, системная служба sshd не может получить доступ к конфигурационному файлу, даже когда установлены крайне широкие права 777, что указывает на проблему с SELinux контекстом. SELinux используется в Fedora для усиленной безопасности и может запретить доступ к файлам, если их контексты не соответствуют ожидаемым.

Применение

Чтобы устранить проблему с невозможностью запустить службу sshd через systemctl, вам нужно проверить и исправить SELinux контексты для файла /etc/ssh/sshd_config. Вот шаги, которые можно предпринять для решения проблемы:

  1. Восстановление стандартных атрибутов SELinux:

    Для восстановления корректных контекстов безопасности SELinux используйте следующие команды:

    sudo restorecon -v /etc/ssh/sshd_config

    Это команда восстановит предустановленный контекст безопасности для файла /etc/ssh/sshd_config.

  2. Проверка и установка корректных прав доступа к файлу:

    Убедитесь, что права доступа установлены корректно. Обычно для файла конфигурации sshd_config достаточно прав 600:

    sudo chmod 600 /etc/ssh/sshd_config

    Также убедитесь, что файл принадлежит юзеру root:

    sudo chown root:root /etc/ssh/sshd_config
  3. Ручное управление контекстами SELinux:

    Если проблема сохраняется, можно проверить текущий SELinux контекст файла:

    ls -Z /etc/ssh/sshd_config

    Ожидается, что контекст будет примерно таким: system_u:object_r:sshd_etc_t:s0. Если он отличается, команда restorecon должна была его исправить. Если это не помогло, вы можете использовать semanage для явного назначения контекста (при необходимости предварительно установить policycoreutils-python-utils):

    sudo semanage fcontext -a -t sshd_etc_t /etc/ssh/sshd_config
    sudo restorecon -v /etc/ssh/sshd_config
  4. Перезагрузка системы:

    Некоторые изменения SELinux контекстов могут потребовать перезагрузки системы:

    sudo reboot
  5. Дополнительные проверки:

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

    sudo fixfiles onboot
    sudo reboot

Если у вас возникают сложности с доступом к команде fixfiles, убедитесь, что пакет, предоставляющий её (обычно policycoreutils) установлен.

Эти шаги помогут вам исправить проблему с запуском sshd через systemctl, сосредотачиваясь на корректировке проблем с правами доступа и контекстами SELinux, которые являются основной причиной "Permission denied". Устранение этих проблем должно обеспечить успешное выполнение команды sudo systemctl restart sshd без ошибок.

Оцените материал
Добавить комментарий

Капча загружается...