Die Verbindung mit SSH zu einem Host, der nicht in DNS/hosts enthalten ist, bleibt beim Verbindungsaufbau für einige Zeit stehen

ssh, scp oder sftp zu einem Knoten, der nicht in der DNS- oder /etc/hosts-Datei erscheint, ist langsam, um eine erste Verbindung herzustellen. Nachdem die Verbindung hergestellt wurde, ist die Geschwindigkeit wie erwartet. Es sind zwei Fälle zu berücksichtigen, siehe unten. Beachten Sie, dass dieses Problem in den meisten Umgebungen nicht auftritt, da sich IPs in /etc/hosts oder DNS befinden.

Die Zeit wird damit verbracht, die IP-Adresse des Ziel-/Quell-Hostnamens aufzulösen oder den Hostnamen für die Ziel-/Quell-IP-Adresse zu finden und/oder die Authentifizierung auf der Grundlage derselben Daten durchzuführen. Bei der Verwendung von -vvv treten zwei verschiedene ausführliche Symptome auf wobei ssh zwei verschiedene Fälle darstellt.

Fall 1

# ssh -vvv 10.10.10.205
... ...
debug1: Next authentication method: gssapi-with-mic
debug3: Trying to reverse map address 10.10.10.205.
debug1: Unspecified GSS failure. Minor code may provide more information
No credentials cache found

In CentOS/RHEL-Systemen ist der SSH-Daemon für die Verwendung von Generic Security Services Application Program Interface (GSSAPI) konfiguriert Authentifizierung standardmäßig. Die GSSAPI führt standardmäßig eine Suche (über DNS oder andere Mittel basierend auf /etc/resolv.conf) nach der angeforderten IP durch. Beachten Sie, dass die Suche auch dann erfolgt, wenn Sie IP-Adressen verwenden. Dies ist für eine sichere/zuverlässige Authentifizierung erforderlich.

Wenn Sie die SSH-Konfigurations-Manpage überprüfen:

# man ssh_config
...
GSSAPIAuthentication
     Specifies whether user authentication based on GSSAPI is allowed. The default is no
...

Wenn die IP/der Host nicht in /etc/hosts oder in der DNS-Datenbank erscheint, läuft die Suchabfrage bei einem erneuten Versuch ab, schließlich gibt sie auf und baut die Verbindung weiter auf. Die Zeit wird während der Suche verbracht (50 Sekunden oder mehr), bis die Passwortabfrage angezeigt wird. Dieser Stillstand tritt nur bei Hosts auf, die sich im lokalen LAN und nicht in der DNS- oder /etc/hosts-Datei befinden. Beachten Sie, dass die Authentifizierungsmethode GSSAPI ist.

Fall 2

# ssh -vvv 10.10.10.12
. . . 
debug1: Offering public key: /root/.ssh/id_dsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
--stalls for 8 seconds--

Hier versucht der Remote-Host, eine DNS-Suche auf der Client-Knoten-IP durchzuführen. Es kann sich um eine brandneue physische oder virtuelle Maschineninstallation handeln, die nicht in /etc/hosts oder DNS aktualisiert wird und daher blockiert, bis die DNS-Abfrage abläuft. Auch hier wird die DNS / Hosts-Suche durchgeführt (basierend auf der /etc/resolv.conf auf dem Client / Server).

Die Lösung

Die unterstützte und richtige Lösung für dieses Problem besteht darin, dass die Hostnamen-/IP-Suche erfolgreich ist. Dazu können Sie:

• Überprüfen Sie Ihre Konfiguration in /etc/resolv.conf auf Namensauflösung und DNS-Serverkonfiguration.
• Wenn nicht definiert, definieren Sie den neu eingeführten Host / die IP, die in den DNS-Server aufgenommen werden soll
• Wenn es ein Problem oder unwürdig ist, DNS-Definitionen durchzuführen (höchstwahrscheinlich ist die Zuweisung temporär – d. h. ein Testsystem, eine temporäre virtuelle Maschine usw.), stellen Sie sicher, dass das Paar aus Hostname und IP-Adresse in Quelle und Ziel enthalten ist Environments' /etc/hosts Datei (das ist viel praktischer)

Problemumgehungen

Ohne eine ordnungsgemäße DNS/hosts (oder /etc/resolv.conf-Konfiguration für diese Angelegenheit) sollen die SSH-Verbindungen anfangs langsam sein. So soll es bei OEL sein. Alternativ kann die Wartesituation durch einige Konfigurationsänderungen umgangen werden.

Für Fall 1 die GSSAPIAuthentication könnte deaktiviert worden sein. Obwohl dies möglich ist, wird dringend davon abgeraten, da die Verwendung von GSSAPI eine der grundlegenden Sicherheitsfunktionen von SSH ist. SSH ermöglicht nicht nur die Sicherheit der Kommunikationsinhalte, sondern kann auch sicherstellen, dass dieses Ziel das beabsichtigte ist. Das liegt daran, dass die GSSAPIAuthentication in OEL auf yes gesetzt ist (obwohl die Manpage sagt, dass es standardmäßig „No“ ist – aber es ist die Standardeinstellung der Core-SSH-Pakete – nicht der spezifischen Distribution). Dennoch ist es möglich, es zu deaktivieren, wenn Sie absolut sicher sind, dass Sie sich in einem geschlossenen Netzwerk befinden und wissen, was Sie tun:

Temporäre Einrichtung – nur um zu sehen, ob es auf der Kommandozeile funktioniert:

# ssh -o "GSSAPIAuthentication no" 10.10.10.205

Die Passwortabfrage sollte sofort erscheinen, wenn Fall 1 Ihr Fall ist. Um dies dauerhaft einzurichten (trotz anderer Empfehlungen), können Sie GSSAPIAuthentication auf dem Client auf eine der folgenden Weisen auf no ändern:

1. Fügen Sie die folgende Zeile zur SSH-Konfigurationsdatei des Benutzerverzeichnisses hinzu (~/.ssh/config ):

GSSAPIAuthentication no

2. Fügen Sie es der System-SSH-Konfigurationsdatei auf dem Client hinzu. d.h. – /etc/ssh/ssh_config und auf der Serverseite. Bearbeiten Sie die serverseitige Konfigurationsdatei (d. h. das System, mit dem Sie sich verbinden, in diesem Fall ist es 10.10.10.205) – /etc/ssh/sshd_config und starten Sie sshd neu:

# service sshd restart

Dies kann erfolgen, während bereits SSH-Verbindungen bestehen.

Wenn Sie in Fall 2 die DNS-Konfiguration oder die /etc/hosts-Dateien irgendwie nicht ändern können/wollen (trotz anderweitiger Empfehlung), können Sie die Situation umgehen, indem Sie DNS-Lookups für das SSH-Protokoll deaktivieren. Sie können dies tun, indem Sie

festlegen

UseDNS no

in der SSH-Konfigurationsdatei des Servers – /etc/ssh/sshd_config

und starten Sie sshd auf dem Server neu

# service sshd restart

Dies kann bei aktiven Verbindungen erfolgen.