ich habe an meiner Universität einen Server (Debian 7) mit öffentlicher IP eingerichtet. Wenn ich mich per SSH in das System einlogge (von außerhalb des Campus), kommt es zu einer seltsamen Verzögerung von 5-10 Sekunden, bevor ich zur Passwortabfrage komme. Warum ist das so?
Ich führe es aus 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 problemlos.
mein resolv.confsieht aus wie
domain <mydomain>.edu
nameserver <dns ip address>
Die Firewall wird von gesteuert 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
Und nicht zuletzt erhält auch ein Kollege, der ebenfalls einen Account auf dem gleichen System hat, sofort die Eingabeaufforderung!
Antwort1
Wie in den Kommentaren angegeben, liegt dies wahrscheinlich an der UseDNS yesEinstellung auf sshd_configdem Server.
Die UseDNSEinstellung ist häufig die Ursache für genau dieses Problem. Im Grunde genommen ist Ihr IP-Netzblock entweder defekt oder weist einen fehlenden DNS-Server auf. Daher versucht sshd, eine umgekehrte Suche nach Ihrer IP-Adresse durchzuführen und wartet, bis die Zeit abgelaufen ist. Andere Benutzer erleben die Verzögerung nicht, da sie einen funktionierenden DNS-Server für ihren Netzblock haben.
Die meisten Leute deaktivieren diese Einstellung aus genau diesem Grund. Obwohl die Einstellung aus Sicherheitsgründen vorhanden ist,es ist ziemlich nutzlos.
Die Lösung besteht einfach darin, Folgendes festzulegen sshd_config:
UseDNS no