Tại sao đăng nhập SSH của tôi chậm?


95

Tôi đang thấy sự chậm trễ trong Đăng nhập SSH. Cụ thể, có 2 điểm mà tôi thấy một phạm vi từ độ trễ tức thời đến độ trễ nhiều giây.

  1. Giữa việc ban hành lệnh ssh và nhận được lời nhắc đăng nhập và
  2. giữa việc nhập cụm mật khẩu và tải vỏ

Bây giờ, cụ thể là tôi đang xem chi tiết ssh chỉ ở đây. Rõ ràng độ trễ mạng, tốc độ của phần cứng và hệ điều hành liên quan, tập lệnh đăng nhập phức tạp, vv có thể gây ra sự chậm trễ. Đối với bối cảnh, tôi sử dụng vô số các bản phân phối linux và một số máy chủ Solaris sử dụng hầu hết Ubuntu, CentOS và MacOS X làm hệ thống máy khách của tôi. Hầu như mọi lúc, cấu hình máy chủ ssh không thay đổi so với cài đặt mặc định của HĐH.

Những cấu hình máy chủ ssh nào tôi nên quan tâm? Có các tham số OS / kernel có thể được điều chỉnh? Đăng nhập thủ thuật shell? Vân vân?


bạn đang sử dụng tài khoản địa phương? - đôi khi tôi thấy xác thực pam có thể thêm độ trễ khi đăng nhập bằng ssh
Sirex

Thường là tài khoản địa phương. Đôi khi NIS.
Peter Lyons

Câu trả lời:


122

Hãy thử cài đặt UseDNSthành notrong /etc/sshd_confighoặc /etc/ssh/sshd_config.


7
+1 đó là nguyên nhân phổ biến nhất của sự chậm trễ khi đăng nhập vào ssh
matthias krull

2
"Lưu ý về Solaris 11: Tôi đã thử sử dụng UseDNS không có cài đặt trên Solaris 11 và nó đã làm hỏng dịch vụ bắt đầu. Không chính xác là phản hồi thân thiện của dịch vụ. YMMV với các biến thể * Nix khác nhưng có vẻ như UseDNS không có thể là một tùy chọn hợp lệ trong Solaris 11 . " - bình luận của Keith Hoffman
Sathyajith Bhat

3
Tôi đã nghi ngờ khi tôi sử dụng để đăng nhập bằng địa chỉ IP (mạng LAN gia đình), nhưng giải pháp này đã khắc phục vấn đề của tôi. Vì lợi ích của Google, mặc dù nó đã xảy ra ngay sau đó, sự chậm trễ không liên quan gì đến thông báo "key: /home/mylogin/.ssh/id_ecdsa ((nil))" (khi chạy ssh -vvv).
Skippy le Grand Gourou

2
+1 để làm cho nó rõ ràng, các tập tin /etc/ssh/sshd_config! Tôi đã thêm vào /etc/sshd_configvà thấy không có sự khác biệt nào cả !!
vyom

1
@SkippyleGrandGourou: Một số phiên bản Solaris đang sử dụng OpenSSH được sửa đổi, được gọi là SunSSH, có một số điểm không tương thích gây phiền nhiễu. Solaris 11.3 bổ sung OpenSSH trở lại và SunSSH cuối cùng sẽ bị xóa ...
Gert van den Berg

37

Khi tôi chạy ssh -vvvtrên một máy chủ có hiệu suất chậm tương tự, tôi thấy một lỗi treo ở đây:

debug1: Next authentication method: gssapi-with-mic

Bằng cách chỉnh sửa /etc/ssh/ssh_configvà nhận xét phương thức xác thực đó, tôi đã có được hiệu suất đăng nhập trở lại bình thường. Đây là những gì tôi có trong /etc/ssh/ssh_configmáy chủ của mình:

GSSAPIAuthentication no

Bạn có thể đặt cái này trên toàn cầu trên máy chủ, vì vậy nó không chấp nhận GSSAPI để xác thực. Chỉ cần thêm GSSAPIAuthentication nođể /etc/ssh/sshd_configtrên máy chủ và khởi động lại dịch vụ.


Tôi thấy đây là trường hợp xảy ra với các máy chủ RHEL5 của tôi sau khi đăng nhập winbind / quảng cáo được định cấu hình.
Chad

