☰

systemd를 설치한 후 시스템이 SSH를 거부하고 "시작" 상태에서 멈춥니다.

tag-icon • tag-icon linux ssh systemd
systemd를 설치한 후 시스템이 SSH를 거부하고 "시작" 상태에서 멈춥니다.

Azure에서 생성된 Linux Ubuntu VM(14.04 LTS)에서 재현 가능한 문제가 발생했습니다.

systemd스크립트를 통해 패키지를 설치한 후 시스템은 새로운 SSH 연결을 무기한 거부합니다.

시스템이 시작되는 중입니다.

xxx.xxx.xxx.xxx에 의해 연결이 종료되었습니다.

그러나 활성 SSH 연결은 변경되지 않습니다. /etc/nologin시스템에 파일이 없습니다.

내가 볼 수 있는 유일한 옵션은 문제를 해결하기 위한 하드 리셋뿐입니다. 하지만 어떻게 피할 수 있나요?

이것은 내가 사용하는 스크립트입니다.

#!/bin/bash

# Script input arguments
user=$1
server=$2

# Tell the shell to quote your variables to be eval-safe!

printf -v user_q '%q' "$user"
printf -v server_q '%q' "$server"
#

SECONDS=0
address="$user_q"@"$server_q"

function run {
    ssh "$address" /bin/bash "$@"
}

run << SSHCONNECTION
    # Enable autostartup

        # systemd is required for the autostartup
        sudo dpkg-query -W -f='${Status}' systemd 2>/dev/null | grep -c "ok installed" > /home/$user_q/systemd-check.txt
        systemdInstalled=\$(cat /home/$user_q/systemd-check.txt)
                
        if [[ \$systemdInstalled -eq 0 ]]; then
            echo "Systemd is not currently installed. Installing..."
            
            # install systemd
            sudo apt-get update
            sudo apt-get -y install systemd

        else
            echo "systemd is already installed. Skipping this step."
        fi

SSHCONNECTION

답변1

/etc/nologinsystemd를 설치한 후에도 삭제되지 않는 파일("시스템이 시작 중입니다."라는 내용)이 있는 것 같습니다 .

[업데이트] 당신에게 영향을 미치는 것은Ubuntu의 BTS에서 보고된 버그지난 12월. 이는 시스템 설치가 끝날 때 파일이 삭제되지 않기 때문입니다 /var/run/nologin(= 심볼릭 링크이기 /run/nologin때문에 )./var/run/run

/etc/nologin표준 nologin 파일입니다. /var/run/nologinPAM 모듈에서 사용할 수 있는 대체 파일입니다 nologin(man pam_nologin).

nologin이러한 파일은 루트 사용자의 연결에 영향을 미치지 않으며 일반 사용자의 로그인만 방지한다는 점에 유의하십시오 .

답변2

@xhienne이 나에게 올바른 방향을 알려주었습니다.

파일 시스템을 검색한 후 /run/nologin(@xhienne가 /etc/nologin을 제안함) 파일을 발견하고 삭제하면 문제가 해결되었습니다.

이러한 상황은/usr/lib/tmpfiles.d/systemd.conf

내 스크립트에 이 단계를 포함하겠습니다.

sudo rm /run/nologin

답변3

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.

Mageia 릴리스 버그 추적기에 관련 문제가 열려 있는 것 같습니다. 버그 21080 - /run/nologin은 재부팅 후 SSH 로그인을 비활성화합니다..

이 문제가 자주 발생하면 추적기를 찾는 것이 단순히 추적기를 삭제하는 것보다 더 적절한 해결 방법을 결정하는 데 도움이 될 수 있습니다./실행/로그인문서.

다음은 이 버그 추적기의 정보 쿼리와 관련된 일부 데이터입니다.

$ 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=
[email protected] 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 [email protected] shutdown.target [email protected] 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

버그 추적기와 위의 정보는 문제가 실제로 시작 실패로 인해 발생했음을 나타내는 것 같습니다.systemd-usersession.service악마.

이것이 실제로 제 경우에 발생한 일이므로 다음 해결 방법으로 금지된 로그인 상황을 일시적으로 수정했습니다.

$ sudo systemctl start systemd-user-sessions.service

이 일을 한 후,/run/로그인하지 마세요파일이 더 이상 존재하지 않으며 다른 시스템에서 SSH로 연결할 수 있습니다. 그러나 때때로 사용자가 영향을 받는 시스템의 콘솔에 액세스할 수 없기 때문에 이는 신뢰할 수 없습니다.

답변4

/etc/ssh/sshd_config에서 UsePAM을 no로 설정합니다.

UsePAM no

관련 정보