Hệ thống từ chối SSH và bị kẹt khi 'khởi động' sau khi cài đặt systemd


12

Tôi có một vấn đề có thể tái tạo trên máy ảo Linux Ubuntu (14.04 LTS) được tạo trong Azure.

Sau khi cài đặt systemdgói thông qua tập lệnh, hệ thống từ chối các kết nối ssh mới, vô hạn.

Hệ thống đang khởi động lên.

Kết nối được đóng bởi xxx.xxx.xxx.xxx

Kết nối ssh hoạt động được duy trì mặc dù. Không có /etc/nologintập tin hiện diện trong hệ thống.

Tùy chọn duy nhất tôi thấy là thiết lập lại cứng giúp giải quyết vấn đề. Nhưng làm thế nào để tôi tránh nó?

Đây là kịch bản tôi đang sử dụng:

#!/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

Là hệ thống treo , hoặc đơn giản là nó không khởi động trình nền shell an toàn? Câu hỏi nêu một; cơ thể của bài viết ngụ ý rằng nó cũng có thể là người khác.
DopeGhoti

@DopeGhoti Không có cách nào để tôi kiểm tra những gì đang diễn ra vì tôi không thể kết nối với máy từ xa. Tôi sẽ cập nhật câu hỏi để làm cho nó rõ ràng hơn.
Alex

Câu trả lời:


15

Tôi nghi ngờ có một /etc/nologintệp (có nội dung là "Hệ thống đang khởi động.") Không bị xóa sau khi cài đặt systemd.

[cập nhật] Điều ảnh hưởng đến bạn là một lỗi đã được báo cáo trên trạm BTS của Ubuntu vào tháng 12 năm ngoái. Đó là do một /var/run/nologintệp (= /run/nologin/var/runlà một liên kết tượng trưng /run) không bị xóa khi kết thúc cài đặt systemd.

/etc/nologinlà tệp nologin tiêu chuẩn. /var/run/nologinlà một tệp thay thế có thể được sử dụng bởi nologinmô-đun PAM ( man pam_nologin).

Lưu ý rằng không có nologintệp nào ảnh hưởng đến kết nối bởi người dùng root, chỉ người dùng thông thường mới bị chặn đăng nhập.


Tôi đã sao chép vấn đề này, không có tập tin / etc / nologin nào. Phiên SSH hoạt động được duy trì, tuy nhiên phiên bản mới bị từ chối cho đến khi tôi khởi động lại máy.
Alex

Tôi cũng đã kiểm tra /etc/shadowvà tài khoản không bị khóa
Alex

@Alex Trả lời cập nhật.
xhienne

10

@xhienne đã cho tôi hướng đi đúng đắn.

Sau khi tìm kiếm thông qua hệ thống tệp, tôi tìm thấy tệp /run/nologin(@xhienne đề xuất / etc / nologin), loại bỏ giải quyết vấn đề.

Điều kiện tồn tại trong /usr/lib/tmpfiles.d/systemd.conf

Tôi sẽ bao gồm bước này trong kịch bản của tôi.

sudo rm /run/nologin

Vui mừng nó hoạt động. Tôi đã cập nhật câu trả lời của tôi.
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.

Trình theo dõi lỗi phân phối Mageia dường như có một vấn đề liên quan mở: Bug 21080 - đăng nhập ssh bị vô hiệu hóa bởi / run / nologin sau khi khởi động lại .

Sau khi gặp vấn đề này khá thường xuyên, việc tìm kiếm trình theo dõi đã giúp xác định một cách giải quyết có thể phù hợp hơn là chỉ cần xóa tệp / run / đăng nhập .

Dưới đây là một số dữ liệu liên quan đến truy vấn thông tin trong trình theo dõi lỗi đó:

$ 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

Trình theo dõi lỗi và thông tin ở trên dường như cho thấy rằng sự cố thực sự là do lỗi khởi động trình nền systemd-user- session.service.

Thực tế đây là những gì xảy ra trong trường hợp của tôi, vì vậy cách giải quyết sau đây tạm thời sửa chữa điều kiện đăng nhập bị cấm:

$ sudo systemctl start systemd-user-sessions.service

Sau khi thực hiện việc này, tệp / run / nologin không còn nữa và người ta có thể SSH từ một hệ thống khác. Tuy nhiên, lưu ý rằng điều này không đáng tin cậy vì đôi khi người dùng không có quyền truy cập vào bảng điều khiển của hệ thống bị ảnh hưởng.


0

Tôi đã có vấn đề chính xác tương tự nhưng tôi nghĩ một số kịch bản có thể tạo ra nó.

Trong trường hợp của tôi, để cho phép truy cập lại từ xa, tôi đã phải yêu cầu KVM truy cập trực tiếp vào máy chủ từ xa của chúng tôi và sau đó:

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

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

Nhưng ở màn hình KVM tôi thực sự có thể thấy rằng nó đã khởi động vào chế độ khẩn cấp!

Trước đây, tôi đã thực hiện một số thay đổi đĩa / phân vùng (tăng inodes) tạo ra UUID mới và quên thêm tệp / etc / fstab.

Sau khi ban hành lệnh:

blkid

... và sao chép dán UUID mới trên tệp fstab, tôi đã có thể khởi động lại máy chủ một lần nữa mà không gặp vấn đề gì và truy cập SSH từ xa vẫn ổn sau đó.


0

Trong / etc / ssh / sshd_config, đặt UsePAM thành không

UsePAM no

Điều này sẽ làm gì và hậu quả sẽ là gì?
Kusalananda

Câu trả lời này dường như không áp dụng cho tình huống này-- nó không giải thích lý do tại sao người dùng thấy văn bản "Hệ thống đang khởi động" hoặc giải thích cách cài đặt systemd tạo ra cấu hình bị hỏng.
Jeff Schaller
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.