SSH chậm khi bắt đầu phiên

8

Bắt đầu một lớp vỏ Tương tác qua SSH là chậm đối với một trong các máy chủ của tôi. Tất cả mọi thứ dẫn đến nó bao gồm đàm phán mã hóa đều nhanh, nhưng sau đó nó bị treo trong 45 giây. Sau đó, nó kết thúc và tôi có một cái vỏ. Làm thế nào để tôi xác định những gì nó treo trên? Tôi đã cố gắng làm sạch môi trường và vô hiệu hóa tất cả chuyển tiếp trong trường hợp làm chậm nó nhưng nó không giúp ích gì. Đây là lệnh thử nghiệm của tôi:

env -i ssh -x -a -vvv server

và đây là đầu ra từ SSH:

debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug2: channel 0: send open
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
*(hangs for 45 seconds here)*
debug3: Wrote 128 bytes for a total of 3191
debug2: callback start
debug2: client_session2_setup: id 0
debug2: channel 0: request pty-req confirm 1
debug1: Sending environment.

— chim cánh cụt359
nguồn

unix.stackexchange.com/questions/10476/ Mạnh

— forcefsck

@forcefsck Tôi không nghĩ rằng bài đăng đó có liên quan. Kết nối ban đầu của tôi rất nhanh, các khóa nhận được trao đổi, xác thực nhanh, không phải chờ đợi trên một dấu nhắc mật khẩu như trong bài viết trên. Ngoài ra, tất cả DNS chuyển tiếp và đảo ngược nên được hoàn thành vào thời điểm này, tôi khá chắc chắn. Ngoài ra, vấn đề này không liên tục như trong bài viết trên, mỗi lần như vậy. Đầu ra dài dòng mà tôi đã đăng ở trên bắt đầu ngay sau khi thông báo xác thực thành công. Tôi nghĩ rằng nhiều hơn các dòng bash hoặc mô-đun phiên pam bị chậm để bắt đầu.

— chim cánh cụt359

Có một sự chậm trễ cho các phiên không tương tác là tốt? Có độ trễ khi bạn bắt đầu kết nối thứ hai trong khi kết nối đang hoạt động không? Bạn sử dụng phương pháp xác thực nào? Là thư mục nhà của bạn được tự động hóa khi đăng nhập theo một cách nào đó (từ xa hoặc được mã hóa)? Một mô-đun pam có thể là dấu vết, bạn có gì /etc/pam.d/sshd(hoặc tuy nhiên nó được gọi trên hệ thống của bạn)? Nếu bạn có quyền truy cập vào nhật ký máy chủ, có gì liên quan không?

— Gilles 'SO- ngừng trở nên xấu xa'

@Gilles Có, nó dường như ảnh hưởng đến các lệnh từ xa, scp và sftp. Nếu bạn có nghĩa là hai kết nối SSH riêng biệt, cả hai đều chậm. Nếu bạn có nghĩa là bắt đầu một phiên thứ hai thông qua cùng một ổ cắm điều khiển, tôi chỉ thử nó và nó rất nhanh, nhưng tôi nhận được một cảnh báo về sự thất bại trong việc khóa .Xmasterity. Tôi sử dụng mọi thứ từ tương tác bàn phím, khóa công khai, dựa trên máy chủ, đến gssapi-keyex. Xác thực luôn luôn nhanh bất kể, mặc dù tốc độ thay đổi một chút. Thư mục nhà của tôi là cục bộ của máy chủ và không được mã hóa. PAM về cơ bản là mặc định Ubuntu + pam_krb5.so được cài đặt.

— chim cánh cụt359

Bạn nói "chậm với một trong các máy chủ của tôi". Nó có hoạt động bình thường khi sshing với các máy khác không? Và đây là từ máy chủ của bạn, mà bạn đã đăng nhập vào địa phương? Hệ điều hành trên cục bộ và từ xa (bao gồm cả phiên bản) là gì? Ngoài ra, sshing từ máy chủ đến máy chủ của bạn có bình thường không? Liệu sshing như một người dùng khác (cả cục bộ và từ xa) có tạo ra sự khác biệt nào không?

— Faheem Mitha

6

Trong một trường hợp rất giống nhau, nó là một trong những kịch bản cập nhật.

Sau đây đã thực hiện các mẹo:

sudo rm /etc/update-motd.d/90-updates-available

Đây là một người trợ giúp nhỏ đo thời gian của mỗi tập lệnh:

$ for f in /etc/update-motd.d/*;do echo $f;time $f;done
/etc/update-motd.d/00-header            0m0.007s
/etc/update-motd.d/10-help-text         0m0.005s
/etc/update-motd.d/90-updates-available 0m49.163s
/etc/update-motd.d/91-release-upgrade   0m0.152s
/etc/update-motd.d/98-fsck-at-reboot    0m0.015s
/etc/update-motd.d/98-reboot-required   0m0.003s
(output reduced to the relevant parts)

— Daniel Alder
nguồn

Cảm ơn! Hầu hết mọi người chỉ khuyên tắt DNS, nhưng đăng nhập ssh của tôi vẫn bị chậm. Tôi bắt đầu đào sâu vào quá trình đăng nhập và câu trả lời của bạn chỉ cho tôi /etc/update-motd.d/50-landscape-sysinfo, dường như là chậm.

— Rennex

1

Điều này thực sự hữu ích - đối với tôi, kẻ giết người là 50-landscape-sysinfo. Và fyi, bạn có thể chỉ đơn giản là chmod -x /etc/update-motd.d/90-updates-availablengăn chặn nó thực thi khi đăng nhập thay vì loại bỏ nó hoàn toàn.

— billynoah

3

pam_krb5.so đã được định cấu hình để nhận mã thông báo AFS cho trình bao không tồn tại, có thời gian chờ 30 giây tạm dừng bất kỳ xác thực nào bằng mô-đun đó, không chỉ SSH. Loại bỏ điều đó và xác thực xảy ra nhanh hơn nhiều.

— chim cánh cụt359
nguồn

2

Nếu máy chủ ssh của bạn đã kích hoạt ánh xạ DNS ngược, đó có thể là nguyên nhân của sự chậm trễ, hãy tìm VerifyReverseMappingtrong /etc/ssh/sshd_configtệp của máy chủ.

— Frederik Deweerdt
nguồn

1

Tôi nghĩ rằng ánh xạ DNS ngược đã xảy ra trước khi xác thực được phép thành công, nhưng tôi sẽ kiểm tra điều đó.

— chim cánh cụt359

Tôi nghĩ bạn có nghĩa là UseDNS, tôi đã nhận được một cảnh báo không dùng nữa trên ConfirmReverseMapping. Bất kể, tôi đặt cả hai thành không và nó không giúp được gì. Tôi rất quan tâm để đảm bảo ánh xạ ngược của tôi là chính xác và máy chủ có thể ánh xạ tên máy chủ của khách hàng của tôi vào một bản ghi A và quay lại mà không gặp vấn đề gì.

— chim cánh cụt359

0

Tôi đã có cùng một vấn đề, nhưng rõ ràng gây ra bởi một cái gì đó khác. Giải pháp:

/etc/ssh/sshd_config:
#UsePAM yes

và:

sudo /etc/init.d/ssh stop;sudo /etc/init.d/ssh start;

— Ole Tange
nguồn