시스템 설치 후 시스템이 SSH를 거부하고 '부팅'에 멈춤


12

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

시스템은 걸려 , 또는 단순히 보안 쉘 데몬을 시작되지 않는 이유는 무엇입니까? 질문은 하나를 말한다; 게시물의 본문은 다른 게시물 일 수 있음을 나타냅니다.
DopeGhoti

@DopeGhoti 컴퓨터에 원격으로 연결할 수 없기 때문에 무슨 일이 일어나고 있는지 확인할 방법이 없습니다. 질문을 더 명확하게하기 위해 업데이트하겠습니다.
Alex

답변:


15

/etc/nologin시스템 설치 후 제거되지 않은 파일 (이 내용은 "시스템이 부팅 중입니다")이 의심 됩니다.

[업데이트] 당신에게 영향을주는 것은 지난 12 월 우분투의 BTS에서보고 된 버그입니다 . 그것은 인해이다 /var/run/nologin파일 (= /run/nologin이후 /var/run에 심볼릭 링크 /run)을 systemd 설치의 끝에서 제거되지 않습니다.

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

어떤 nologin파일도 사용자 루트의 연결에 영향을 미치지 않으며 일반 사용자 만 로그인 할 수 없습니다.


문제를 재현했습니다. / etc / nologin 파일이 없습니다. 활성 SSH 세션은 유지되지만 시스템을 다시 시작할 때까지 새 세션은 거부됩니다.
Alex

또한 확인 /etc/shadow
Alex

@Alex 답변이 업데이트되었습니다.
xhienne

10

@xhienne는 올바른 방향을 제시했습니다.

파일 시스템을 검색 한 후 /run/nologin(@xhienne 제안 / etc / nologin) 파일을 찾아 문제를 해결했습니다.

조건은 존재했다 /usr/lib/tmpfiles.d/systemd.conf

이 단계를 스크립트에 포함시킵니다.

sudo rm /run/nologin

다행입니다. 내 답변을 업데이트했습니다.
xhienne

2
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 배포 버그 추적기는 관련 문제가있는 것으로 보입니다 : 재부팅 후 / run / nologin에 의해 버그 21080-ssh 로그인이 비활성화되었습니다 .

이 문제가 자주 발생하면 추적 프로그램을 찾는 것이 단순히 / run / login 파일을 제거하는 것보다 더 적절한 해결 방법을 찾는 데 도움이되었습니다 .

해당 버그 추적기의 정보에 대한 쿼리와 관련된 일부 데이터는 다음과 같습니다.

$ 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

버그 추적기와 위의 정보는 문제가 실제로 systemd-user-sessions.service 데몬 을 시작하지 못했기 때문에 발생하는 것으로 보입니다 .

이것은 실제로 내 경우에 발생하므로 다음 해결 방법은 금지 된 로그인 조건을 일시적으로 수정합니다.

$ sudo systemctl start systemd-user-sessions.service

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


0

나는 똑같은 문제가 있었지만 여러 시나리오가 그것을 만들 수 있다고 생각합니다.

필자의 경우 원격 액세스를 다시 활성화하려면 원격 서버에 대한 직접 액세스를 KVM에 요청한 후 다음을 수행해야합니다.

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

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

그러나 KVM 화면에서 실제로 비상 모드로 부팅 된 것을 볼 수있었습니다!

이전에는 새로운 UUID를 생성하고 / etc / fstab 파일을 추가하는 것을 잊어 버린 디스크 / 파티션 변경 (노드 증가)을 수행했습니다.

명령을 실행 한 후 :

blkid

... 그리고 fstab 파일에 새 UUID를 붙여 넣은 후 문제없이 서버를 다시 재부팅 할 수 있었고 그 후에 원격 SSH 액세스가 가능했습니다.


0

/ etc / ssh / sshd_config에서 UsePAM을 no로 설정하십시오.

UsePAM no

이것이 무엇을하고 결과는 어떻게됩니까?
Kusalananda

이 답변은이 상황에 적용되지 않는 것 같습니다. 사용자에게 "시스템 부팅 중"텍스트가 표시되는 이유나 systemd 설치로 인해 깨진 구성이 어떻게 생성되었는지는 설명하지 않습니다.
Jeff Schaller
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.