Вопрос или проблема
Короче говоря: я хочу перезапустить службу 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
. Вот шаги, которые можно предпринять для решения проблемы:
-
Восстановление стандартных атрибутов SELinux:
Для восстановления корректных контекстов безопасности SELinux используйте следующие команды:
sudo restorecon -v /etc/ssh/sshd_config
Это команда восстановит предустановленный контекст безопасности для файла
/etc/ssh/sshd_config
. -
Проверка и установка корректных прав доступа к файлу:
Убедитесь, что права доступа установлены корректно. Обычно для файла конфигурации
sshd_config
достаточно прав 600:sudo chmod 600 /etc/ssh/sshd_config
Также убедитесь, что файл принадлежит юзеру
root
:sudo chown root:root /etc/ssh/sshd_config
-
Ручное управление контекстами 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
-
Перезагрузка системы:
Некоторые изменения SELinux контекстов могут потребовать перезагрузки системы:
sudo reboot
-
Дополнительные проверки:
Если ничего из вышеперечисленного не помогло, воспользуйтесь командой для пересканирования и исправления всех файлов на системной файловой системе:
sudo fixfiles onboot sudo reboot
Если у вас возникают сложности с доступом к команде fixfiles
, убедитесь, что пакет, предоставляющий её (обычно policycoreutils
) установлен.
Эти шаги помогут вам исправить проблему с запуском sshd
через systemctl
, сосредотачиваясь на корректировке проблем с правами доступа и контекстами SELinux, которые являются основной причиной "Permission denied". Устранение этих проблем должно обеспечить успешное выполнение команды sudo systemctl restart sshd
без ошибок.