duże opóźnienie przy logowaniu w CentOS7

Mam system CentOS 7, a kiedy loguję się za pomocą putta lub ssh, pojawia się długie opóźnienie, zanim pojawi się monit o hasło. Uruchomiłem ssh -v i stwierdziłem, że do tego dochodzi:

debug1: ssh_ecdsa_verify: signature correct
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

a potem siedzi tam przez 1-2 minuty, a następnie ta moc wybucha:

debug1: Authentications that can continue:
publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: gssapi-keyex
debug1: No valid Key exchange context
debug1: Next authentication method: gssapi-with-mic
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Unspecified GSS failure.  Minor code may provide more information
debug1: Unspecified GSS failure.  Minor code may provide more information
No Kerberos credentials available
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug1: Next authentication method: password

I wtedy pojawia się monit o hasło. Dzieje się tak bez względu na to, który użytkownik się loguje. Dzieje się tak tylko w systemie 1. Mam 5 innych, w których przebiega bez opóźnień.

W dziennikach nie ma dysku ani pamięci ani żadnych innych błędów.

Co może być przyczyną takiego opóźnienia?

AKTUALIZACJA:

Próbowałem ustawić wartość „ GSSAPIAuthenticationnie”, ale to nie rozwiązało problemu.

Ponownie uruchomiłem ssh, tym razem z opcją -vvv. Ten wynik wyszedł, a następnie zawiesił się:

debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/motor/.ssh/id_rsa ((nil)),
debug2: key: /home/motor/.ssh/id_dsa ((nil)),
debug2: key: /home/motor/.ssh/id_ecdsa ((nil)),
debug2: key: /home/motor/.ssh/id_ed25519 ((nil)),

Po 1-2 minutach wyszło:

debug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying private key: /home/motor/.ssh/id_rsa
debug3: no such identity: /home/motor/.ssh/id_rsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_dsa
debug3: no such identity: /home/motor/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_ecdsa
debug3: no such identity: /home/motor/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /home/motor/.ssh/id_ed25519
debug3: no such identity: /home/motor/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

A następnie monit o hasło.

Na swoim /etc/ssh/sshd_configzdalnym serwerze powinieneś zmienić opcję GSSAPIAuthenticationna nie. Uruchom ponownie sshd i powinieneś być gotowy.

edycja: GSSAPI (Generic Security Service Application Programming Interface) to zasadniczo interfejs API, który wykorzystuje biblioteki Kerberos do zapewnienia silnego szyfrowania sieci. O ile nie ma szczególnego powodu, dla którego chcesz włączyć GSSAPI, ta metoda powinna rozwiązać występujący problem.

edit2: Dla jasności może być również możliwe, że upłynął limit czasu wstecznego sprawdzania DNS (w szczególności sprawdzanie rekordu PTR podłączających się hostów). SSH sprawdza to oczywiście, ponieważ działa jako środek bezpieczeństwa w celu sprawdzenia poprawności podłączonego hosta.

Mówiąc to, proces nie dodaje wiele pod względem realnego bezpieczeństwa, ponieważ realistycznie istnieje znaczna część hostów, które i tak nie mają PTR. Istnieją trzy sposoby rozwiązania tego problemu:

1). Możesz zmienić sshd_configplik, aby użyć UseDNS noparametru. Spowoduje to zatrzymanie wyszukiwania wstecznego DNS. Jest to bezpieczne.

2). Dodaj rekord PTR do odpowiedniego systemu DNS dla hosta, który powoli się łączy.

3). Dodaj ręczny wpis do hostspliku systemu operacyjnego z odpowiednim wpisem.

Mam nadzieję, że to pomaga!

Brzmi to jak problem z DNS - podczas próby logowania wykonywane jest odwrotne wyszukiwanie DNS, aby podać zdalną nazwę hosta w dziennikach uwierzytelniania.

Sprawdź, czy na serwerze nie ma nieodpowiadającego mechanizmu rozpoznawania nazw w /etc/resolv.confpliku.