połączenie z serwerem ssh trwa zbyt długo

Mam dwie maszyny wirtualne z ( arch linuxi debiandziała pod virtual box). Niedawno połączenie z archmaszyną wirtualną zajęło dużo czasu ssh. Po raz pierwszy kolejne próby następują szybko. Oto, co widzę na archmaszynie wirtualnej:

debug1: userauth-request for user yuri service ssh-connection method none
debug1: attempt 0 failures 0
debug3: Trying to reverse map address 10.0.2.2.
# ^^^ spends a lot of time after this line
debug2: parse_server_config: config reprocess config len 314
debug2: input_userauth_request: setting up authctxt for yuri
debug1: PAM: initializing for "yuri"
debug1: PAM: setting PAM_RHOST to "10.0.2.2"
debug1: PAM: setting PAM_TTY to "ssh"
debug2: input_userauth_request: try method none
Failed none for yuri from 10.0.2.2 port 35786 ssh2

10.0.2.2jest domyślną bramą dla maszyn wirtualnych. Co to wszystko znaczy?

PS Oto dobra odpowiedź , dzięki której mogłem poczynić pewne postępy w badaniu problemu.

Domyślam się, że problemem są limity czasu żądań DNS. Spróbuj ... wyłączyć opcję UseDNS na serwerze, z którym się łączysz.

Dziennik serwera prawie to potwierdził (tak dobrze zrobione, że go opublikowałem :).

debug3: Trying to reverse map address 10.0.2.2.
# ^^^ spends a lot of time after this line

Patrząc na man sshd_config:

 UseDNS  Specifies whether sshd(8) should look up the remote host name and
         check that the resolved host name for the remote IP address maps
         back to the very same IP address.  The default is “yes”.

Zauważ, że jest to prawie bezcelowe . Czek nie zabija połączenia. Jeśli nie przejdzie, po prostu rejestruje machanie palcem:

9 lipca 05:43:00 cegła sshd [18971]: Adres 200.41.233.234 jest mapowany na host234.advance.com.ar, ale to nie mapuje z powrotem na adres - MOŻLIWA PODŁÓŻA!

który służy tylko do generowania przerażających fałszywych alarmów dla użytkowników z niekompetentnymi dostawcami usług internetowych.

OK, więc jak to może spowodować opóźnienie?

Jeśli serwer DNS nie zareaguje natychmiast, klient będzie czekał i spróbuje ponownie. (W przypadku opóźnienia lub utraty pakietu DNS z powodu przeciążenia sieci). Jeśli serwer DNS w ogóle nie odpowiada, klient ostatecznie się podda. Np. W digmoim systemie próbuje przez 15 sekund. (Używa bardziej szczegółowego kodu biblioteki dns, ale zasada jest taka sama).

$ time dig invalid @192.0.2.1

; <<>> DiG 9.9.4-P2-RedHat-9.9.4-12.P2.fc20 <<>> invalid @192.0.2.1
;; global options: +cmd
;; connection timed out; no servers could be reached

real    0m15.020s
user    0m0.010s
sys         0m0.011s

Problemem jest, że wyszukiwanie wsteczne nie otrzymuje odpowiedzi. Możesz samodzielnie uruchomić to samo wyszukiwanie na serwerze i powinieneś zobaczyć to samo opóźnienie co ssh. getent hosts 10.0.2.2.

Na tym etapie istnieje wiele możliwości, które mogą powodować wolne połączenie. Z tego linku jeden problem, który widzę, dotyczy szyfrowania.

Wreszcie wiem, o co chodzi.

katalog / home / user jest zaszyfrowany i dlatego ssh nie mógł uzyskać do niego dostępu, chyba że jestem zalogowany.

Jeszcze jedna możliwość, ze tutaj jest związane z SELinuxobsługą.

Tak, SELinuxprawdopodobna przyczyna. Katalog .sshjest prawdopodobnie źle oznakowany. Patrzeć /var/log/audit/audit.log. Powinien być oznaczony ssh_home_t. Sprawdź za pomocą ls -laZ. Uruchom w restorecon -r -vv /root/.ssh razie potrzeby.

Również z tego linku widzę, że uwierzytelnianie PAM może być przyczyną powolnego SSH.

Edytuj swój plik „ / etc / ssh / ssh_config ” i skomentuj następujące linie:

GSSAPIAuthentication yes
GSSAPIDelegateCredentials no