В моем случае подключение дисплеев и включение их перед загрузкой решило проблему. Похоже, пользовательский интерфейс просто не поддерживает горячее подключение.
Всем удачи!
Я подозреваю, что существует файл / 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, вход в систему запрещен только обычным пользователям.
@xhienne дал мне правильное направление.
После поиска в файловой системе я нашел файл / run / nologin
(@xhienne предложил / etc / nologin), удаление которого решило проблему.
Условие существовало в /usr/lib/tmpfiles.d/systemd.conf
Я включу этот шаг в свой сценарий.
sudo rm /run/nologin
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.
Я столкнулся с точно такой же проблемой. Основная причина заключалась в том, что сервер 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 был в порядке.
В конфигурации /etc/ssh/sshd _установите для параметра UsePAM значение no
UsePAM no