Điều này làm việc cho tôi trên máy chủ Ubuntu 14.04.
Penghe Geng

Đối với CentOS 7, cần đặt cả hai GSSAPIAuthentication noUseDNS notrong /etc/ssh/sshd_configtệp.
Sunry

19

Đối với tôi, thủ phạm là độ phân giải IPv6, nó đã hết thời gian. (Tôi đoán cài đặt DNS xấu tại nhà cung cấp máy chủ của tôi.) Tôi đã phát hiện ra điều này bằng cách thực hiện ssh -v, cho biết bước nào đang bị treo.

Giải pháp là sshvới -4tùy chọn:

ssh -4 me@myserver.com


2
Tôi nghi ngờ ngày càng nhiều người trong chúng ta sẽ thấy điều này khi thời gian trôi qua và mọi thứ (rất tệ và) dần dần phù hợp với IPV6. Cảm ơn!
hiền nhân

1
... Và câu trả lời này đặc biệt không có ích nếu không có thông báo gỡ lỗi xác nhận đây là vấn đề.
EP

Theo kinh nghiệm của tôi, đây là một vấn đề rất phổ biến khi SSH đang lắng nghe trên các giao diện dualstack và điều đầu tiên tôi kiểm tra khi tôi có thể đăng nhập, nhưng mất nhiều thời gian hơn dự kiến.
Mogget

Có bất kỳ cơ hội nào chúng ta có thể sửa IPv6 thay vì mặc định thành IPv4 không?
msrd0

Đây có lẽ là lý do UseDNS không có câu trả lời hoạt động. sử dụng -vvv chỉ cho thấy nó tạm dừng debug2: resolving "thing.net.au" port 22không có lỗi, nhưng điều này không xảy ra với -4, cho thấy đó là sự cố DNS IPv6.
pmc

16

Với systemd, đăng nhập có thể bị treo trên giao tiếp dbus với logind sau một số nâng cấp, sau đó bạn cần khởi động lại logind

systemctl restart systemd-logind

Tôi thấy rằng trên debian 8, arch linx, và trên một danh sách suse


1
Ôi chà, bây giờ đó là thủ phạm! Cảm ơn nhiều!
mahatmanich

Tương tự cho tôi. Mất một lúc để loại trừ tất cả các sự cố DNS và SSH có thể xảy ra trước tiên. Lưu ý: Nếu vấn đề cũng áp dụng cho sudo chậm, hãy thử điều này trước.
Michael

Tôi vừa hoàn thành một số nâng cấp tại chỗ từ RHEL6 lên RHEL7 và nhận thấy vấn đề này. Câu trả lời này cũng đã khắc phục vấn đề của tôi.
dùng53029

cảm ơn bạn rất nhiều, nó hoạt động như một nét duyên dáng
Bảo Nam

9

Bạn luôn có thể bắt đầu sshvới -vtùy chọn hiển thị những gì đang được thực hiện tại thời điểm này.

$ ssh -v you@host

Với thông tin bạn đã cung cấp, tôi chỉ có thể đề xuất một số cấu hình phía máy khách:

  • Vì bạn viết rằng bạn đang nhập mật khẩu theo cách thủ công, tôi sẽ đề nghị bạn sử dụng xác thực khóa chung nếu có thể. Điều này loại bỏ bạn như một nút cổ chai tốc độ.

  • Bạn cũng có thể tắt chuyển tiếp X với -xvà chuyển tiếp xác thực với -a(những cái này có thể đã bị tắt theo mặc định). Đặc biệt, vô hiệu hóa chuyển tiếp X có thể giúp bạn cải thiện tốc độ lớn nếu máy khách của bạn cần khởi động máy chủ X cho sshlệnh (ví dụ: trong OS X).

Mọi thứ khác thực sự phụ thuộc vào loại chậm trễ mà bạn trải nghiệm ở đâu và khi nào.


Gợi ý tốt về tính dài dòng, bạn cũng có thể tăng nó bằng cách có nhiều v. Lên đến 3 IIRC.
vtest

7

Về điểm 2., đây là câu trả lời không yêu cầu sửa đổi máy chủ cũng như không yêu cầu phải có quyền root / quản trị.

Bạn cần chỉnh sửa tệp "user ssh_config" của mình:

