Verzögerung, um eine Passwortabfrage zu erhalten, wenn Sie zu einem öffentlichen Server senden

Ich habe einen Server (Debian 7) in meiner Universität mit öffentlicher IP eingerichtet. Wenn ich in das System ssh (von außerhalb des Campus), erhalte ich eine seltsame Verzögerung von 5-10 Sekunden, bevor ich die Passwortabfrage erhalte. Warum ist das so?

Ich renne ssh -v, um eine ausführliche Ausgabe zu erhalten:

debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received

.... delay of 5-10 seconds here

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: /home/nass/.ssh/id_rsa
debug1: Trying private key: /home/nass/.ssh/id_dsa
debug1: Trying private key: /home/nass/.ssh/id_ecdsa
debug1: Next authentication method: password

dann bekomme ich die Passwortabfrage in Ordnung.

mein resolv.confsieht aus wie

domain <mydomain>.edu
nameserver <dns ip address>

Die Firewall wird gesteuert von webminund die Konfiguration /etc/webmin/firewall/iptables.savesieht folgendermaßen aus:

# Generated by iptables-save v1.4.14 on Mon Feb 10 17:41:38 2014
*filter
:FORWARD DROP [0:0]
:IP_TCP - [0:0]
:INPUT DROP [0:0]
:IP_UDP - [0:0]
:OUTPUT ACCEPT [0:0]
:IP_ICMP - [0:0]
-A INPUT -i lo -j ACCEPT
-A INPUT -m state --state ESTABLISHED -j ACCEPT
-A INPUT -m state --state RELATED -j ACCEPT
-A INPUT -p tcp -m tcp --tcp-flags ACK ACK -j ACCEPT
-A INPUT -s 127.0.0.1/32 -i eth0 -j DROP
-A INPUT -p icmp -i eth0 -j IP_ICMP
-A INPUT -p udp -m udp -i eth0 -j IP_UDP
-A INPUT -p tcp -m tcp -i eth0 -j IP_TCP
-A INPUT -m limit --limit 3/second --limit-burst 3 -j ULOG --ulog-prefix "FW_INPUT: " --ulog-nlgroup 1
-A IP_ICMP -p icmp -m icmp --icmp-type 0 -j ACCEPT
-A IP_ICMP -p icmp -m icmp --icmp-type 3 -j ACCEPT
-A IP_ICMP -p icmp -m icmp --icmp-type 4 -j ACCEPT
-A IP_ICMP -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A IP_ICMP -p icmp -m icmp --icmp-type 12 -j ACCEPT
-A IP_ICMP -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A IP_ICMP -p icmp -j RETURN
-A IP_TCP -p tcp -m tcp --dport 2049:2050 -j DROP
-A IP_TCP -p tcp -m tcp --dport 6000:6063 -j DROP
-A IP_TCP -p tcp -m tcp --dport 7000:7010 -j DROP
-A IP_TCP -p tcp -m tcp --dport 19001 -j ACCEPT
-A IP_TCP -p tcp -m tcp --dport 12321 -j ACCEPT
-A IP_TCP -p tcp -m tcp --dport 80 -j ACCEPT
-A IP_TCP -p tcp -m tcp --dport 443 -j ACCEPT
-A IP_TCP -p tcp -m tcp -j RETURN
COMMIT
# Completed on Mon Feb 10 17:41:38 2014
# Generated by iptables-save v1.4.14 on Mon Feb 10 17:41:38 2014
*mangle
:PREROUTING ACCEPT [2386474:238877913]
:INPUT ACCEPT [2251067:225473866]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [1100410:5416839301]
:POSTROUTING ACCEPT [1100428:5416842284]
COMMIT
# Completed on Mon Feb 10 17:41:38 2014
# Generated by iptables-save v1.4.14 on Mon Feb 10 17:41:38 2014
*nat
:PREROUTING ACCEPT [211832:26633302]
:INPUT ACCEPT [444:26827]
:OUTPUT ACCEPT [1817:114098]
:POSTROUTING ACCEPT [1817:114098]
COMMIT
# Completed on Mon Feb 10 17:41:38 2014

Last but not least erhält ein Kollege, der auch ein Konto auf demselben System hat, sofort die Aufforderung!

— nass
quelle

Der erste Gedanke ist, dass der Server UseDNS yesaktiviert hat. Dies ist bekannt dafür, dass Anmeldungen verlangsamt werden. Abgesehen davon müssten wir die Debug-Protokolle des Servers sehen ( $(which sshd) -d).

— Patrick

@Patrick, es scheint aus gutem Grund da zu sein. Aber warum verlangsamt es mein Login, aber nicht meine Kollegen?

— nass

Warum glaubst du, ist es aus gutem Grund da? Es ist sehr wahrscheinlich, dass es da ist, weil niemand jemals daran gedacht hat, es auszuschalten. Und es verlangsamt Sie wahrscheinlich, weil der autorisierende DNS-Server für Ihren Netblock tot ist oder fehlt.

— Patrick

@Patrick gut, führt es diese Überprüfung nicht aus Sicherheitsgründen durch?

— Nass

@ Patrick übrigens das Problem gelöst, so können Sie dies auch als Antwort schreiben

— nass

Wie in den Kommentaren angegeben, wird dies wahrscheinlich durch die UseDNS yesEinstellung sshd_configauf dem Server verursacht.

Die UseDNSEinstellung ist ein häufiger Schuldiger für genau dieses Problem. Grundsätzlich passiert, dass Ihr IP-Netblock entweder einen defekten oder einen fehlenden DNS-Server hat. Daher versucht sshd, Ihre IP-Adresse rückwärts zu suchen, und wartet, bis das Zeitlimit überschritten ist. Andere Personen erleben die Verzögerung nicht, da sie einen funktionierenden DNS-Server für ihren Netblock haben.

Die meisten Leute schalten diese Einstellung aus genau diesem Grund aus. Ja, die Einstellung dient zwar der Sicherheit, ist aber ziemlich nutzlos .

Die Lösung besteht einfach darin, Folgendes einzustellen sshd_config:

UseDNS no

— Patrick
quelle

Nur ein Hinweis: sshd_configIn Debian 7 kommt ohne diese Klausel in der Konfigurationsdatei. Man muss es

— eingeben