Thời gian chờ đợi khi đăng nhập

Khi tôi đăng nhập vào máy chủ của mình, tôi nhận được điều này:

No mail.
Last login: Fri Nov  5 14:22:45 2010...

sau đó tôi phải đợi trong 5 giây và sau đó sẵn sàng ...

wolfy@ubuntu-server:~$

Đây là thời gian chờ đợi bình thường hay tôi nên làm gì đó để "sửa chữa" điều này?

Đây thường là kết quả của việc pam_motdtạo lại /etc/motdtập tin. Bạn có thể kiểm tra các tập lệnh riêng lẻ /etc/update-motd.dđể xem có gì đặc biệt chậm không.

Tôi có cùng các vấn đề với 10.04 (LTS).

Khi tôi chạy ssh của tôi với -vvv, nó chết tại:

debug1: Entering interactive session.

Mở rộng câu trả lời này.

Tôi đã quản lý để khởi động lại máy chủ từ xa và kích hoạt đăng nhập DEBUG. Cũng sử dụng cơ hội này để duy trì đăng nhập và quan sát các nỗ lực đăng nhập khác. Đây là những gì xảy ra. Máy khách kết nối và được ủy quyền và treo ở thông báo trên.

Trên máy chủ, danh sách quy trình hiển thị điều này:

root       835  0.0  0.1  11476  3348 ?        Ss   13:39   0:00 sshd: till [priv]
root       840  0.0  0.0   4804  1124 ?        S    13:39   0:00 /bin/sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/run-parts --lsbsysinit /etc/update-motd.d
root       841  0.0  0.0   4728  1108 ?        S    13:39   0:00 /bin/run-parts --lsbsysinit /etc/update-motd.d
root       854  0.0  0.0   4804  1144 ?        S    13:39   0:00 /bin/sh /etc/update-motd.d/50-landscape-sysinfo
root       861  0.2  0.5  15388  9248 ?        S    13:39   0:00 /usr/bin/python /usr/bin/landscape-sysinfo
root       863  0.0  0.0      0     0 ?        Z    13:39   0:00 [who] <defunct>

Tôi có thể thực thi /usr/bin/python /usr/bin/landscape-sysinfotốt trong khi đăng nhập, nhưng vì một số lý do, tôi không thể hiểu tại sao nó lại trì hoãn quá trình đăng nhập. Khi tôi giết tiến trình, đăng nhập tiếp tục đến dấu nhắc và thành công .

Đây dường như không phải là một vấn đề ssh (d), nó liên quan nhiều hơn đến update-motdphong cảnh. Tôi đã gỡ cài đặt update-motdgói, nhưng có vẻ như /etc/update-motdthư mục vẫn tồn tại và các tập lệnh vẫn được thực thi - khiến quá trình bị treo.

Gỡ lỗi này hơn nữa:

Hóa ra /etc/update-motd.d/thư mục không thực sự thuộc về gói update-motd, nó dường như được kích hoạt bởi xác thực pam thông qua sshd.

Tôi dường như đã đóng đinh nó!

Vô hiệu hóa pam_motd trong các tệp sau:

• /etc/pam.d/sshd
• /etc/pam.d/login

Một lần nữa:

apt-get purge landscape-client landscape-common

Những điều này dường như để giúp mở rộng nhất định. Mặc dù vậy, nó chỉ loại bỏ tập lệnh vi phạm trong /etc/update-motd.d/và không xóa tất cả các tập lệnh trong thư mục đó và cũng không bị loại bỏ pam_motd.

Nói chung, tôi không tìm thấy cách nào để vô hiệu hóa pam_motdhoàn toàn bởi vì dường như, bất kể nó làm gì - nó làm chậm quá trình đăng nhập đến một phần mở rộng nhất định. Nó không chặn như kịch bản trong landscape-common, nhưng chậm hơn.

Báo cáo lỗi về vấn đề này:

• https://bugs.launchpad.net/ubfox/+source/pam/+orms/805423

Cách giải quyết từ đó:

Bạn đúng rằng khả năng đăng nhập quan trọng hơn là trình bày một motd. Nếu hành vi này là một vấn đề đối với bạn, có một số cách bạn có thể vô hiệu hóa nó:

• nhận xét dòng 'pam_motd' /etc/pam.d/sshdnếu bạn không muốn hiển thị một mô-đun.
• xóa nội dung của /etc/update-motd.dthư mục.
• chmod -x các tập lệnh /etc/update-motd.dmà bạn không muốn chạy.

Tìm thấy giải pháp cuối cùng:

1. sudo apt-get remove landscape-client landscape-common
2. dòng bình luận session optional pam_motd.so trong /etc/pam.d/loginvà/etc/pam.d/sshd

