Ubuntu 16.04 ssh em uma LAN falha com “conexão recusada”

0

Eu tenho um desktop e laptop em uma mesma LAN, ambos executando o Ubuntu 16.04 x64. Ambos têm o openssh e o openssh-server instalados e em execução. Em ambos os ssh 'para localhost funciona perfeitamente, e em nenhum dos ssh a outra máquina funciona, falhando com connection refused . Para ser mais preciso, ssh [email protected] leva ao mesmo erro, embora o ip seja uma das máquinas que estou experimentando. Cada máquina pode ping o outro. Ambos estão usando chaves públicas para autenticação. sftp , telnet e ssh-copy-id todos falharam com o mesmo erro. Para o melhor de minha capacidade eu tentei verificar que nenhum firewall em qualquer uma das máquinas está bloqueando o tráfego ssh (mas testes adicionais aqui são bem-vindos).

O que eu posso estar fazendo de errado e como posso consertar esse problema?

Eu ficaria feliz em fornecer saídas para quaisquer verificações relevantes.

    
por Chiffa 11.07.2016 / 02:05

2 respostas

1

Descobri que a maneira mais fácil de resolver problemas de conexão ssh é usar o modo de depuração dos aplicativos cliente e servidor.

Em uma máquina, vamos chamá-la de pcA, abrir um terminal e executar o seguinte comando:

/usr/sbin/sshd -d -p 2222

Na outra máquina linux, pcB, digite este comando e veja a saída do servidor no pcA:

ssh -vv -p 2222 [IP Address of pcA]

O que estamos fazendo aqui é executar uma versão 'em primeiro plano' do daemon ssh no pcA, ouvindo as conexões na porta 2222, executando no modo de depuração (detalhado). No pcB, estamos tentando conectar-se ao pcA como um cliente ssh na porta 2222, no modo detalhado.

  • O pcA e o pcB exibirão o texto indicando o fluxo do processo de conexão como eles o vêem.

  • Tipicamente, os resultados são suficientes para tornar a resolução óbvia, e. permissões no seu diretório ~ / .ssh.

    Algumas dicas:

    Se o servidor não obtiver absolutamente nenhuma tentativa de conexão do pcB, você terá um problema de firewall ou de roteamento de rede de algum tipo. Nesse caso, tente uma varredura de rede na mesma porta do pcB usando o nmap: nmap -p 2222 [ip address pcA]

    Você também pode chamar o nmap com a sintaxe nmap -A [ip address pcA] para fazer uma varredura geral (incluindo a porta std sshd (22) e informações do traceroute. Isso pode indicar onde as coisas estão caindo (firewall do roteador?)

  • Se não for óbvio, poste os resultados do cliente e do servidor na sua pergunta.

Atualizar

Execute o comando netstat -tulpn no pcA para ver o que está escutando em quais portas na máquina. Isso lhe dará uma saída assim:

Proto Recv-Q  Send-Q   Local Address       Foreign Address      State    PID/Program name
tcp     0       0      0.0.0.0:22            0.0.0.0:*          LISTEN     1133/sshd
tcp6    0       0      :::22                 :::*               LISTEN     1133/sshd
udp     0       0      0.0.0.0:68            0.0.0.0:*                     722/dhclient

Se você executá-lo e o sshd estiver sendo executado normalmente na porta 22. Poste o que você obtém em resposta a esse comando no pcA.

2ª atualização Viu sua resposta - o que era ListenAddress definido como antes? Normalmente, o padrão é 0.0.0.0 (que é QUALQUER endereço) e não há problemas com isso.

    
por 11.07.2016 / 02:27
0

Ok, acabei de adicionar manualmente as ip s das minhas máquinas às ListenAddress linhas de /etc/ssh/sshd_config . Prós:     Eu posso finalmente ssh. Contras:     Isso é provavelmente um hack terrível e não escalável; Se alguma vez eu precisar de ssh em minhas máquinas, fora da LAN, provavelmente vou me deparar com problemas reais.

    
por 11.07.2016 / 03:04

Tags