O login SSH falha após a atualização / reinicialização no servidor Ubuntu 16.04 no Raspberry Pi 3B

Question

Eu não tenho um monitor, então estou tentando fazer isso em todo ssh.

Estou usando a imagem do Ubuntu Classic Server 16.04 do Ubuntu Pi Flavor Maker . Eu queimo o cartão SD, ethernet o rpi para o meu roteador sem fio e, em seguida, inicializar o rpi. Efetuo login via ssh usando o nome de usuário ubuntu e a senha ubuntu e, em seguida, altero a senha. Nesse ponto, posso fazer sudo reboot e, em alguns instantes, ssh voltar usando as novas credenciais.

No entanto, depois de instalar aptitude e executar

aptitude update
aptitude upgrade
sudo reboot

Não consigo fazer login novamente via ssh. O rpi ainda encontra o roteador e se conecta. Eu posso pingar o rpi e a porta 22 parece estar ouvindo (veja abaixo). Eu simplesmente não consigo entrar novamente.

Aqui estão alguns diagnósticos:

balter@BICB260:~$ sudo nmap -sS -Pn -p 22 192.168.1.5
Password:

Starting Nmap 7.50 ( https://nmap.org ) at 2017-06-25 13:19 PDT
Nmap scan report for 192.168.1.5
Host is up (0.0013s latency).

PORT   STATE    SERVICE
22/tcp filtered ssh
MAC Address: B8:27:EB:04:4A:F0 (Raspberry Pi Foundation)

Nmap done: 1 IP address (1 host up) scanned in 0.37 seconds
balter@BICB260:~$ ping 192.168.1.5
PING 192.168.1.5 (192.168.1.5): 56 data bytes
64 bytes from 192.168.1.5: icmp_seq=0 ttl=64 time=1.990 ms
64 bytes from 192.168.1.5: icmp_seq=1 ttl=64 time=1.528 ms
64 bytes from 192.168.1.5: icmp_seq=2 ttl=64 time=2.085 ms
64 bytes from 192.168.1.5: icmp_seq=3 ttl=64 time=2.024 ms
^C
--- 192.168.1.5 ping statistics ---
4 packets transmitted, 4 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 1.528/1.907/2.085/0.221 ms
balter@BICB260:~$ ssh -vvv [email protected]
OpenSSH_6.9p1, LibreSSL 2.1.8
debug1: Reading configuration data /Users/balter/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: /etc/ssh/ssh_config line 56: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to 192.168.1.5 [192.168.1.5] port 22.
debug1: connect to address 192.168.1.5 port 22: Operation timed out
ssh: connect to host 192.168.1.5 port 22: Operation timed out 

    

Answer 1

O erro TCP "tempo de operação esgotado" significa que o cliente enviou uma tentativa de conexão TCP ao endereço IP do servidor, mas o servidor nunca respondeu. Causas comuns para isso são:

1. Algum tipo de filtro de pacotes (também conhecido como firewall) está bloqueando a comunicação entre o cliente e o servidor.
2. O servidor que você está tentando acessar está inativo, desconectado da rede ou não está usando o endereço IP que você acha que deveria estar usando.

O estado "filtrado" do nmap indica que existe algum tipo de filtro de pacotes um firewall) bloqueando suas tentativas de conexão:

filtered
Nmap cannot determine whether the port is open because packet filtering prevents its probes from reaching the port. The filtering could be from a dedicated firewall device, router rules, or host-based firewall software. These ports frustrate attackers because they provide so little information. Sometimes they respond with ICMP error messages such as type 3 code 13 (destination unreachable: communication administratively prohibited), but filters that simply drop probes without responding are far more common.

O Nmap diz que o servidor está ativo e conectado à rede. Portanto, a explicação mais simples é que algum tipo de filtro de pacotes está bloqueando a conexão SSH. Se isto estava funcionando antes de você executar o aptitude, meu palpite é que o aptitude pode ter instalado, ativado e / ou reconfigurado um filtro de pacotes rodando no Pi.

Outra possibilidade pode ser que o Pi tenha aparecido usando o endereço IP errado, ou que tenha falhado em configurar sua interface de rede corretamente e não tenha um endereço IP.