Inicjacja połączenia ssh trwa wieczność, utknęła w „pledge: network”

Nawiązanie połączenia z jednym z moich serwerów za pomocą ssh trwa dłużej niż 20 sekund.

Nie jest to związane z warunkami LAN lub WAN, ponieważ połączenie z samym sobą zajmuje to samo (ssh localhost). Po ostatecznym ustanowieniu połączenia interakcja z serwerem jest bardzo szybka.

Użycie -vvv pokazuje, że połączenie jest zawieszone po powiedzeniu „pledge: network”. W tym momencie uwierzytelnianie (tutaj za pomocą klucza) jest już wykonane, jak widać tutaj:

...
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 [email protected]
debug1: Entering interactive session.
debug1: pledge: network

(... utknąłem tutaj na 15 do 25 sekund ...)

debug1: client_input_global_request: rtype [email protected] want_reply 0
debug2: callback start
debug2: fd 3 setting TCP_NODELAY
debug2: client_session2_setup: id 0
...

Serwer to Ubuntu 16.04. W przeszłości zdarzyło mi się to z innym serwerem (był Ubuntu 12.04), nerver znalazł rozwiązanie i problem zniknął po pewnym czasie ...

sshd_config jest domyślnym programem dostarczanym przez Ubuntu.

Do tej pory próbowałem:

• using -o GSSAPIAuthentication = no w komendzie ssh
• używając hasła zamiast klucza
• using UsePrivilegeSeparation no zamiast yes, w sshd_config

Jest to prawdopodobnie problem z D-Busi systemd. Jeśli z dbusjakiegoś powodu usługa zostanie ponownie uruchomiona, konieczne będzie również ponowne uruchomienie systemd-logind.

Możesz sprawdzić, czy to jest problem, otwierając dziennik demona ssh (na Ubuntu powinien być /var/log/auth.log) i sprawdź, czy ma on następujące linie:

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

Jeśli tak, po prostu uruchom ponownie systemd-logindusługę:

systemctl restart systemd-logind

Miałem ten sam problem na CentOS 7, ponieważ messagebuszostał zrestartowany (tak się D-Busnazywa usługa na CentOS).

znalazłem odpowiedź:

zmieniono UsePAM z yes na no w pliku sshd_config

Po zrestartowaniu usługi ssh połączenie jest teraz natychmiastowe do serwera. Na tym serwerze PAM jest połączony z ldap, więc prawdopodobnie jest to powód, nawet jeśli tutaj łączę się z użytkownikiem zadeklarowanym na samym serwerze, a nie LDAP.

Jest to raczej sposób na obejście problemu, a nie rozwiązanie ... Mam inne serwery skonfigurowane w ten sam sposób, w których nie występuje ten problem.

Mam nadzieję, że to może komuś pomóc ...

Stało się to na dwóch moich serwerach Fedora 25 i było to spowodowane wieloma nieudanymi próbami logowania SSH.

(Typowe sugestie dotyczące używania GSSAPIAuthentication=noi UseDNS=noponownego uruchamiania systemd-logindnie miały znaczenia).

Na tych serwerach /etc/pam.d/postloginzawiera:

session     optional      pam_lastlog.so silent noupdate showfailed

Strona pam_lastlogpodręcznika man wyjaśnia, że showfailedopcja:

Wyświetla liczbę nieudanych prób logowania i datę ostatniej nieudanej próby z btmp.

Na tych serwerach /var/log/btmppliki były ogromne z powodu wielu nieudanych prób logowania. Te btmppliki dziennika nie zostały obrócone są obaj.

Zainstalowałem logrotatepakiet, aby mieć pewność, że pliki dziennika zostaną w przyszłości obrócone. (W Fedorze konfiguracja dostarczana z logrotateobsługuje rotację /var/log/btmp.)

Usunąłem również ogromne btmppliki dziennika; jak tylko to zrobiłem, połączenie z serwerami było natychmiastowe.

W moim przypadku przyczyną była awaria rsyslogd. Dowiedziałem się tego, ponieważ nie było więcej komunikatów w dzienniku np. / Var / log / syslog lub /var/log/mail.log

Więc service rsyslog restartrozwiązaliśmy problem dla nas.

Dla mnie ten problem jest spowodowany dużym (setki MB) btmpplikiem. Ten plik rejestruje próby logowania. Gdy ludzie próbują brutalnie wymusić twoje hasło, ten plik może być duży i powodować opóźnienia w "pledge: network"fazie.

Spróbuj wyczyścić plik dziennika

echo "" > /var/log/btmp

i zobacz, czy to pomoże.

Dla mnie rozwiązaniem było dodawanie

UseDNS no

do /etc/ssh/sshd_configa potem oczywiście service ssh restart(na naszym serwerze Debian / Jessie). Nic więcej...

przed :

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

po :

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

W mojej informacji zwrotnej dotyczącej debugowania zauważyłem następujący wiersz:

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

Który był plikiem, którego właścicielem root:rootbyłam podczas gdy ja jenkins. Usunięcie tego pliku rozwiązało moje problemy.