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.

ubuntu ssh arch-linux

— x-yuri
źródło

Jeśli link jest akceptowalną i działającą odpowiedzią, powinieneś opublikować go za pomocą przycisku „Podaj własną odpowiedź”. Pomaga to oznaczyć pytanie jako udzielone i ułatwia innym, którzy przeglądają Twoje pytanie, tytuł, aby zobaczyć, że istnieje robocza odpowiedź. Edycja pytania i dodanie odpowiedzi jest w porządku, ale utrudnia ludziom dostrzeżenie odpowiedzi.

— 0x Owczarek

@ 0xSheepdog, uważam, że OP odniósł się do wspomnianego linku i nadal nie jest w stanie rozwiązać problemu. Dlatego opublikował pytanie dotyczące tego linku w swoim pytaniu.

— Ramesh

Dziękuję @Ramesh, że ten punkt nigdy nie przyszedł mi do głowy. Przepraszam x-yuri, jeśli cię źle zrozumiałem.

— 0x Owczarek

Wydaje mi się, że „UseDNS nie” na serwerze powinno unikać opóźnienia. (Często zauważam opóźnienie, gdy używam ssh lokalnie przy braku działającego DNS). Czy tak jest, czy nie?

— sourcejedi

@ 0xSheepdog dodałem link, ponieważ pomógł mi dowiedzieć się więcej na temat problemu. Ale problem nie został jeszcze rozwiązany.

— x-yuri

Odpowiedzi:

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.

— sourcejedi
źródło

Dobrze. Plik hosts służy do wyszukiwania wstecznego, a także normalnego, więc prawdopodobnie to właśnie powoduje tę różnicę. Czy mówisz, że maszyny wirtualne używają serwera DNS ISP, tzn. Jeśli wyglądasz, /etc/resolv.confże nie wyświetla adresu IP w jednym z twoich własnych zakresów sieci, takich jak 10.0.2.2? Jeśli tak, to tak, jest to niekompetencja dostawcy usług internetowych. (I domniemanie, że prawdopodobnie nie będą w stanie naprawić tego za radą pojedynczego konsumenta. Więc musisz obejść to sam. W takim przypadku np. Instalacja unboundjako rekurencyjnego resolvera na komputerze hosta byłaby dobrym pomysłem w generał).

— sourcejedi

Ach, brakowało mi dwóch rzeczy. 1. Kontrola SSH pracuje nie jest spodziewane , aby spowodować opóźnienie nawet jeśli odwrotne odwzorowanie brakuje. DNS powinien natychmiast zwrócić pustą odpowiedź, a klient nie spróbuje ponowić zapytania. Twój problem nie przypomina konkretnej niekompetencji dostawcy usług internetowych, o której wspomniałem w odpowiedzi, jeśli o to ci chodziło.

— sourcejedi

2. Zauważ, że digto nie dotyczy /etc/hosts. Jeśli /etc/resolv.confwyświetla ten sam serwer nazw na obu maszynach wirtualnych, oczekiwałbym dig -x 10.0.2.2również przekroczenia limitu czasu na maszynie wirtualnej debian. To samo dotyczy systemu hosta, tzn. Tego, na którym działa VirtualBox.

— sourcejedi

Jedną z podejrzeń jest to, że VirtualBox prawie na pewno ma zintegrowany serwer DNS i może być w jakiś sposób wadliwy. Innym może być stare, wadliwe oprogramowanie przekaźnika DNS (widziałem trochę wad na nieaktualnym DNSMasq) działającym na twoim routerze domowym.

— sourcejedi

Jeśli jeszcze tego nie zrobiłeś, sprawdziłbym również dwukrotnie jedno lub dwa normalne wyszukiwania na maszynach wirtualnych. Ponieważ działa poprawnie na hoście, nie sądzę, że jest to problem z twoim usługodawcą internetowym (lub lokalnym routerem). Powiedziałbym, że obie maszyny wirtualne są w porządku, to VirtualBox jest zepsuty (zwłaszcza, że zapewniają one określone pakiety dla każdej wersji Ubuntu). Czy to błędna konfiguracja w twoim systemie, czy błąd, który wymaga naprawy w VirtualBox? Nie wiem przepraszam Przypuszczalnie istnieje forum społeczności VirtualBox, w którym możesz się zarejestrować i zostać podrzuconym na :-).

— sourcejedi

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

— Ramesh
źródło

Przepraszam, nie wspomniałem, że sprawdziłem swoje GSSAPI*ustawienia. Jeśli chodzi o pierwszy przypadek, mój katalog domowy nie jest zaszyfrowany, a serwer nie odrzucił mojego klucza. I nie mam /var/log/auditkatalogu na maszynie hosta i gościa. Zastanawiam się teraz, czy jest to spowodowane UseDNS = yes, choć dzieje się tak na obu maszynach wirtualnych. A ten, który łączy się zbyt wolno, jest z arch linux. UseDNSDoceniane jest uzasadnienie tego, jak dokładnie wpływa na problem.

— x-yuri