Długi czas oczekiwania przy logowaniu

20

Po zalogowaniu się na moim serwerze otrzymuję:

No mail.
Last login: Fri Nov  5 14:22:45 2010...

to muszę poczekać 5 sekund, a potem jest gotowy ...

wolfy@ubuntu-server:~$

Czy ten czas oczekiwania jest normalny, czy powinienem coś zrobić, aby to "naprawić"?

    
zadawane Wolfy 05.11.2010, 14:57
źródło

10 odpowiedzi

18

Jest to zwykle wynikiem pam_motd regeneracji pliku /etc/motd . Możesz sprawdzić poszczególne skrypty w /etc/update-motd.d , aby zobaczyć, czy coś jest szczególnie powolne.

    
odpowiedział Kees Cook 05.11.2010, 21:33
źródło
13

Mam takie same problemy z 10.04 (LTS).

Kiedy uruchamiam mój ssh z -vvv , to umiera na:

debug1: Entering interactive session.

Rozszerzanie tej odpowiedzi.

Udało mi się zdalnie uruchomić serwer i włączyć opcję DEBUG. Wykorzystano również tę możliwość, aby pozostać zalogowanym i obserwować inne próby logowania. Oto, co się dzieje. Klient łączy się i jest autoryzowany i zawiesza się w powyższym komunikacie.

Na serwerze lista procesów pokazuje:

root       835  0.0  0.1  11476  3348 ?        Ss   13:39   0:00 sshd: till [priv]
root       840  0.0  0.0   4804  1124 ?        S    13:39   0:00 /bin/sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin /bin/run-parts --lsbsysinit /etc/update-motd.d
root       841  0.0  0.0   4728  1108 ?        S    13:39   0:00 /bin/run-parts --lsbsysinit /etc/update-motd.d
root       854  0.0  0.0   4804  1144 ?        S    13:39   0:00 /bin/sh /etc/update-motd.d/50-landscape-sysinfo
root       861  0.2  0.5  15388  9248 ?        S    13:39   0:00 /usr/bin/python /usr/bin/landscape-sysinfo
root       863  0.0  0.0      0     0 ?        Z    13:39   0:00 [who] <defunct>

Mogę wykonać /usr/bin/python /usr/bin/landscape-sysinfo dobrze, gdy jestem zalogowany, ale z jakiegoś powodu nie mogę się domyślić, dlaczego blokuje proces logowania. Kiedy zabiję proces, logowanie będzie kontynuowane po znaku zachęty i zakończy się sukcesem .

To nie wydaje się być problemem ssh (d), jest bardziej związane z update-motd i krajobrazem. Odinstalowałem pakiet update-motd , ale wygląda na to, że katalog /etc/update-motd nie zniknie, a skrypty nadal są wykonywane - co powoduje zawieszenie procesu.

Debugowanie tego dalej:

Okazuje się, że katalog /etc/update-motd.d/ naprawdę nie należy do pakietu update-motd , wydaje się być wywołany przez uwierzytelnienie pam poprzez sshd.

Wydaje mi się, że to zrobiłem!

Wyłączone pam_motd w następujących plikach:

  • /etc/pam.d/sshd
  • /etc/pam.d/login

Jeszcze jedno:

apt-get purge landscape-client landscape-common

Te wydają się pomagać w pewnym zakresie. Jednak tylko usuwa obraźliwy skrypt w /etc/update-motd.d/ i nie usuwa wszystkich skryptów w tym katalogu ani nie pozbędzie się pam_motd .

Ogólnie nie znalazłem sposobu na całkowite wyłączenie pam_motd , ponieważ wydaje się, że cokolwiek robi - spowalnia proces logowania do pewnego stopnia. Nie blokuje jak skrypt w landscape-common , ale jest wolniejszy.

Raport o błędzie dotyczący tego problemu:

Obejścia z tego miejsca:

  

Masz rację, że umiejętność logowania jest ważniejsza niż   prezentując motd. Jeśli takie zachowanie jest dla Ciebie problemem, są   kilka sposobów, które można wyłączyć:

     
  • Skomentuj wiersz "pam_motd" w /etc/pam.d/sshd , jeśli nie chcesz wyświetlać motd.
  •   
  • usuń zawartość katalogu /etc/update-motd.d .
  •   
  • chmod -x skrypty w /etc/update-motd.d , których nie chcesz uruchamiać.
  •   
    
odpowiedział Till 11.07.2012, 15:20
źródło
10

W końcu znalazłem rozwiązanie:

  1. sudo apt-get remove landscape-client landscape-common
  2. wiersz komentarza %kod% w session optional pam_motd.so i /etc/pam.d/login

Teraz logowanie jest NATYCHMIAST!

    
odpowiedział BarsMonster 22.03.2011, 06:12
źródło
4

