Servidor SSH não responde a solicitações de conexão

Estou tentando configurar um servidor SSH na minha máquina local usando o OpenSSH. Quando tento fazer 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 correção realmente óbvia para isso que estou simplesmente ignorando.

Aqui está o que acontece quando tento fazer o SSH de um 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

Onde robotsestá meu host remoto e 99.3.26.94meu servidor SSH local.

SSH está em execução

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

Onde arnoldestá 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 Apache. Porta 22 - nem tanto.

NMap diz que está 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 robotsestá meu host remoto e 99.3.26.94meu 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 instalado - é um netinst Debian relativamente novo.

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

Edição: solicitação de conexão de erro de rede interna

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

Uma resposta muito decepcionante

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

Então, qual foi o problema?

Nenhuma configuração foi alterada ou ajustada - nem no roteador, nem no servidor SSH nem na máquina do cliente SSH. É bastante seguro dizer que o roteador não está lidando adequadamente com o tráfego recebido, apesar das configurações adequadas. Como o software de roteador doméstico não é realmente projetado para lidar com o encaminhamento de portas, o pobre rapaz demorou um pouco para implementar as alterações necessárias.

Mas já faz 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 errado. Evidentemente, pode levar 6 horas - possivelmente mais - para que as configurações do roteador entrem em vigor.

Então, como sei se esse é o meu problema?

Uma ferramenta bacana que me deparei durante essa escapada é tcpdump. Esse carinha magro cheira o tráfego para você, oferecendo informações valiosas sobre o que realmente está acontecendo. Além disso, ele tem alguns recursos de superfiltragem que permitem restringir exatamente o que você deseja procurar. Por exemplo, o comando:

tcpdump -i wlan1 port 22 -n -Q inout

Diz tcpdumppara olhar para o tráfego através da interface wlan1 ( -i'interface' =), apenas através da porta 22, ignorar a resolução de DNS nome ( -n= 'nenhuma resolução name'), e queremos ver o tráfego de entrada e de saída ( -Qaceita in, outou inout; inouté o padrão).

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

1. Se você estiver vendo tráfego de entrada da máquina remota, mas não houver tráfego de saída do servidor local, o problema está no servidor: provavelmente há uma regra de firewall que precisa ser alterada etc.
2. Se você está vendo tanto a entrada quanto a saída , mas sua máquina remota não está recebendo a resposta, provavelmente é o roteador: está permitindo o tráfego de entrada, mas eliminando os pacotes de saída.
3. Se não houver tráfego , provavelmente isso também é um problema do roteador: os SYNpacotes da máquina remota estão sendo ignorados e descartados pelo roteador antes mesmo de chegarem ao servidor.

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

Estou executando o Mint (Ubuntu).

Eu tinha feito tudo ... chave pública no formato correto, em keys_chave autorizadas, chmodding, chowning, reiniciando ssh e sshd etc. Como tudo foi documentado em todo o lugar.

Para mim, era o firewall ufw. A falta de resposta ssh me levou a isso, mas não consegui resolver nenhum problema nos dois sentidos em uma LAN.

Eu testei por:

sudo ufw service stop

... e funcionou perfeitamente, ou seja, recebi uma resposta de uma chamada ssh.

Então, inicie o ufw novamente:

sudo ufw service start

... e adicione a regra:

sudo ufw allow openssh

Tudo funcionando bem agora.

Se você, como eu, ativou o UFW (no Linux, Ubuntu no meu caso), tente o seguinte:

sudo ufw enable OpenSSH

Isso permitirá o OpenSSH no firewall.

Apenas para outros:

Eu tive que usar a opção -P no tcpdump em vez de -Q

tcpdump -i wlan1 port 22 -n -P inout

Na maioria das vezes, o firewall é um culpado. Faça service iptables stope service ip6tables stop.

Se a interrupção do serviço não funcionar, execute o iptable flush.

iptables --flush.

Se for uma VM, faça o mesmo no host também