O servidor SSH não está respondendo à solicitação de conexão

Question

Estou tentando configurar um servidor SSH em minha máquina local usando o OpenSSH. Quando eu tento o SSH de um host remoto para o meu servidor SSH local, o servidor SSH não responde e a solicitação expira. Tenho certeza de que há uma solução óbvia para isso que simplesmente estou negligenciando.

Veja o que acontece quando tento acessar o SSH a partir de um host remoto:

yoshimi@robots:/$ ssh -vv [email protected]
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

Onde robots é meu host remoto e 99.3.26.94 é meu servidor SSH local.

O SSH está em execução

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

Onde arnold é o meu servidor SSH local.

O encaminhamento de porta está configurado no roteador

Eu tenho meu roteador doméstico configurado para encaminhar as portas 80 e 22 para o meu servidor SSH. Curiosamente, a porta 80 funcionou sem problemas - vai direto para o diretório da web do Apache. Port 22 - não tanto.

NMap diz que é filtrado

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

Onde robots é meu host remoto e 99.3.26.94 é meu servidor SSH local.

Não é IPTables (eu acho)

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 eu não tenho nenhum outro firewall no lugar - é um netinst relativamente fresco do Debian.

Então, então: O que mais poderia ser? Certamente parece ser uma coisa do tipo firewall apenas ignorar o tráfego, mas se não é o roteador, não é iptables, e é não outro firewall no servidor SSH, ... o que diabos existe?

EDIT: saída do servidor NetStat

Do servidor SSH:

tcp6       0      0 :::22                   :::*                    LISTEN      5784/sshd       

    

Answer 1

Uma auto-resposta muito decepcionante

Tendo deixado esse problema de lado por um dia e voltado para ele, fiquei ao mesmo tempo aliviado e perturbado (mais perturbado do que aliviado) ao descobrir que tudo estava, misteriosamente, funcionando apropriadamente.

Então, qual foi o problema?

Nenhuma configuração foi alterada ou ajustada - não no roteador, não no servidor SSH e não na máquina do cliente SSH. É bastante seguro dizer que o roteador não está manipulando o tráfego de entrada corretamente, apesar das configurações adequadas. Dado que o software de roteador doméstico dinky não é realmente projetado para lidar com o encaminhamento de porta, levou o pobre rapaz um tempo para implementar as mudanças necessárias.

Mas tem sido como 6 horas !!

Sim cara, eu sei. Passei o dia todo tentando descobrir o que estava errado - e nunca o encontrei porque não havia nada de errado. Evidentemente, pode levar 6 horas - possivelmente mais - para que as configurações do roteador entrem em vigor.

Então, como eu sei se esta é a minha questão?

Uma ferramenta bacana que encontrei durante essa escapada é tcpdump . Esse rapazinho magro fareja o tráfego para você, oferecendo informações valiosas sobre o que realmente está acontecendo. Além disso, ele tem alguns recursos de super filtragem que permitem que você diminua exatamente o que você quer ver. Por exemplo, o comando:

tcpdump -i wlan1 port 22 -n -Q inout

Informa tcpdump para procurar tráfego por meio da interface wlan1 ( -i = 'interface'), somente pela porta 22, ignorar a resolução de nomes DNS ( -n = 'sem resolução de nomes') e queremos veja o tráfego de entrada e de saída ( -Q aceita in , out ou inout ; inout é o padrão).

Ao executar este comando no seu servidor SSH ao tentar se conectar através de uma máquina remota, fica rapidamente claro onde está o problema. Existem, essencialmente, 3 possibilidades:

1. Se você estiver vendo o tráfego recebido da máquina remota, mas o tráfego sem saída do servidor local, o problema está no servidor: provavelmente há uma regra de firewall que precisa ser mudado, etc.
2. Se você está vendo entrada e saída , mas sua máquina remota não está recebendo a resposta, é mais provável que o roteador: esteja permitindo o tráfego de entrada, mas descartando seus pacotes de saída.
3. Se não houver nenhum tráfego , isso provavelmente também é um problema do roteador: os pacotes SYN da máquina remota estão sendo ignorados e descartados pelo roteador antes mesmo de chegarem ao seu servidor.

E uma vez que você descobriu onde está o problema, uma correção é (geralmente) trivial.