it-swarm.com.de

lange Verzögerung beim Anmelden mit CentOS7

Ich habe ein CentOS 7-System und wenn ich mich mit PuTTY oder ssh anmelde, dauert es lange, bis ich die Passwortabfrage erhalte. Ich habe ssh -v ausgeführt und festgestellt, dass dies der Fall ist:

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

und dann sitzt es dort für 1-2 Minuten und dann sprengt diese Ausgabe:

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

Und dann kommt die Passwort-Eingabeaufforderung heraus. Dies geschieht unabhängig davon, welcher Benutzer sich anmeldet. Dies geschieht nur auf dem 1-System. Ich habe 5 andere, wo es ohne Verzögerung weitergeht.

Es gibt keine Festplatte oder Speicher oder andere Fehler in den Protokollen.

Was könnte dazu führen, dass es sich so verzögert?

AKTUALISIEREN:

Ich habe versucht, GSSAPIAuthentication auf no zu setzen, und das hat das Problem nicht gelöst.

Ich habe ssh erneut ausgeführt, diesmal mit -vvv. Diese Ausgabe kam heraus und dann hing es:

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)),

Nach 1-2 Minuten kam dies heraus:

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

Und dann die Passwort-Eingabeaufforderung.

15
Larry Martell

In Ihrem /etc/ssh/sshd_config Auf dem Remote-Server sollten Sie die Option GSSAPIAuthentication auf no ändern. Starten Sie sshd neu und Sie sollten bereit sein zu gehen.

bearbeiten: GSSAPI (Generic Security Service Application Programming Interface) ist im Wesentlichen eine API, die Kerberos-Bibliotheken verwendet, um eine starke Netzwerkverschlüsselung bereitzustellen. Sofern es keinen bestimmten Grund gibt, warum GSSAPI aktiviert sein muss, sollte diese Methode das Problem beheben, das Sie haben.

edit2: Aus Gründen der Übersichtlichkeit kann es auch vorkommen, dass bei der umgekehrten DNS-Prüfung eine Zeitüberschreitung auftritt (insbesondere bei der Überprüfung des PTR-Eintrags der Verbindungshosts). SSH führt diese Überprüfung selbstverständlich durch, da sie als Sicherheitsmaßnahme zur Validierung des Verbindungshosts dient.

Davon abgesehen trägt der Prozess nicht viel zur tatsächlichen Sicherheit bei, da realistisch gesehen ein erheblicher Anteil der Hosts ohnehin keine PTR hat. Es gibt drei Möglichkeiten, um dieses Problem zu beheben:

1). Sie können die Datei sshd_config Ändern, um den Parameter UseDNS no Zu verwenden. Dadurch wird die umgekehrte DNS-Suche gestoppt. Es ist sicher zu tun.

2). Fügen Sie einen PTR-Eintrag im entsprechenden DNS-System für den Host hinzu, der nur langsam eine Verbindung herstellt.

3). Fügen Sie der Datei OS hosts einen manuellen Eintrag mit dem entsprechenden Eintrag hinzu.

Ich hoffe, das hilft!

16
Brett Levene

Dies klingt nach einem DNS-Problem. Während eines Anmeldeversuchs wird eine umgekehrte DNS-Suche durchgeführt, um den Remote-Hostnamen in den Authentifizierungsprotokollen anzugeben.

Stellen Sie sicher, dass der Server in der Datei /etc/resolv.conf Keinen nicht reagierenden Resolver hat.

4
Admin