Długi czas oczekiwania na logowanie

Kiedy loguję się na moim serwerze, otrzymuję to:

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

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

wolfy@ubuntu-server:~$

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

Zwykle jest to wynikiem pam_motdponownego wygenerowania /etc/motdpliku. Możesz sprawdzić poszczególne skrypty, /etc/update-motd.daby sprawdzić, czy coś jest szczególnie wolne.

Mam te same problemy z 10.04 (LTS).

Kiedy uruchamiam ssh -vvv, umiera w:

debug1: Entering interactive session.

Rozszerzając tę ​​odpowiedź.

Udało mi się ponownie uruchomić serwer zdalnie i włączyłem rejestrację DEBUG. Skorzystałem również z tej okazji, aby pozostać zalogowanym i obserwować inne próby logowania. Oto co się dzieje. Klient łączy się, jest autoryzowany i zawiesza się przy powyższym komunikacie.

Na serwerze lista procesów pokazuje to:

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ć się /usr/bin/python /usr/bin/landscape-sysinfodobrze, gdy jestem zalogowany, ale z jakiegoś powodu nie mogę zrozumieć, dlaczego wstrzymuje proces logowania. Kiedy zabić proces logowania trwa do szybkiego i jest udany .

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

Debugowanie tego dalej:

Okazuje się, że /etc/update-motd.d/katalog tak naprawdę nie należy do pakietu update-motd, wydaje się, że jest uruchamiany przez uwierzytelnianie pam poprzez sshd.

Wydaje mi się, że go przybiłem!

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

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

Jeszcze jeden:

apt-get purge landscape-client landscape-common

Te wydają się do pewnego stopnia pomocne. Mimo to usuwa tylko szkodliwy skrypt /etc/update-motd.d/i nie usuwa wszystkich skryptów w tym katalogu, ani się go nie pozbywa pam_motd.

Ogólnie rzecz biorąc, nie znalazłem sposobu na pam_motdcałkowite wyłączenie, ponieważ wydaje się, że cokolwiek robi - spowalnia proces logowania do pewnego stopnia. Nie blokuje się tak, jak skrypt landscape-common, ale działa wolniej.

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

• https://bugs.launchpad.net/ubuntu/+source/pam/+bug/805423

Rozwiązania stamtąd:

Masz rację, że możliwość logowania jest ważniejsza niż prezentacja motd. Jeśli takie zachowanie jest dla Ciebie problemem, możesz je wyłączyć na kilka sposobów:

• skomentuj wiersz „pam_motd”, /etc/pam.d/sshdjeśli nie chcesz wyświetlać motd.
• usuń zawartość /etc/update-motd.dkatalogu.
• chmod -x skrypty, w /etc/update-motd.dktórych nie chcesz uruchamiać.

W końcu sam znalazłem rozwiązanie:

1. sudo apt-get remove landscape-client landscape-common
2. linia komentarz session optional pam_motd.so w /etc/pam.d/logini/etc/pam.d/sshd

Teraz logowanie jest NATYCHMIASTOWE!

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

• Uruchom ssh z parametrem -v, aby być pełnym.
• Spróbuj uruchomić polecenie ping do serwera SSH, z którym się łączysz, i sprawdź, czy to również zawiesza się w tym samym czasie.
• Wypróbuj inny rodzaj transferu na ten sam serwer. Na przykład, wget z parametrem --limit-rate, aby pobrać plik przez HTTP i pozwolić, aby zajęło to wystarczająco dużo czasu, aby wywołać zachowanie „zawieszenia”.
• Sprawdź, czy zawiesza się tylko w stanie bezczynności, a nawet jeśli w tej chwili coś robisz. Jeśli zawiesi się on w stanie bezczynności, prawdopodobnie wyświetli się komunikat diagnostyczny -v, w którym to przypadku pomocne może być skorzystanie 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.

Jeśli PermitEmptyPasswordi UsePAMoba są włączone, serwer OpenSSH zawsze podejmuje próbę uwierzytelnienia przy użyciu zerowego hasła, które przyjmuje za znak, że dla danego konta nie jest wymagane uwierzytelnianie. Robi to natychmiast po rozpoczęciu procesu uwierzytelniania, w obu protokołach, a nie w odpowiedzi na „prawdziwe” żądanie uwierzytelnienia od klienta. OpenSSH zezwoli na taki dostęp tylko wtedy, gdy PermitEmptyPasswordustawiona jest flaga sshd_config ; niestety sposób, w jaki kod jest napisany, w każdym przypadku wykonuje test hasła, a zatem pokazuje PAM jako błąd.

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

Odniesienie: https://groups.google.com/forum/?fromgroups=#!topic/comp.security.ssh/wExY8lWlG-c

Myślę, że podczas logowania 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.

Z mojego ograniczonego doświadczenia wynika, że ​​gdy kit działa, ale Linux, w tym przypadku Ubuntu, nie działa, zwykle utrzymuje się przy życiu. Problemy z siecią lub serwerem wpłynęłyby zarówno na system operacyjny klienta.

Możesz użyć powyższej opcji „zachowaj przy życiu” w wierszu poleceń, ale pisanie jest trochę nudne.

Łatwiejsza edycja kilku plików konfiguracyjnych.

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

KeepAlive yes
ServerAliveInterval 120

Jeśli nie masz dostępu do konta root lub aby włączyć go dla jednego użytkownika, edytuj ~/.ssh/configi dodaj te same dwa wiersze.

Sprawdź dzienniki systemowe w katalogu / var / log, może pojawić się komunikat z powiązanym błędem / przekroczeniem limitu czasu.

Jeśli masz czas, poczekaj wcześniej

Edytować /etc/sshd_config

i ustaw (lub dodaj)

UseDNS no

lub dodaj swój ip, /etc/hostsjeśli jest to statyczny lokalny

Możesz spróbować monitorować uruchomione procesy podczas logowania do serwera z już zalogowanego połączenia (lub innej konsoli). Istnieje możliwość wykrycia, które procesy są najbardziej aktywne lub zużywają najwięcej procesora w tym czasie.

Poniżej znajduje się jedna możliwa metoda:

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

Należy pamiętać, że jeśli opóźnienie nie jest spowodowane przez niektóre obliczenia intensywnie wykorzystujące procesor, nie zauważysz niczego nie na miejscu. W takim przypadku problem może być związany z operacjami we / wy (oczekiwanie na odczyt / zapis dysku lub odpowiedź sieciową).