Z Twojego opisu brzmi to bardziej jak problem z siecią. Aby zdiagnozować:

  • Uruchom program ssh z parametrem -v, aby był pełny.
  • Spróbuj uruchomić polecenie ping na serwerze SSH, z którym się łączysz, i zobacz, czy to również zawiesza się w tym samym czasie.
  • Spróbuj innego transferu na ten sam serwer. Na przykład wget z parametrem --limit-rate, aby pobrać plik za pośrednictwem protokołu HTTP i potrwać wystarczająco długo, aby mógł wywołać "zawieszone" zachowanie.
  • Sprawdź, czy zawiesza się tylko w stanie bezczynności, a nawet jeśli coś robisz w tej chwili. Jeśli zawiesza się w trybie bezczynności, prawdopodobnie powie ci to diagnostyka -v, w takim przypadku może pomóc pomoc do korzystania z keepalive (ssh -o "TCPKeepAlive yes")

Jeśli możesz połączyć OK z Windows i PuTTY, prawdopodobnie nie jest to problem po stronie serwera.

    
odpowiedział roadmr 08.12.2011, 05:49
źródło
2

Myślę, że po zalogowaniu się Ubuntu wykonuje jeden lub więcej z tych plików:

/etc/bash.bashrc
~/.bash_profile
~/.bashrc

Możesz zobaczyć, co jest w nich, a może nawet spróbować je wykonać, aby zobaczyć, co trwa tak długo.

    
odpowiedział Savvas Radevic 05.11.2010, 16:30
źródło
2

W moim ograniczonym doświadczeniu, gdy kit działa, ale Linux, w tym przypadku Ubuntu, nie jest zwykle utrzymywany przy życiu. Problemy z siecią lub serwerem miałyby wpływ na system operacyjny klienta.

Możesz użyć powyższej opcji keep alive w wierszu poleceń, ale jest to dość żmudne w pisaniu.

Łatwiejsze edytowanie kilku plików konfiguracyjnych.

Jeśli masz root access i chcesz włączyć go automatycznie dla wszystkich użytkowników, edytuj /etc/ssh/ssh_config , dodaj

KeepAlive yes
ServerAliveInterval 120

Jeśli nie masz uprawnień administratora lub włącz go dla pojedynczego użytkownika, edytuj ~/.ssh/config i dodaj te same dwie linie.

    
odpowiedział Panther 08.12.2011, 06:48
źródło
2

Jeśli włączone są PermitEmptyPassword i UsePAM , serwer OpenSSH zawsze próbuje uwierzytelnić przy użyciu zerowego hasła, co oznacza, że ​​nie jest wymagane uwierzytelnianie dla danego konta. Robi to tak szybko, jak rozpoczyna się proces uwierzytelniania, w obu protokołach, a nie w odpowiedzi na jakiekolwiek "prawdziwe" żądanie uwierzytelnienia od klienta. OpenSSH zezwoli na taki dostęp tylko wtedy, gdy sshd_config flaga PermitEmptyPassword jest ustawiona; niestety, sposób w jaki jest kod napisane, w każdym przypadku wykonuje test hasła, a więc pokazuje do PAM jako błąd.

Więc: wyłącz PermitEmptyPassword lub UsePAM , ale pamiętaj: bez PAM, nie będziesz mógł się zalogować bez klucza.

Numer referencyjny: link

    
odpowiedział Alessandro Pezzato 01.10.2012, 22:53
źródło
0

Sprawdź logi systemowe w / var / log, możesz znaleźć komunikat z powiązanym błędem / limitem czasu.

    
odpowiedział João Pinto 05.11.2010, 15:14
źródło
0

Jeśli masz też czas oczekiwania przed

Edytuj /etc/sshd_config

i ustaw (lub dodaj)

UseDNS no

lub dodaj swój ip w /etc/hosts , jeśli jest to statyczny lokalny

    
odpowiedział user11187 21.02.2011, 00:09
źródło
0

Możesz próbować monitorować uruchomione procesy, logując się do serwera z już zalogowanego połączenia (lub innej konsoli). Istnieje szansa na zauważenie, które procesy są najbardziej aktywne lub używają najwięcej procesorów w tym czasie.

Poniżej znajduje się jedna z możliwych metod:

  1. Spróbuj zalogować się na innej konsoli.
  2. Uruchom top , aby zobaczyć, co się stanie.
  3. Zaloguj się na 1. konsoli.

Zwróć uwagę, że jeśli opóźnienie nie jest spowodowane przez obliczenia wymagające dużego obciążenia procesora, nie zauważysz niczego poza miejscem. W takim przypadku problem może dotyczyć operacji we / wy (oczekiwanie na odczyt / zapis dysku lub odpowiedź sieciową).

    
odpowiedział ido 05.11.2010, 15:17
źródło

Przeczytaj inne pytania na temat tagów