2010-07-22 07:02:00 +0000 2010-07-22 07:02:00 +0000
103
103

Dlaczego moje logowanie SSH jest powolne?

Obserwuję opóźnienia w logowaniu SSH. Konkretnie, są 2 miejsca, w których widzę zakres od natychmiastowych do wielosekundowych opóźnień.

  1. pomiędzy wydaniem polecenia ssh a pojawieniem się monitu o zalogowanie oraz
  2. pomiędzy wprowadzeniem hasła a załadowaniem powłoki

Teraz, konkretnie patrzę tylko na szczegóły ssh. Oczywiście opóźnienia w sieci, szybkość sprzętu i zaangażowanych systemów operacyjnych, złożone skrypty logowania itp. mogą powodować opóźnienia. Dla kontekstu, ssh używam do wielu dystrybucji linuxa i kilku hostów Solarisa, używając głównie Ubuntu, CentOS i MacOS X jako systemów klienckich. Prawie przez cały czas konfiguracja serwera ssh jest niezmieniona w stosunku do domyślnych ustawień systemu operacyjnego.

Jakie konfiguracje serwera ssh powinny mnie interesować? Czy istnieją parametry OS/kernela, które można dostroić? Sztuczki powłoki logowania? Etc?

Odpowiedzi (22)

130
130
130
2010-07-22 08:38:59 +0000

Spróbuj ustawić UseDNS na no w /etc/sshd_config lub /etc/ssh/sshd_config.

39
39
39
2010-09-22 17:42:34 +0000

Kiedy uruchomiłem ssh -vvv na serwerze z podobną, wolną wydajnością, zobaczyłem, że tutaj się zawiesza:

debug1: Next authentication method: gssapi-with-mic

Edytując /etc/ssh/ssh_config i wykomentowując tę metodę uwierzytelniania sprawiłem, że wydajność logowania wróciła do normy. Oto co mam w moim /etc/ssh/ssh_config na serwerze:

GSSAPIAuthentication no

Możesz ustawić to globalnie na serwerze, więc nie akceptuje GSSAPI do uwierzytelniania. Wystarczy dodać GSSAPIAuthentication no do /etc/ssh/sshd_config na serwerze i zrestartować usługę.

21
21
21
2015-08-14 00:50:20 +0000

Dla mnie, winowajcą była rozdzielczość IPv6, kończyły się czasy. (Złe ustawienie DNS u mojego dostawcy hosta, jak sądzę.) Odkryłem to wykonując ssh -v, co pokazało, który krok się zawiesił.

Rozwiązaniem jest ssh z opcją -4:

ssh -4 me@myserver.com.

16
16
16
2015-05-21 09:41:03 +0000

Z systemd, logowanie może zawiesić się na komunikacji dbus z logind po niektórych aktualizacjach, wtedy trzeba zrestartować logind

systemctl restart systemd-logind

Saw, że na debian 8, arch linx, i na liście suse

9
9
9
2010-07-22 08:28:05 +0000

Zawsze możesz uruchomić ssh z opcją -v, która wyświetla, co jest aktualnie wykonywane.

$ ssh -v you@host

Z podanych przez Ciebie informacji mogę jedynie zasugerować pewne konfiguracje po stronie klienta:

  • Ponieważ piszesz, że wprowadzasz hasła ręcznie, sugerowałbym, abyś używał uwierzytelniania kluczem publicznym, jeśli to możliwe. To usunie cię jako wąskie gardło prędkości.

  • Mógłbyś również wyłączyć X-forwarding za pomocą -x i authentication forwarding za pomocą -a (mogą one być już domyślnie wyłączone). Szczególnie wyłączenie X-forwarding może dać Ci dużą poprawę szybkości, jeśli Twój klient musi uruchomić serwer X dla komendy ssh (np. pod OS X).

Wszystko inne zależy od tego, jakie opóźnienia występują gdzie i kiedy.

7
7
7
2012-06-29 07:41:22 +0000

Jeśli chodzi o punkt 2, oto odpowiedź, która nie wymaga modyfikacji serwera ani posiadania uprawnień roota/administratora.

Musisz edytować swój plik “user ssh_config”, który jest:

vi $HOME/.ssh/config

(Uwaga: musiałbyś utworzyć katalog $HOME/.ssh jeśli nie istnieje)

I dodać:

Host *
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Możesz to zrobić na podstawie każdego hosta, jeśli jest to wymagane :) przykład:

