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ć”?
server
ssh
performance
login
Wolfy
źródło
źródło
Odpowiedzi:
Zwykle jest to wynikiem
pam_motd
ponownego wygenerowania/etc/motd
pliku. Możesz sprawdzić poszczególne skrypty,/etc/update-motd.d
aby sprawdzić, czy coś jest szczególnie wolne.źródło
Mam te same problemy z 10.04 (LTS).
Kiedy uruchamiam ssh
-vvv
, umiera w: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:
Mogę wykonać się
/usr/bin/python /usr/bin/landscape-sysinfo
dobrze, 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-motd
krajobrazem. Odinstalowałemupdate-motd
pakiet, ale wygląda na to, że/etc/update-motd
katalog 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 pakietuupdate-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:
Jeszcze jeden:
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 pozbywapam_motd
.Ogólnie rzecz biorąc, nie znalazłem sposobu na
pam_motd
całkowite wyłączenie, ponieważ wydaje się, że cokolwiek robi - spowalnia proces logowania do pewnego stopnia. Nie blokuje się tak, jak skryptlandscape-common
, ale działa wolniej.Raport o błędzie dotyczący tego problemu:
Rozwiązania stamtąd:
źródło
W końcu sam znalazłem rozwiązanie:
sudo apt-get remove landscape-client landscape-common
session optional pam_motd.so
w/etc/pam.d/login
i/etc/pam.d/sshd
Teraz logowanie jest NATYCHMIASTOWE!
źródło
Z twojego opisu brzmi bardziej jak problem z siecią. Aby zdiagnozować:
Jeśli możesz połączyć OK z Windows i PuTTY, prawdopodobnie nie jest to problem po stronie serwera.
źródło
Jeśli
PermitEmptyPassword
iUsePAM
oba 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, gdyPermitEmptyPassword
ustawiona 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
PermitEmptyPassword
lubUsePAM
, 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
źródło
Myślę, że podczas logowania Ubuntu wykonuje jeden lub więcej z tych plików:
Możesz zobaczyć, co jest w nich, a może nawet spróbować je wykonać, aby zobaczyć, co trwa tak długo.
źródło
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
, dodajJeśli nie masz dostępu do konta root lub aby włączyć go dla jednego użytkownika, edytuj
~/.ssh/config
i dodaj te same dwa wiersze.źródło
Sprawdź dzienniki systemowe w katalogu / var / log, może pojawić się komunikat z powiązanym błędem / przekroczeniem limitu czasu.
źródło
Jeśli masz czas, poczekaj wcześniej
Edytować
/etc/sshd_config
i ustaw (lub dodaj)
lub dodaj swój ip,
/etc/hosts
jeśli jest to statyczny lokalnyźródło
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:
top
tam, aby zobaczyć, co się stanie.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ą).
źródło