sshd versucht DNS-Lookups mit UseDNS-Nr

7

sshd scheint fast immer zu versuchen, eine Reverse-DNS-Suche für neue Verbindungen durchzuführen. Bei Hosts ohne PTR-Eintrag führt dies zu Verzögerungen von 5 Sekunden pro Abfrage. Manchmal akzeptiert es die Verbindung sofort, manchmal versucht es einmal, manchmal zweimal aufzulösen. Ich habe dies tcpdump port 53beim Versuch beobachtet, eine Verbindung zum Server herzustellen. Ich habe wirklich keine Ahnung, warum es manchmal versucht, zweimal nachzuschlagen.

Dies scheint ein ziemlich häufiges Problem zu sein, und die Standardantwort lautet UseDNS no/ etc / ssh / sshd_config. Ich habe diese Option jedoch bereits festgelegt und sshd versucht immer noch, diese umgekehrten Suchvorgänge durchzuführen.

Ich habe hier einen anderen Vorschlag gefunden . Ich habe versucht, -u0 zu / etc / default / ssh hinzuzufügen, aber es scheint nichts geändert zu haben.

Ich habe an dieser Stelle keine Ideen mehr, jeder Vorschlag ist willkommen.

ssh reverse-dns

— koniiiik
quelle

Haben Sie den Dienst nach diesen Änderungen neu gestartet?

— Michael Hampton

Ja natürlich. (-:

— koniiiik

Versuchen Sie, die sshd LogLevel auf VERBOSE oder DEBUG zu erhöhen, um zu sehen, was los ist?

— hcsteve

Ich beabsichtige, das irgendwann nachts zu versuchen, wenn es weniger Verbindungen von Menschen gibt ...

— koniiiik

Kannst du deine sshd_config posten? Tests mit FreeBSD 9.1 und 9.2 zeigen, dass bei Verwendung von UseDNS auf no und keinem anderen Konfigurationselement, das eine DNS-Suche verursachen könnte, keine Lookups auftreten.

— Kevin Phair

9

Heutzutage ist GSSAPI der häufigste Schuldige:

/etc/ssh/sshd_config:
GSSAPIAuthentication no

Die anderen drei Schuldigen für die Linux-Plattform wurden in einer anderen Antwort erwähnt:

zu sshdeiner Befehlszeilenoption hinzufügen-u0
einstellen UseDNS no
Verwenden Sie keine from=hostnameinternen authorized_keysDateien

— kubanczyk
quelle

5

Die Verwendung von DNS = no verhindert nicht, dass sshd DNS-Suchvorgänge durchführt, sondern verhindert, dass Clients abgelehnt werden, wenn PTR-Einträge nicht übereinstimmen.

-u0 verhindert, dass sshd DNS-Namen in der utmp-Struktur protokolliert.

Suchvorgänge können weiterhin durchgeführt werden, je nachdem, was ein Benutzer in seinen autorisierten Schlüsseln hat.

Sehen Sie dies für eine anständige Erklärung:

http://lists.freebsd.org/pipermail/freebsd-stable/2006-November/030886.html

— Vierbeiner
quelle

Um ehrlich zu sein, habe ich noch nicht einmal davon gehört, dass es die Möglichkeit gibt, from = hostname in autorisierten Schlüsseln anzugeben. Zumindest wenn ich mich anmelden möchte, ist dies nicht der Fall. Außerdem tritt die durch die Suche verursachte Verzögerung auf, bevor sshd die Leitungsverbindung vom <Host> -Port <Port> in Syslog protokolliert, was vermutlich bedeutet, bevor er erfährt, welcher Benutzer versucht, sich anzumelden.

— koniiiik

1

Ändern Sie diese in / etc / ssh / sshd_config Port 22, UseDNS yes, UsePAM no, UseLogin no,

Und machen: service sshd neu starten

— Ernesto Mila
quelle

0

Nun, es ist eine Weile her, aber es stellte sich heraus, dass die Verzögerung beim nächsten Neustart des Servers verschwand. Ich habe keine Ahnung, was passiert ist, aber es muss eines der Dinge gewesen sein, die ich versucht habe, und anscheinend war es nicht genug, sshd neu zu starten.

— koniiiik
quelle

0

In meinem Fall bestand das Problem aus Einträgen in den Dateien hosts.allow und / oder hosts.deny, die dazu führten, dass DNS-Suchvorgänge durchgeführt wurden. Laut Dokumentation kann dies auch für die Anweisungen Allow und Deny in den Konfigurationsdateien passieren.

— PlasmaHH
quelle

-2

Auch das Deaktivieren der GSS-Authentifizierung kann bei diesem Problem helfen.

— Nefer
quelle

1

Diese Antwort wurde bereits früher gegeben.

— Gerald Schneider