Host linux-srv
  HostName 192.158.1.1
  GSSAPIAuthentication no
  GSSAPIDelegateCredentials yes

Upewnij się, że adres IP pasuje do IP twojego serwera. Jedną fajną zaletą jest to, że teraz ssh będzie dostarczał autocomplete dla tego serwera. Możesz więc wpisać ssh lin + Tab i powinno się to automatycznie uzupełnić do ssh linux-srv.

4
4
4
2017-06-08 07:57:20 +0000

Sprawdź /etc/resolv.conf na serwerze, aby upewnić się, że serwer DNS, wymieniony w tym pliku, działa ok, i usuń wszystkie niedziałające DNS.

Czasami jest to bardzo pomocne.

2
2
2
2010-07-22 14:24:59 +0000

Oprócz wspomnianych już problemów z DNS, jeśli ssh'ujesz do serwera z wieloma zamontowanymi NFS, może wystąpić opóźnienie między hasłem a monitem, ponieważ polecenie quota sprawdza użycie/kwotę na wszystkich systemach plików nie zamontowanych za pomocą noquota. W systemach Solaris, możesz to zobaczyć w domyślnym /etc/profile i pominąć je uruchamiając touch $HOME/.hushlogin .

1
1
1
2013-05-02 23:01:07 +0000

Jeśli żadna z powyższych odpowiedzi nie działa i masz problemy z dns reverse lookup, możesz również sprawdzić czy nscd (name service cache daemon) jest zainstalowany i uruchomiony.

Jeśli to jest problem to dlatego, że nie masz pamięci podręcznej dns, i za każdym razem, gdy pytasz o nazwę hosta, której nie ma w twoim pliku hosta, wysyłasz zapytanie do twojego serwera nazw zamiast szukać w pamięci podręcznej

Próbowałem wszystkich powyższych opcji i jedyną zmianą, która zadziałała było uruchomienie nscd.

Powinieneś również zweryfikować kolejność wykonywania rozdzielczości zapytań dns w /etc/nsswitch.conf, aby najpierw użyć pliku hosts.

1
1
1
2015-10-13 01:19:43 +0000

Jest to prawdopodobnie specyficzne tylko dla OpenSSH Debiana/Ubuntu, który zawiera user-group-modes.patch napisany przez jednego z opiekunów pakietu Debiana. Łata ta pozwala plikom ~/.ssh mieć ustawiony bit group writable (g+w), jeśli jest tylko jeden użytkownik z takim samym gid jak ten w pliku. Funkcja secure_permissions() zawarta w łatce dokonuje tego sprawdzenia. Jednym z etapów sprawdzania jest przejście przez każdy wpis passwd przy użyciu getpwent() i porównanie gid wpisu z gid pliku.

W systemie z wieloma wpisami i/lub powolną autentykacją NIS/LDAP, to sprawdzenie będzie powolne. nscd nie buforuje wywołań getpwent(), więc każdy wpis passwd będzie odczytywany przez sieć, jeśli serwer nie jest lokalny. W systemie, w którym to znalazłem, dodawało to około 4 sekund dla każdego wywołania ssh lub logowania do systemu.