Bây giờ đăng nhập là NGAY LẬP TỨC!

Từ mô tả của bạn, nó có vẻ giống như một vấn đề mạng. Để chẩn đoán:

• Chạy ssh với tham số -v để dài dòng.
• Hãy thử chạy ping đến máy chủ SSH mà bạn đang kết nối và xem điều này có bị treo cùng lúc không.
• Hãy thử một số loại chuyển khác đến cùng một máy chủ. Chẳng hạn, wget với tham số --limit-Rate để tìm nạp tệp qua HTTP và phải mất đủ thời gian để nó có thể kích hoạt hành vi "treo".
• Xem liệu nó chỉ bị treo khi không hoạt động, hoặc ngay cả khi bạn đang làm gì đó vào lúc này. Nếu nó bị treo khi không hoạt động, chẩn đoán -v có thể sẽ cho bạn biết như vậy, trong trường hợp đó, lời khuyên sử dụng keepalive có thể giúp ích (ssh -o "TCPKeepAlive yes")

Nếu bạn có thể kết nối OK với Windows và PuTTY, có lẽ đó không phải là vấn đề ở phía máy chủ.

Nếu PermitEmptyPasswordvà UsePAMcả hai đều được bật, máy chủ OpenSSH luôn cố gắng xác thực bằng mật khẩu null, đây là dấu hiệu cho thấy không cần xác thực cho tài khoản được đề cập. Nó thực hiện điều này ngay khi quá trình xác thực bắt đầu, trong cả hai giao thức và không đáp ứng bất kỳ yêu cầu xác thực "thực" nào từ máy khách. OpenSSH sẽ chỉ cho phép truy cập như vậy nếu cờ sshd_config PermitEmptyPasswordđược đặt; Thật không may, cách viết mã, nó thực hiện kiểm tra mật khẩu trong mọi trường hợp và do đó hiển thị PAM là một lỗi.

Vì vậy: vô hiệu hóa PermitEmptyPasswordhoặc UsePAM, nhưng hãy nhớ: không có PAM, bạn sẽ không thể đăng nhập mà không cần khóa.

Tham khảo: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c

Tôi nghĩ rằng khi bạn đăng nhập, Ubuntu sẽ thực thi một hoặc nhiều tệp trong số này:

/etc/bash.bashrc
~/.bash_profile
~/.bashrc

Bạn có thể thấy những gì trong đó và thậm chí có thể thử thực hiện chúng để xem những gì mất quá nhiều thời gian.

Theo kinh nghiệm hạn chế của tôi, khi putty hoạt động, nhưng Linux, Ubuntu trong trường hợp này thì không, nó thường được duy trì. Sự cố mạng hoặc máy chủ sẽ ảnh hưởng đến cả hệ điều hành máy khách.

Bạn có thể sử dụng tùy chọn giữ trực tiếp ở trên dòng lệnh, nhưng nó khá tẻ nhạt khi gõ.

Dễ dàng chỉnh sửa một vài tập tin cấu hình.

Nếu bạn có root accessvà muốn bật nó tự động cho tất cả người dùng, hãy chỉnh sửa /etc/ssh/ssh_config, thêm

KeepAlive yes
ServerAliveInterval 120

Nếu bạn không có quyền truy cập root hoặc để kích hoạt nó cho một người dùng, hãy chỉnh sửa ~/.ssh/configvà thêm hai dòng giống nhau.

Kiểm tra nhật ký hệ thống của bạn tại / var / log, bạn có thể tìm thấy một thông báo có lỗi / thời gian chờ liên quan.

Nếu bạn cũng có một thời gian chờ đợi trước

Chỉnh sửa /etc/sshd_config

và đặt (hoặc thêm)

UseDNS no

hoặc thêm ip của bạn vào /etc/hostsnếu nó là cục bộ tĩnh

Bạn có thể muốn theo dõi các quy trình đang chạy trong khi bạn đăng nhập vào máy chủ từ một kết nối đã đăng nhập (hoặc một bảng điều khiển khác). Có một cơ hội để phát hiện ra các quá trình nào hoạt động mạnh nhất hoặc sử dụng nhiều CPU nhất tại thời điểm đó.

Dưới đây là một phương pháp có thể:

1. Hãy thử đăng nhập vào một giao diện điều khiển khác.
2. Chạy topđến đó để xem những gì xảy ra.
3. Đăng nhập vào giao diện điều khiển 1.

Xin lưu ý rằng nếu độ trễ không phải do một số tính toán thâm dụng CPU gây ra, bạn sẽ không phát hiện ra bất cứ điều gì ngoài vị trí. Trong trường hợp này, sự cố có thể bị ràng buộc I / O (chờ một số lần đọc / ghi đĩa hoặc phản hồi mạng).