Il server SSH non risponde alle richieste di connessione

Sto tentando di configurare un server SSH sul mio computer locale utilizzando OpenSSH. Quando provo a SSH da un host remoto nel mio server SSH locale, il server SSH non risponde e la richiesta scade. Sono abbastanza sicuro che ci sia una soluzione davvero ovvia per questo che sto semplicemente trascurando.

Ecco cosa succede quando provo a SSH da un host remoto:

yoshimi@robots:/$ ssh -vv volt@99.3.26.94
OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 99.3.26.94 [99.3.26.94] port 22.
debug2: fd 3 setting O_NONBLOCK
debug1: connect to address 99.3.26.94 port 22: Connection timed out
ssh: connect to host 99.3.26.94 port 22: Connection timed out

Dov'è il robotsmio host remoto ed 99.3.26.94è il mio server SSH locale.

SSH è in esecuzione

volt@arnold:~$ ps -A | grep sshd
 5784 ?        00:00:00 sshd

Dov'è il arnoldmio server SSH locale.

Il port forwarding è impostato sul router

Ho il mio router di casa configurato per inoltrare le porte 80 e 22 al mio server SSH. È interessante notare che la porta 80 ha funzionato senza intoppi - va direttamente alla directory web di Apache. Porta 22 - non così tanto.

NMap dice che è filtrata

yoshimi@robots:/$ nmap -p 22 99.3.26.94

Starting Nmap 6.47 ( http://nmap.org ) at 2015-06-02 14:45 EDT
Nmap scan report for 99-3-26-94.lightspeed.bcvloh.sbcglobal.net (99.3.26.94)
Host is up (0.33s latency).
PORT   STATE    SERVICE
22/tcp filtered ssh

Nmap done: 1 IP address (1 host up) scanned in 7.59 seconds

Dov'è il robotsmio host remoto ed 99.3.26.94è il mio server SSH locale.

Non è IPTables (penso)

volt@arnold:~$ sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
fail2ban-ssh  tcp  --  anywhere             anywhere             multiport dports ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain fail2ban-ssh (1 references)
target     prot opt source               destination         
RETURN     all  --  anywhere             anywhere            

... E non ho altri firewall in atto - è un netinst Debian relativamente fresco.

Quindi, allora: cos'altro potrebbe essere? Sembra certamente essere una sorta di firewall-y qualcosa per ignorare il traffico, ma se non è il router, non è iptables e non è un altro firewall sul server SSH, ... che diamine c'è altro ??

EDIT: richiesta di connessione dall'errore di rete interno

yoshimi@robots:/$ ssh volt@192.168.1.90
ssh: connect to host 192.168.1.90 port 22: No route to host

Un'auto-risposta molto deludente

Avendo messo da parte questo problema per un giorno e tornato su di esso, ero sia sollevato che turbato (più turbato che sollevato) per scoprire che tutto, misteriosamente, funzionava correttamente.

Quindi, qual era il problema?

Nessuna impostazione è stata modificata o modificata: non sul router, non sul server SSH e non sulla macchina del client SSH. È abbastanza sicuro dire che era il router che non gestiva correttamente il traffico in entrata, nonostante le impostazioni corrette. Dato che il software del router domestico non è progettato per gestire il port forwarding, il povero ragazzo ha impiegato un po 'di tempo per implementare le modifiche necessarie.

Ma è stato come 6 ore !!

Sì amico, lo so. Ho passato tutto il giorno a cercare di capire cosa non andava e non l'ho mai trovato perché non c'era niente di sbagliato. Evidentemente, possono essere necessarie 6 ore, forse di più, per rendere effettive le impostazioni del router.

Quindi, come faccio a sapere se questo è il mio problema?

Uno strumento elegante che ho trovato durante questa scappatella è tcpdump. Questo ragazzino magro ti annusa il traffico, offrendo preziose informazioni su ciò che sta realmente accadendo. Inoltre, ha alcune funzioni di super filtro che ti consentono di restringere esattamente ciò che vuoi cercare. Ad esempio, il comando:

tcpdump -i wlan1 port 22 -n -Q inout

Dice tcpdumpdi cercare il traffico attraverso l'interfaccia wlan1 ( -i'interfaccia' =), solo attraverso la porta 22, ignorare la risoluzione DNS nome ( -n= 'no risoluzione dei nomi'), e vogliamo vedere sia il traffico in entrata e in uscita ( -Qaccetta in, outo inout; inoutè l'impostazione predefinita).

Eseguendo questo comando sul tuo server SSH mentre provi a connetterti tramite una macchina remota, diventa rapidamente chiaro dove si trova esattamente il problema. Esistono essenzialmente 3 possibilità:

1. Se stai vedendo traffico in entrata dal computer remoto, ma nessun traffico in uscita dal tuo server locale, il problema risiede nel server: probabilmente c'è una regola del firewall che deve essere modificata, ecc.
2. Se vedi sia in entrata che in uscita , ma il tuo computer remoto non sta ricevendo la risposta, è molto probabile che il router: consenta il traffico in entrata, ma rilasci i pacchetti in uscita.
3. Se non c'è traffico , probabilmente è anche un problema del router: i SYNpacchetti della macchina remota vengono ignorati e rilasciati dal router prima ancora che raggiungano il tuo server.

E una volta scoperto dove si trova il problema, una correzione è (di solito) banale.

Sto eseguendo Mint (Ubuntu).

Avevo fatto di tutto ... chiave pubblica nel formato corretto in authorized_keys, chmodding, chowning, riavvio di ssh e sshd ecc. Come è stato documentato dappertutto.

Per me era il firewall ufw. La mancanza di qualsiasi risposta ssh mi ha portato a questo, eppure su una LAN non ho potuto fare nessun problema in entrambi i modi.

Ho testato da:

sudo ufw service stop

... e ha funzionato perfettamente, cioè ho ricevuto una risposta da una chiamata SSH.

Quindi, ricominciare:

sudo ufw service start

... e aggiungi la regola:

sudo ufw allow openssh

Ora funziona tutto bene.

Se, come me, hai abilitato UFW (su Linux, Ubuntu nel mio caso), prova questo:

sudo ufw enable OpenSSH

Ciò consentirà OpenSSH nel firewall.

Solo per gli altri:

Ho dovuto usare l'opzione -P in tcpdump invece di -Q

tcpdump -i wlan1 port 22 -n -P inout

Il più delle volte il firewall è un colpevole. Fare service iptables stope service ip6tables stop.

Se l'arresto del servizio non funziona, eseguire iptable flush.

iptables --flush.

Se è una macchina virtuale, fai lo stesso anche nell'host