vi $HOME/.ssh/config

(Lưu ý: bạn sẽ phải tạo thư mục $ HOME / .ssh nếu nó không tồn tại)

Và thêm:

Host *
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Bạn có thể làm như vậy trên cơ sở mỗi máy chủ nếu được yêu cầu :) ví dụ:

Host linux-srv
  HostName 192.158.1.1
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Đảm bảo địa chỉ IP khớp với IP máy chủ của bạn. Một lợi thế thú vị là bây giờ ssh sẽ cung cấp tự động hoàn thành cho máy chủ này. Vì vậy, bạn có thể gõ ssh lin+ Tabvà nó sẽ tự động hoàn thành ssh linux-srv.


4

Kiểm tra /etc/resolv.conftrên máy chủ để chắc chắn rằng máy chủ DNS, được liệt kê trong tệp này, hoạt động tốt và xóa mọi DNS không hoạt động.

Đôi khi nó rất hữu ích.


2

Bên cạnh các vấn đề DNS đã được đề cập, nếu bạn đang truy cập vào một máy chủ có nhiều gắn kết NFS, thì có thể có độ trễ giữa mật khẩu và lời nhắc khi quotalệnh kiểm tra mức sử dụng / hạn ngạch của bạn trên tất cả các hệ thống tệp không được gắn với noquota. Trên các hệ thống Solaris, bạn có thể thấy điều này trong mặc định /etc/profilevà bỏ qua nó bằng cách chạy touch $HOME/.hushlogin .


1

Làm việc tốt

# uname -a
SunOS oi-san-01 5.11 oi_151a3 i86pc i386 i86pc Solaris
# ssh -V
Sun_SSH_1.5, SSH protocols 1.5/2.0, OpenSSL 0x009080ff
# echo "GSSAPIAuthentication no" >> /etc/ssh/sshd_config
# echo "LookupClientHostnames no" >> /etc/ssh/sshd_config
# svcadm restart ssh

UseDNS no không hoạt động với OpenIndiana !!!

Đọc "man sshd_config" cho tất cả các tùy chọn

"Tra cứu các tên miền không" nếu máy chủ của bạn không thể giải quyết


1

Nếu không có câu trả lời nào ở trên hoạt động và bạn đang gặp phải vấn đề tra cứu ngược dns, bạn cũng có thể kiểm tra xem nscd(tên daemon bộ đệm dịch vụ) đã được cài đặt và chạy chưa.

Nếu đây là vấn đề thì đó là do bạn không có bộ đệm dns và mỗi lần bạn truy vấn tên máy chủ không có trên máy chủ lưu trữ, bạn gửi câu hỏi đến máy chủ tên của bạn thay vì tìm trong bộ đệm của bạn

Tôi đã thử tất cả các tùy chọn ở trên và thay đổi duy nhất có hiệu quả đã bắt đầu nscd.

Bạn cũng nên xác minh thứ tự để thực hiện phân giải truy vấn dns /etc/nsswitch.confđể sử dụng tệp máy chủ trước.


1

Điều này có lẽ chỉ dành riêng cho Debian / Ubuntu OpenSSH, bao gồm nhóm người dùng-mode.patch được viết bởi một trong những người duy trì gói Debian. Bản vá này cho phép các tệp ~ / .ssh có tập hợp bit có thể ghi nhóm (g + w) nếu chỉ có một người dùng có cùng gid như của tệp. Hàm Secure_permissions () của bản vá thực hiện kiểm tra này. Một trong những giai đoạn của kiểm tra là đi qua từng mục nhập passwd bằng cách sử dụng getpwent () và so sánh gid của mục nhập với gid của tệp.

Trên hệ thống có nhiều mục nhập và / hoặc xác thực NIS / LDAP chậm, kiểm tra này sẽ chậm. nscd không lưu trữ các cuộc gọi getpwent (), vì vậy mọi mục nhập mật khẩu sẽ được đọc qua mạng nếu máy chủ không cục bộ. Trên hệ thống tôi tìm thấy cái này, nó đã thêm khoảng 4 giây cho mỗi lần gọi ssh hoặc đăng nhập vào hệ thống.

