Por que o Ubuntu não pode acessar meu Raspberry Pi pela LAN?

Question

Ok, recentemente recebi um Raspberry Pi e o conectei à minha rede Wi-Fi - habilitei o SSH e instalei o Hiawatha, e consegui acessá-lo da minha área de trabalho, que estava executando o Puppy Linux na época .

Eu também poderia acessá-lo muito bem quando inicializado no Windows (PuTTY no Win XP Pro), e o Netbook poderia acessá-lo via PuTTY, também. (Win 7 Starter)

No entanto, quando iniciei no Ubuntu, todas as conexões SSH, HTTP e HTTPS foram recusadas. Para confirmar que era o Ubuntu, e apenas o Ubuntu, que estava tendo problemas de conexão, eu reiniciei o Puppy Linux - bem conectado, e conectei bem com o Windows. O Netbook pode se conectar a todos os três serviços sem problemas. Foi apenas o Ubuntu que disse que a conexão foi recusada.

Gostaria de saber o que está errado - já fiz toda a solução básica de problemas: reinicializar o RPi, reinicializar meu computador, reinicializar o roteador sem fio, etc. O Raspberry Pi não tem Firewall habilitado e meu roteador oferece dispositivos conectados ao acesso irrestrito da LAN uns aos outros. Eu fiz testes extensivos , e o Ubuntu provou ser, sem sombra de dúvida, o único que não está disposto a se conectar.

ATUALIZAÇÃO: Acabei de testar o acesso através do meu IP externo e tudo funciona perfeitamente no Ubuntu! No entanto, o Ubuntu ainda não pode acessar o Pi de nada local, e eu apenas re-confirmou que o meu outro sistema operacional pode . Eu acho estranho que o Ubuntu tenha problemas para se conectar localmente (diferentemente dos meus outros sistemas operacionais), mas está bem acessando o Pi através do meu IP externo ...

UPDATE 2: A desativação do meu firewall permite que eu acesse o dispositivo, mas a senha é reportada como incorreta a cada . único . tempo . Eu tentei digitá-lo no Gedit, depois arrastá-lo e soltá-lo no prompt de senha durante o login do SSH, e ele autoriza ao acessar [email protected] , mas NÃO ao acessar [email protected] . Isso é inacreditavelmente frustrante.

    

Answer 1

Então, até que você tenha ufw habilitado com configurações padrão na sua máquina Ubuntu, a conexão sempre reportou Connection refused . Depois que você desativou o ufw em seu cliente, a conexão é estabelecida, mas a senha é sempre rejeitada?

Eu acho que, nesse caso, seu problema é que o 192.168.2.128 ip é roteado de volta para sua máquina cliente Ubuntu, e na verdade você está se conectando ao servidor ssh em execução na sua máquina Ubuntu. Isso explicaria:

• Por que você consegue se conectar a partir da Internet.

• Por que sua conexão foi rejeitada quando o firewall estava ligado no seu cliente Ubuntu.

• Por que a conexão não é mais rejeitada com o firewall do cliente desativado.

• Por que agora a conexão é estabelecida, mas a autenticação falha.

Para solucionar esse caso:

• Verifique a chave do host do servidor com ssh -v [email protected] para uma conexão local e para a Internet. Ele informa a mesma chave?

• Ou enquanto você estiver se conectando localmente, e estiver no prompt para digitar sua senha, em outro terminal: sudo netstat -tupan e veja se uma conexão foi estabelecida com o sshd no seu Ubuntu.

Embora este caso explique tudo, mas é tão estranho que eu duvido que isso seja problema seu.

    

Answer 2

É perfeitamente possível que sua máquina Ubuntu esteja recebendo um endereço IP de rede diferente do esperado. Tente o seguinte:

• No raspi, verifique seu endereço IP com ifconfig | grep 192.168
• na máquina do ubuntu, verifique seu endereço IP com ifconfig | grep 192.168

Para poder falar uns com os outros em sua rede local, eles devem estar usando a mesma sub-rede - veja a terceira seção do endereço IP para ver se eles estão. No seu caso, ambos devem estar na sub-rede 192.168.2. *.

Verifique se eles realmente têm endereços IP diferentes . Isso pode parecer óbvio, mas pode acontecer se um deles estiver usando DHCP e o outro estiver definido estaticamente.

Se tudo isso for feito, execute o seguinte comando para ver onde os pacotes devem estar:

route -n

Procure na saída da sub-rede de destino que se aplica ao seu pi de framboesa. Deve haver apenas 3 linhas:

Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.0.1     0.0.0.0         UG    0      0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     1000   0        0 eth0
192.168.0.0     0.0.0.0         255.255.255.0   U     1      0        0 eth0

Se você tem mais linhas ou coisas estão indo para pontos estranhos, então essa é a resposta.

Meu palpite é que sua conexão ssh está chegando a um servidor SSH diferente daquele em seu pi framboesa, e é por isso que mudar o firewall ubuntu o afetou e seus logins não estão funcionando.

    

Answer 3

De acordo com o que está no seu PasteBin, a "conexão recusada" indica que você está recebendo uma redefinição TCP de qualquer endereço IP.

Verificação de integridade: durante a solução de problemas, DISABLE ufw.

Com o seu firewall de desktop desabilitado, você pode fazer ping no Pi a partir do seu desktop? Você pode fazer ping na área de trabalho do seu Pi?

Depois de tentar o ping nas duas direções, observe a saída de 'arp -n' nas duas máquinas. Eles vêem os endereços MAC (Ethernet Ethernet) uns dos outros ou estão redirecionando / interceptando o tráfego?

Se você puder fazer ping nas duas direções e 'arp -n' indicar que os endereços MAC apropriados estão sendo usados (verifique 'ifconfig' na máquina oposta), o próximo passo é examinar /var/log/auth.log em o PI. Deve dizer-lhe o que há de errado com a tentativa de conexão.

Se o acima não ajudar, mostre a saída dos seguintes comandos no Pi:

sudo ifconfig -a
cat /etc/resolv.conf
arp -n
netstat -rn
sudo iptables-save
sudo grep ssh /var/log/auth.log | tail -50

E na sua área de trabalho:

sudo ifconfig -a
cat /etc/resolv.conf
arp -n
netstat -rn
sudo iptables-save

Eu vejo um pouco disso colado nos comentários acima, mas a coisa toda é importante para pegar com o firewall desligado primeiro. Se você puder fazê-lo funcionar com o firewall desativado, poderá prosseguir com a solução de suas regras de firewall.

Além disso, mesmo que você esteja segmentando um endereço IP, as configurações DNS ainda são importantes porque o SSH usa o DNS durante a validação da chave do host.

    

Answer 4

Apague o arquivo ~/.ssh/known_hosts e tente novamente. Se anteriormente havia um host com o mesmo endereço IP ssh acessível, você pode manter uma impressão digital inválida

    

Answer 5

No Ubuntu 13.10, não consegui ssh para o meu pi, quando anteriormente eu podia no 13.04 e no Mint 16. Ao tentar

ssh -vvv user@host

Eu tenho:

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

Eu encontrei uma sugestão que dizia para definir MTU para a Máquina (não o pi) para 1200 em vez de automático. Eu fiz isso, desligado - > então no meu wifi, e conectado com ssh para PI na primeira tentativa. Espero que isso ajude alguém.