Kết nối ssh mất mãi mãi để bắt đầu, bị mắc kẹt tại cam kết: mạng

Kết nối với một trong các máy chủ của tôi bằng ssh mất hơn 20 giây để bắt đầu.

Điều này không liên quan đến các điều kiện LAN hoặc WAN, vì kết nối với chính nó mất cùng một (ssh localhost). Sau khi kết nối cuối cùng được thiết lập, nó rất nhanh để can thiệp vào máy chủ.

Sử dụng -vvv cho thấy kết nối bị kẹt sau khi nói "cam kết: mạng". Tại thời điểm này, xác thực (ở đây sử dụng khóa) đã được thực hiện, như hiển thị ở đây:

...
debug1: Authentication succeeded (publickey).
Authenticated to myserver.mydomain.com ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network

(... bị kẹt ở đây trong 15 đến 25 giây ...)

debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...

Máy chủ là Ubuntu 16.04. Nó đã xảy ra với tôi trong quá khứ với một máy chủ khác (là Ubuntu 12.04), máy chủ đã tìm thấy giải pháp và vấn đề đã biến mất sau một thời gian ...

sshd_config là mặc định được cung cấp bởi Ubuntu.

Cho đến nay tôi đã thử:

• sử dụng -o GSSAPIAuthentication = no trong lệnh ssh
• sử dụng mật khẩu thay vì chìa khóa
• sử dụng UsePriv đặc biệt không phải trả tiền thay vì có, trong sshd_config

Đây có lẽ là một vấn đề với D-Busvà systemd. Nếu dbusdịch vụ được khởi động lại vì một số lý do, bạn cũng sẽ cần phải khởi động lại systemd-logind.

Bạn có thể kiểm tra xem đây có phải là sự cố hay không bằng cách mở nhật ký ssh daemon (trên Ubuntu /var/log/auth.log) và kiểm tra xem nó có các dòng này không:

sshd[2721]: pam_systemd(sshd:session): Failed to create session: Connection timed out

Nếu có, chỉ cần khởi động lại systemd-loginddịch vụ:

systemctl restart systemd-logind

Tôi gặp vấn đề tương tự trên CentOS 7, vì messagebusđã được khởi động lại (đó là cách D-Busdịch vụ được gọi trên CentOS).

tìm thấy câu trả lời:

đã thay đổi UsePAM từ có thành không trong tệp sshd_config

Sau khi khởi động lại dịch vụ ssh, kết nối ngay lập tức đến máy chủ. Trên máy chủ này, PAM được liên kết với ldap, vì vậy đó có thể là lý do, ngay cả khi ở đây tôi đang kết nối với người dùng được khai báo trên chính máy chủ, không phải là LDAP.

Chà, đây là một cách để vượt qua vấn đề, không thực sự là một giải pháp ... Tôi có các máy chủ khác được thiết lập giống như cách không gặp phải vấn đề này.

Hy vọng điều này có thể giúp ai đó ...

Điều này đã xảy ra trên hai trong số các máy chủ Fedora 25 của tôi và do nhiều lần thử đăng nhập SSH không thành công.

(Các đề xuất chung về sử dụng GSSAPIAuthentication=novà UseDNS=no, hoặc khởi động lại systemd-logind, không có sự khác biệt.)

Trên các máy chủ này, /etc/pam.d/postloginchứa:

session     optional      pam_lastlog.so silent noupdate showfailed

Trang hướng dẫn pam_lastloggiải thích rằng showfailedtùy chọn sẽ:

Hiển thị số lần thử đăng nhập thất bại và ngày của lần thử thất bại cuối cùng từ btmp.

Trên các máy chủ này, các /var/log/btmptệp rất lớn do nhiều lần đăng nhập thất bại. Các btmptệp nhật ký không được xoay.

Tôi đã cài đặt logrotategói để đảm bảo các tệp nhật ký sẽ được xoay trong tương lai. (Trên Fedora, cấu hình có logrotatekhả năng xoay vòng /var/log/btmp.)

Tôi cũng đã xóa các btmptệp nhật ký khổng lồ ; Ngay sau khi tôi làm điều này, kết nối với các máy chủ là ngay lập tức trở lại.

Trong trường hợp của tôi, lý do là một rsyslogd bị rơi. Tôi phát hiện ra điều này bởi vì không có nhiều thông điệp tường trình trong eg / var / log / syslog hoặc /var/log/mail.log

Vì vậy, service rsyslog restartgiải quyết vấn đề cho chúng tôi.

Đối với tôi vấn đề này là do btmptệp lớn (hàng trăm MB) . Tập tin này ghi lại những nỗ lực đăng nhập. Khi mọi người đang cố gắng ép buộc mật khẩu của bạn, tập tin này có thể lớn và gây ra sự chậm trễ trong "pledge: network"giai đoạn.

Cố gắng xóa tệp nhật ký

echo "" > /var/log/btmp

và xem nếu nó giúp.

Đối với tôi, giải pháp đã được thêm vào

UseDNS no

đến /etc/ssh/sshd_configvà sau đó dĩ nhiên service ssh restart(trên máy chủ Debian / Jessie của chúng tôi). Không có gì khác ...

trước :

ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 13.440 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 20.990 total
ssh git@git.*****.de true  0.03s user 0.02s system 0% cpu 31.114 total
ssh git@git.*****.de true  0.03s user 0.01s system 0% cpu 25.898 total

sau :

ssh git@git.*****.de true  0.03s user 0.02s system 5% cpu 0.832 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.523 total
ssh git@git.*****.de true  0.03s user 0.01s system 7% cpu 0.574 total

Tôi nhận thấy dòng sau trong phản hồi gỡ lỗi của tôi:

Control socket connect(/var/lib/jenkins/.ssh/USER@HOST:22): Permission denied

Đó là một tập tin được sở hữu root:roottrong khi tôi jenkins. Loại bỏ tập tin này giải quyết vấn đề của tôi.