☰

Servidor SSH não responde à solicitação de conexão

tag-icon • tag-icon linux networking ssh firewall openssh
Servidor SSH não responde à solicitação de conexão

Estou tentando configurar um servidor SSH em minha máquina local usando OpenSSH. Quando tento fazer SSH de um host remoto em meu servidor SSH local, o servidor SSH não responde e a solicitação atinge o tempo limite. Tenho certeza de que há uma soluçã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 [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 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á meu servidor SSH local.

O encaminhamento de porta está configurado no roteador

Tenho meu roteador doméstico configurado para encaminhar as portas 80 e 22 para meu servidor SSH. Curiosamente, a porta 80 funcionou sem problemas - vai direto para o diretório web do 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:O que mais poderia ser?Certamente parece ser um tipo de firewall para simplesmente ignorar o tráfego, mas se não for o roteador, não é o iptables e não é outro firewall no servidor SSH, ... o que diabos mais existe ??

EDIT: Saída do servidor NetStat

Do servidor SSH:

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

Responder1

Uma auto-resposta muito decepcionante

Depois de deixar esse problema de lado por um dia e voltar 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 era 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 lidou adequadamente com o tráfego de entrada, apesar das configurações adequadas. Dado que o pequeno software de roteador doméstico não érealmenteprojetado para lidar com encaminhamento portuário, o coitado demorou um pouco para implementar as mudanças necessárias.

Mas já se passaram cerca de 6 horas!!

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

Então, como posso saber se este é o meu problema?

Uma ferramenta bacana que encontrei durante essa escapada é tcpdump. Esse carinha enxuto fareja 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 ver. Por exemplo, o comando:

tcpdump -i wlan1 port 22 -n -Q inout

Diz tcpdumppara procurar tráfego através da interface wlan1 ( -i= 'interface'), apenas através da porta 22, ignorar a resolução de nomes DNS ( -n= 'sem resolução de nomes') e queremos ver o tráfego de entrada e saída ( -Qaceita in, out, ou inout; inouté o padrão).

Ao executar este comando em seu servidor SSH ao tentar se conectar por meio de uma máquina remota, rapidamente fica claro onde está exatamente o problema. Existem, essencialmente, 3 possibilidades:

  1. Se você está vendoentradatráfego da máquina remota, massem saídatráfego do seu servidor local, o problema está no servidor: provavelmente há uma regra de firewall que precisa ser alterada, etc.
  2. Se você está vendotanto de entrada quanto de saída, mas sua máquina remota não está recebendo a resposta, provavelmente é o roteador: ele está permitindo o tráfego de entrada, mas descartando os pacotes de saída.
  3. Se houversem trânsito, provavelmente 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 de descobrir onde está o problema, uma solução é (geralmente) trivial.

informação relacionada