ritardare per ottenere la richiesta della password quando si invia a un server pubblico

ho un server (debian 7) installato nella mia università con IP pubblico. quando entro nel sistema (dall'esterno del campus), ricevo uno strano ritardo di 5-10 secondi prima di ricevere la richiesta della password. Perché?

Corro ssh -vper ottenere un output dettagliato:

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

quindi ricevo bene la richiesta della password.

il mio resolv.confsembra

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

il firewall è controllato da webmine la configurazione /etc/webmin/firewall/iptables.saveè simile a:

# 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

Ultimo ma non meno importante, un collega che ha anche un account sullo stesso sistema riceve immediatamente la richiesta!

— Nass
fonte

Il primo pensiero è che il server sia UseDNS yesabilitato. Questo è noto per rallentare gli accessi. A parte questo, dovremmo vedere i log di debug del server ( $(which sshd) -d).

— Patrick,

@Patrick, sembra essere lì per una buona ragione. Ma perché rallenta il dowm del mio login, ma non i miei colleghi?

— nass

Perché pensi che sia lì per una buona ragione? È del tutto probabile che ci sia perché nessuno ha mai pensato di spegnerlo. E probabilmente ti rallenta perché il server DNS autorevole per il tuo netblock è morto o mancante.

— Patrick,

@Patrick bene, non esegue questo controllo per motivi di sicurezza?

— nass

@Patrick tra questo risolto il problema, quindi potresti anche scrivere questo come una risposta

— nass

Come indicato nei commenti, ciò è probabilmente causato UseDNS yesdall'impostazione sshd_configsul server.

L' UseDNSimpostazione è un colpevole comune proprio per questo problema. Fondamentalmente ciò che accade è che il tuo netblock IP ha un server DNS difettoso o mancante. Quindi sshd sta cercando di fare una ricerca inversa sul tuo indirizzo IP, e aspetta che scada. Altre persone non subiscono il ritardo poiché dispongono di un server DNS funzionale per il loro netblock.

La maggior parte delle persone disattiva questa impostazione proprio per questo motivo. Sebbene sì, l'impostazione è lì per sicurezza, è praticamente inutile .

La soluzione è semplicemente impostare quanto segue in sshd_config:

UseDNS no

— Patrick
fonte

solo una nota: sshd_configin debian 7 arriva senza questa clausola nel file di configurazione. Bisogna

— scriverlo