Система отказывается от SSH и зависает при «загрузке» после установки systemd

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

Всем удачи!

10
06.03.2018, 21:42
5 ответов

Я подозреваю, что существует файл / etc / nologin (содержимое которого будет «Система загружается»), который не удаляется после установки systemd. .

[обновление] На вас влияет ошибка, о которой сообщалось в Ubuntu BTS в декабре прошлого года. Это связано с файлом / var / run / nologin (= / run / nologin , поскольку / var / run является символической ссылкой на / run ), который не удаляется в конце установки systemd.

/ etc / nologin - стандартный файл nologin. / var / run / nologin - это альтернативный файл, который может использоваться PAM-модулем nologin ( man pam_nologin ).

Обратите внимание, что ни один из файлов nologin не влияет на подключения пользователя root, вход в систему запрещен только обычным пользователям.

23
27.01.2020, 20:00

@xhienne дал мне правильное направление.

После поиска в файловой системе я нашел файл / run / nologin (@xhienne предложил / etc / nologin), удаление которого решило проблему.

Условие существовало в /usr/lib/tmpfiles.d/systemd.conf

Я включу этот шаг в свой сценарий.

sudo rm /run/nologin
12
27.01.2020, 20:00
Note:  This answer is applicable whether or not systemd was recently installed or not.
       The issue was observed even after systemd had been installed a long time.

El rastreador de errores de distribución de Mageia parece tener un problema relacionado abierto:Error 21080 -inicio de sesión ssh deshabilitado por /run/nologin después de un reinicio .

Después de experimentar este problema con bastante frecuencia, encontrar el rastreador ayudó a identificar una solución alternativa que podría ser más apropiada que simplemente eliminar el archivo/run/login .

Aquí hay algunos datos relacionados con consultas de información en ese rastreador de errores:

$ ls -l /run/nologin 
-rw-r--r-- 1 root root 42 Mar  6 10:11 /run/nologin
$ cat /run/nologin
"System is booting up. See pam_nologin(8)"
$ date
Tue Mar  6 11:10:38 CST 2018
$ uptime
11:15:10 up  1:04,  0 users,  load average: 0.07, 0.07, 0.08
$ systemctl status systemd-user-sessions.service
● systemd-user-sessions.service - Permit User Sessions
   Loaded: loaded (/usr/lib/systemd/system/systemd-user-sessions.service; static
   Active: inactive (dead)
     Docs: man:systemd-user-sessions.service(8)
$ systemctl show -p Requires,Wants,Requisite,BindsTo,PartOf,Before,After  systemd-user-sessions.service --no-pager
Requires=system.slice sysinit.target
Requisite=
Wants=
BindsTo=
PartOf=
Before=getty@tty1.service prefdm.service crond.service multi-user.target plymouth-quit-wait.service session-c2.scope display-manager-failure.service systemd-ask-password-wall.service session-c1.scope user@983.service shutdown.target user@1000.service user-983.slice user-1000.slice plymouth-quit.service
After=system.slice systemd-journald.socket remote-fs.target network.target systemd-journal-flush.service sysinit.target nss-user-lookup.target basic.target

El rastreador de errores y la información anterior parecen mostrar que el problema en realidad se debe a una falla al iniciar el daemonsystemd -user -sessions.service .

De hecho, esto es lo que sucede en mi caso, por lo que la siguiente solución corrige temporalmente la condición de inicio de sesión prohibido:

$ sudo systemctl start systemd-user-sessions.service

Después de hacer esto, el archivo/run/nologinya no está presente, y uno puede SSH desde otro sistema. Tenga en cuenta, sin embargo, que esto no es confiable ya que a veces el usuario no tiene acceso a la consola del sistema afectado.

2
27.01.2020, 20:00

Я столкнулся с точно такой же проблемой. Основная причина заключалась в том, что сервер kerberos поддерживал только тип шифрования rc4 -hmac.

решение:использование ktutil

ktutil: addent -password -p foo@bar -k 0 -e rc4-hmac
Password for foo@bar:
ktutil: wkt foo.keytab
ktutil: quit
ktinit -kt foo.keytab foo

Мне это помогло. Если это не сработает, попробуйте все разные типы шифрования по одному.

-121 ---285528 ​​-

У меня была точно такая же проблема, но я думаю, что ее могут создать несколько сценариев.

В моем случае, чтобы снова включить удаленный доступ, мне пришлось запросить KVM для прямого доступа к нашему удаленному серверу, а затем:

# 1. Start SSH service
/etc/init.d/ssh start

# 2. Remove the nologin file
rm /run/nologin

Но на экране KVM я действительно мог видеть, что он загрузился в аварийном режиме!

Раньше я вносил некоторые изменения в диск/раздел (, увеличивая индексные дескрипторы ), которые генерировали новый UUID, и забыл добавить его в файл /etc/fstab.

После подачи команды:

blkid

...и скопировав новый UUID в файл fstab, я смог снова без проблем перезагрузить сервер, и после этого удаленный доступ по SSH был в порядке.

0
27.01.2020, 20:00

В конфигурации /etc/ssh/sshd _установите для параметра UsePAM значение no

UsePAM no
0
27.01.2020, 20:00

Теги

Похожие вопросы