Cách khắc phục là loại bỏ bit có thể ghi trên tất cả các tệp trong ~ / .ssh bằng cách thực hiện chmod g-w ~/.ssh/*.


1

Tôi thấy rằng khởi động lại systemd-logind.service chỉ khắc phục được sự cố trong vài giờ. Việc thay đổi UsePAM từ có thành không trong sshd_config đã dẫn đến đăng nhập nhanh, mặc dù motd không còn được hiển thị. Nhận xét về vấn đề bảo mật?


Tôi đã trải qua MỌI đề xuất khác ở đây và đây là điều duy nhất khắc phục sự cố trên máy chủ kích hoạt Samba4 của tôi ... CẢM ƠN!
Deven Phillips

CẢNH BÁO: 'UsePAM no' không được hỗ trợ trong Red Hat Enterprise Linux và có thể gây ra một số vấn đề.
bbaassssiiee

1

Để hoàn thành tất cả các câu trả lời cho thấy độ phân giải DNS có thể làm chậm đăng nhập ssh của bạn, đôi khi, một quy tắc tường lửa bị thiếu. Ví dụ: nếu bạn DROP tất cả các bảng INPUT theo mặc định

iptables -t filter -P INPUT DROP

sau đó bạn sẽ phải chấp nhận INPUT cho yêu cầu cổng ssh và DNS

iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT

1

ssh -vvv kết nối hoạt động rất tốt cho đến khi hệ thống treo trên hệ thống cố gắng lấy thiết bị đầu cuối trong ít nhất 20 giây:

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.
... waiting ... waiting ... waiting

Sau khi thực hiện systemctl restart systemd-logind trên máy chủ, tôi đã có kết nối lại ngay lập tức!

Đây là trên debian8 ! Vì vậy, systemd là vấn đề ở đây!

Lưu ý: Bastien Durel đã đưa ra câu trả lời cho vấn đề này, tuy nhiên nó thiếu thông tin gỡ lỗi. Tôi hy vọng điều này hữu ích cho ai đó.


Tôi đã cùng một vấn đề với "Bước vào phiên tương tác" treo trên RHEL7 (CentOS 7) và giải quyết nó bằng cách bình luận ra session [default=1] pam_lastlog.so nowtmp showfailedtrong /etc/pam.d/postlogin. Rõ ràng việc cập nhật tệp Lastlog rất chậm trên VPS OpenVZ dựa trên container của tôi.
Justin

1

Gần đây tôi đã tìm thấy một nguyên nhân khác của đăng nhập ssh chậm.

Ngay cả khi bạn đã UseDNS novào /etc/sshd_config, sshd vẫn có thể thực hiện tra cứu DNS ngược nếu /etc/hosts.denycó mục như:

nnn-nnn-nnn-nnn.rev.some.domain.com

Điều đó có thể xảy ra nếu bạn đã cài đặt Denyhost trong hệ thống của mình.

Sẽ thật tuyệt nếu ai đó biết cách làm Denyhosts tránh đưa loại hình này vào /etc/hosts.deny.

Đây là một liên kết, đến Câu hỏi thường gặp về Denyhosts , về cách xóa các mục khỏi /etc/hosts.deny- xem Làm cách nào tôi có thể xóa địa chỉ IP mà Denyhosts bị chặn?


1

Chúng tôi có thể thấy rằng phương thức phân giải tên ưa thích không phải là tệp máy chủ và sau đó là DNS.

Ví dụ, đây sẽ là cấu hình thông thường:

[root@LINUX1 ~]# cat /etc/nsswitch.conf|grep hosts
#hosts:     db files nisplus nis dns
hosts:      files dns myhostname

Đầu tiên, tập tin máy chủ được tiếp cận (tùy chọn: tập tin) và sau đó là DNS (tùy chọn: dns), tuy nhiên chúng tôi có thể thấy rằng một hệ thống phân giải tên khác đã được thêm vào không hoạt động và khiến chúng tôi chậm chạp trong việc cố gắng thực hiện độ phân giải ngược.

Nếu thứ tự phân giải tên không chính xác, bạn có thể thay đổi tại: /etc/nsswitch.conf

Trích xuất từ: http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html


1

Tôi đã thử tất cả các câu trả lời nhưng không ai trong số họ làm việc. cuối cùng tôi cũng tìm ra vấn đề của mình:

Đầu tiên tôi chạy sudo tail -f /var/log/auth.log để tôi có thể thấy nhật ký của ssh sau đó trong một phiên chạy khác ssh 172.16.111.166và nhận thấy đang chờ

/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166

Sau khi tìm kiếm, tôi tìm dòng này trong / etc / ssd / ssh_config

ProxyCommand /usr/bin/sss_ssh_knownhostsproxy -p %p %h

Tôi đã nhận xét và sự chậm trễ đã biến mất


1

Lưu ý: Điều này bắt đầu như một "Cách gỡ lỗi", hướng dẫn, nhưng cuối cùng lại là giải pháp giúp tôi trên máy chủ Ubuntu 16.04 LTS.

TLDR : Chạy landscape-sysinfovà kiểm tra xem lệnh đó có mất nhiều thời gian để hoàn thành hay không; đó là bản in thông tin hệ thống khi đăng nhập SSH mới. Lưu ý rằng lệnh này không có sẵn trên tất cả các hệ thống, landscape-commongói sẽ cài đặt nó. ("Nhưng xin chờ chút nữa...")


Khởi động máy chủ ssh thứ hai trên một cổng khác trên máy gặp sự cố, làm như vậy trong chế độ gỡ lỗi, điều này sẽ không làm cho nó rẽ nhánh và sẽ in ra các thông báo gỡ lỗi:

sudo /usr/sbin/sshd -ddd -p 44321

kết nối với máy chủ đó từ một máy khác ở chế độ dài dòng:

ssh -vvv -p 44321 username@server

Khách hàng của tôi xuất ra các dòng sau ngay trước khi bắt đầu ngủ:

debug1: Entering interactive session.
debug1: pledge: network

Googling không thực sự hữu ích, nhưng nhật ký máy chủ tốt hơn:

debug3: mm_send_keystate: Finished sending state [preauth]
debug1: monitor_read_log: child log fd closed
debug1: PAM: establishing credentials
debug3: PAM: opening session
---- Pauses here ----
debug3: PAM: sshpam_store_conv called with 1 messages
User child is on pid 28051

Tôi nhận thấy rằng khi tôi thay đổi UsePAM yesđể UsePAM nosau đó vấn đề này đã được giải quyết.

Không liên quan đến UseDNShoặc bất kỳ cài đặt nào khác, chỉ UsePAMảnh hưởng đến sự cố này trên hệ thống của tôi.

Tôi không có đầu mối tại sao, và tôi cũng không để lại UsePAMtại no, bởi vì tôi không biết được các tác dụng phụ là, nhưng điều này cho phép tôi tiếp tục điều tra.

Vì vậy, đừng coi đây là một câu trả lời, nhưng bước đầu tiên để bắt đầu tìm hiểu những gì sai.


Vì vậy, tôi tiếp tục điều tra, và chạy sshdvới strace( sudo strace /usr/sbin/sshd -ddd -p 44321). Điều này mang lại những điều sau đây:

sendto(4, "<87>Nov 20 20:35:21 sshd[2234]: "..., 110, MSG_NOSIGNAL, NULL, 0) = 110
close(5)                                = 0
stat("/etc/update-motd.d", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
umask(022)                              = 02
rt_sigaction(SIGINT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigaction(SIGQUIT, {SIG_IGN, [], SA_RESTORER, 0x7f15dce784b0}, {SIG_DFL, [], 0}, 8) = 0
rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
clone(child_stack=0, flags=CLONE_PARENT_SETTID|SIGCHLD, parent_tidptr=0x7ffde6152d2c) = 2385
wait4(2385, # BLOCKS RIGHT HERE, BEFORE THE REST IS PRINTED OUT # [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 2385

Dòng này /etc/update-motd.dlàm tôi nghi ngờ, rõ ràng quá trình chờ kết quả của những thứ trong đó/etc/update-motd.d

Vì vậy, tôi cdđã tham gia /etc/update-motd.dvà chạy một sudo chmod -x *để ức chế PAM để chạy tất cả các tệp tạo ra động này Message Of The Day, bao gồm tải hệ thống và nếu các gói cần được nâng cấp, và điều này đã giải quyết được vấn đề.

Đây là một máy chủ dựa trên CPU N3150 "tiết kiệm năng lượng", có rất nhiều việc phải làm 24/7, vì vậy tôi nghĩ rằng việc thu thập tất cả dữ liệu motd này là quá nhiều cho nó.

Tôi có thể bắt đầu kích hoạt các tập lệnh trong thư mục đó một cách chọn lọc, để xem cái nào ít gây hại hơn, nhưng gọi đặc biệt landscape-sysinfolà rất chậm và 50-landscape-sysinfogọi lệnh đó. Tôi nghĩ đó là một trong những nguyên nhân gây ra sự chậm trễ lớn nhất.

Sau khi sử dụng lại hầu hết các tập tin, tôi đã đi đến kết luận đó 50-landscape-sysinfo99-esmlà nguyên nhân cho những rắc rối của tôi. 50-landscape-sysinfomất khoảng 5 giây để thực hiện và 99-esmkhoảng 3 giây. Tất cả các tệp còn lại khoảng 2 giây hoàn toàn.

Không 50-landscape-sysinfo99-esmrất quan trọng. 50-landscape-sysinfoin ra các số liệu thống kê hệ thống thú vị (và cả nếu bạn thiếu dung lượng!) và 99-esmin ra các tin nhắn liên quan đếnUbuntu Extended Security Maintenance

Cuối cùng, bạn có thể tạo một tập lệnh với echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.shvà nhận bản in đó theo yêu cầu.


1

Chủ đề này đã cung cấp một loạt các giải pháp nhưng tôi không được đưa ra ở đây =). Vì vậy, đây là. Vấn đề của tôi (mất khoảng 1 phút để đăng nhập ssh vào raspberry pi của tôi), là do tệp .bash_history bị hỏng. Vì tệp được đọc khi đăng nhập, điều này gây ra sự chậm trễ đăng nhập. Khi tôi xóa tệp, thời gian đăng nhập trở lại bình thường, như tức thời.

Hy vọng điều này sẽ giúp một số người khác.


0

Đối với tôi, tôi cần GSSAPI và tôi không muốn tắt tra cứu DNS ngược. Điều đó dường như không phải là một ý tưởng tốt, vì vậy tôi đã kiểm tra trang chính để giải quyết. Hóa ra, một tường lửa giữa tôi và các máy chủ mà tôi đang SSH, đã can thiệp vào các yêu cầu DNS, vì chúng không ở dạng mà tường lửa mong đợi. Cuối cùng, tất cả những gì tôi cần làm là thêm dòng này vào decv.conf trên các máy chủ mà tôi đang SSH tới:

options single-request-reopenHay nói, là một tài tài của, qua, qua, qua một khác, qua giữ, qua, qua một tài khác, qua, khác qua, qua, khi khác mới mới đăng,, mới mới đăng, mới đăng, mới đăng, mới đăng, mới cam mới, mới đăng, mới đăng, mới đăng ký đăng cam


0

Đáng chú ý, một bản cập nhật gói liên kết trên CentOS 7 đã bị phá vỡ tên, hiện tại trong nhật ký rằng /etc/named.conf có vấn đề về quyền. Nó đã hoạt động tốt trong nhiều tháng với 0640. Bây giờ nó muốn 0644. Điều này có ý nghĩa vì daemon có tên thuộc về người dùng 'có tên'.

Với tất cả mọi thứ đều chậm, từ đăng nhập ssh đến phục vụ trang từ máy chủ web cục bộ, ứng dụng LAMP chậm chạp, v.v., có lẽ vì mọi yêu cầu sẽ hết thời gian trên máy chủ cục bộ đã chết trước khi tìm đến DNS thứ cấp bên ngoài được định cấu hình.


0

Đối với tôi có một vấn đề trong /etc/hoststập tin địa phương của tôi . Vì vậy, sshđã thử hai IP khác nhau (một sai) mất hết thời gian.

Sử dụng ssh -vđã lừa ở đây:

$ ssh -vvv remotesrv
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /home/mathieu/.ssh/config
debug1: /home/mathieu/.ssh/config line 60: Applying options for remotesrv
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to remotesrv [192.168.0.10] port 22.
debug1: connect to address 192.168.0.10 port 22: Connection timed out
debug1: Connecting to remotesrv [192.168.0.26] port 22.
debug1: Connection established.

Máy /etc/hostschủ?
Daniel F
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.