Poprawką jest usunięcie bitu zapisu na wszystkich plikach w ~/.ssh przez wykonanie chmod g-w ~/.ssh/*.

1
1
1
2018-11-20 19:15:56 +0000

Uwaga: To zaczęło się jako “Jak debugować”, samouczek, ale skończyło się na rozwiązaniu, które pomogło mi na serwerze Ubuntu 16.04 LTS.

TLDR : Uruchom landscape-sysinfo i sprawdź, czy to polecenie długo się kończy; jest to wydruk informacji systemowych przy nowym logowaniu SSH. Zauważ, że ta komenda nie jest dostępna na wszystkich systemach, pakiet landscape-common ją instaluje. (“But wait, there’s more…”)


Uruchom drugi serwer ssh na innym porcie na maszynie, która ma problem, zrób to w trybie debug, co nie spowoduje jego rozwidlenia i wydrukuje komunikaty debug:

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

Połącz się z tym serwerem z innej maszyny w trybie verbose:

ssh -vvv -p 44321 username@server

Mój klient wypisuje następujące linie tuż przed rozpoczęciem snu:

debug1: Entering interactive session.
debug1: pledge: network

Googlowanie tego nie jest zbyt pomocne, ale logi serwera są lepsze:

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

Zauważyłem, że gdy zmienię UsePAM yes na UsePAM no wtedy ten problem zostaje rozwiązany.

Nie jest to związane z UseDNS lub jakimkolwiek innym ustawieniem, tylko UsePAM ma wpływ na ten problem w moim systemie.

Nie mam pojęcia dlaczego, a także nie zostawiam UsePAM na no, ponieważ nie wiem, jakie są skutki uboczne, ale to pozwala mi kontynuować badania.

Więc proszę nie traktuj tego jako odpowiedzi, ale jako pierwszy krok do rozpoczęcia poszukiwania tego, co jest nie tak.


Więc kontynuowałem dochodzenie i uruchomiłem sshd z strace (sudo strace /usr/sbin/sshd -ddd -p 44321). Dało to następujące wyniki:

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

Linia /etc/update-motd.d wzbudziła moje podejrzenia, najwyraźniej proces czeka na wynik rzeczy, które znajdują się w /etc/update-motd.d

Tak więc cd‘d do /etc/update-motd.d i uruchomiłem sudo chmod -x * w celu zablokowania PAM do uruchomienia wszystkich plików, które generują to dynamiczne Message Of The Day, co obejmuje obciążenie systemu i jeśli pakiety wymagają aktualizacji, a to rozwiązało problem.

Jest to serwer oparty na “energooszczędnym” procesorze N3150, który ma dużo pracy 24/7, więc myślę, że zbieranie tych wszystkich danych motd było dla niego po prostu zbyt dużym obciążeniem.

Może zacznę selektywnie włączać skrypty w tym folderze, aby zobaczyć, które są mniej szkodliwe, ale specjalnie wywoływanie landscape-sysinfo jest bardzo powolne, a 50-landscape-sysinfo wywołuje tę komendę. Myślę, że to właśnie ona powoduje największe opóźnienia.

Po ponownym włączeniu większości plików doszedłem do wniosku, że50-landscape-sysinfo i 99-esm były przyczyną moich kłopotów. 50-landscape-sysinfo potrzebował około 5 sekund na wykonanie, a 99-esm około 3 sekund. Wszystkie pozostałe pliki około 2 sekund łącznie.

Ani 50-landscape-sysinfo, ani 99-esm nie są kluczowe. 50-landscape-sysinfo wypisuje interesujące statystyki systemowe (a także jeśli masz mało miejsca!), a 99-esm wypisuje komunikaty związane z Ubuntu Extended Security Maintenance

W końcu możesz stworzyć skrypt z echo '/usr/bin/landscape-sysinfo' > info.sh && chmod +x info.sh i uzyskać ten wydruk na żądanie.

1
1
1
2017-07-22 08:21:56 +0000

Próbowałem wszystkich odpowiedzi, ale żadna z nich nie działała. w końcu znalazłem mój problem:

najpierw uruchomiłem sudo tail -f /var/log/auth.log żeby zobaczyć log ssh potem w innej sesji uruchomiłem ssh 172.16.111.166 i zauważyłem oczekiwanie na

/usr/bin/sss_ssh_knownhostsproxy -p 22 172.16.111.166

po poszukiwaniach znalazłem tę linię w /etc/ssd/ssh_config

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

zakomentowałem ją i opóźnienie zniknęło

1
1
1
2012-04-25 13:37:42 +0000

Działa dobrze.

# 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 nie działa z OpenIndiana !!!

Przeczytaj “man sshd_config” dla wszystkich opcji

“LookupClientHostnames no” jeśli twój serwer nie może rozwiązać

1
1
1
2017-03-04 22:38:38 +0000

ssh -vvv połączenie poszło naprawdę dobrze, dopóki nie zawiesiło się na systemie próbując uzyskać terminal przez co najmniej 20 sekund:

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

Po wykonaniu systemctl restart systemd-logind na serwerze znów miałem natychmiastowe połączenie!

To było na debian8! Więc systemd był tutaj problemem!

Uwaga: Bastien Durel dał już odpowiedź na ten problem, jednak brakuje w niej informacji o debugowaniu. Mam nadzieję, że to jest pomocne dla kogoś.

1
1
1
2017-07-09 09:12:53 +0000

Może się okazać, że preferowaną metodą rozwiązywania nazw nie jest plik hosta, a następnie DNS.

Na przykład, tak wyglądałaby zwykła konfiguracja:

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

Najpierw sięga się do pliku hosts (opcja: files), a następnie do DNS (opcja: dns), jednak może się okazać, że został dodany inny system rozwiązywania nazw, który nie działa i powoduje, że mamy powolność w próbie wykonania odwrotnej rozdzielczości.

Jeśli kolejność rozwiązywania nazw nie jest poprawna, można ją zmienić pod adresem: /etc/nsswitch.conf

Extracted from: http://www.sysadmit.com/2017/07/linux-ssh-login-lento.html

1
1
1
2018-01-03 15:02:47 +0000

Ten wątek już dostarcza garść rozwiązań, ale moje nie jest tu podane =). Więc oto jest. Mój problem (zajął około 1 minuty, aby zalogować się ssh do mojego raspberry pi), był spowodowany uszkodzonym plikiem .bash_history. Ponieważ plik ten jest odczytywany przy logowaniu, powodowało to opóźnienie w logowaniu. Kiedy usunąłem plik, czas logowania wrócił do normy, jakby natychmiastowy.

Mam nadzieję, że to pomoże innym osobom.

1
1
1
2016-12-06 09:24:08 +0000

Aby uzupełnić wszystkie odpowiedzi pokazujące, że rozdzielczości DNS mogą spowolnić logowanie ssh, czasami brakuje reguł firewalla. Na przykład, jeśli domyślnie DROPujesz wszystkie pakiety INPUT

iptables -t filter -P INPUT DROP

to będziesz musiał zaakceptować INPUT dla portu ssh i żądania DNS

iptables -t filter -A INPUT -p tcp --dport 53 -j ACCEPT
iptables -t filter -A INPUT -p udp --dport 53 -j ACCEPT
```.
1
1
1
2016-10-24 21:49:02 +0000

Ostatnio znalazłem kolejną przyczynę powolnego logowania się do ssh.

Nawet jeśli masz UseDNS no w /etc/sshd_config, sshd może nadal wykonywać odwrotne przeszukiwanie DNS, jeśli /etc/hosts.deny ma wpis taki jak:

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

To może się zdarzyć, jeśli masz zainstalowane w systemie DenyHosts .

Byłoby wspaniale, gdyby ktoś wiedział, jak sprawić, by DenyHosts unikał umieszczania tego typu wpisów w /etc/hosts.deny.

Tutaj jest link do DenyHosts FAQ , jak usunąć wpisy z /etc/hosts.deny - zobacz Jak mogę usunąć adres IP, który zablokował DenyHosts? .

1
1
1
2016-07-13 22:35:37 +0000

Stwierdziłem, że ponowne uruchomienie systemd-logind.service wyleczyło problem tylko na kilka godzin. Zmiana UsePAM z yes na no w sshd_config zaowocowała szybkim logowaniem, chociaż motd nie jest już wyświetlane. Komentarze dotyczące kwestii bezpieczeństwa?

0
0
0
2015-05-21 13:01:07 +0000

Dla mnie był problem w moim lokalnym pliku /etc/hosts. Tak więc ssh próbował dwóch różnych IP (jeden zły), co trwało wieki, aby zakończyć czas.

Użycie ssh -v załatwiło sprawę:

$ 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.
```.
0
0
0
2014-08-28 11:41:40 +0000

Dla mnie potrzebowałem GSSAPI, i nie chciałem wyłączać odwrotnego DNS lookups. To po prostu nie wydawało się dobrym pomysłem, więc sprawdziłem główną stronę resolv.conf. Okazało się, że firewall pomiędzy mną a serwerami, do których się łączyłem SSH, zakłócał żądania DNS, ponieważ nie były one w takiej formie, jakiej oczekiwał firewall. W końcu, wszystko co musiałem zrobić to dodać tą linijkę do resolv.conf na serwerach, do których się łączyłem SSH:

options single-request-reopen

0
0
0
2016-12-13 17:07:11 +0000

Co ciekawe, aktualizacja pakietu bind na CentOS 7 zepsuła named, stwierdzając w logu, że /etc/named.conf ma problem z uprawnieniami. Działał dobrze przez miesiące z 0640. Teraz chce 0644. Ma to sens, ponieważ nazwany demon należy do ‘nazwanego’ użytkownika.

Z wyłączonym named wszystko było powolne, od logowań ssh do serwowania stron z lokalnego serwera WWW, ślamazarnych aplikacji LAMP itp., najprawdopodobniej dlatego, że każde żądanie kończyłoby się na martwym lokalnym serwerze, zanim spojrzałoby w górę na zewnętrzny, drugorzędny DNS, który jest skonfigurowany.