Сбой входа в систему SSH после обновления / перезагрузки на сервере Ubuntu 16.04 на Raspberry Pi 3B

Question

У меня нет монитора, поэтому я пытаюсь сделать это по всему SSH.

Я использую образ Ubuntu Classic Server 16.04 от Ubuntu Pi Flavor Maker. Я записываю SD-карту, подключаю Ethernet к беспроводному маршрутизатору, а затем загружаю RPI. Я вхожу через ssh, используя имя пользователя ubuntu и пароль ubuntu а затем меняю пароль. В этот момент я могу выполнить sudo reboot и через несколько секунд вернуться в ssh, используя новые учетные данные.

Однако после того, как я установил aptitude и запустил

aptitude update
aptitude upgrade
sudo reboot

Я не могу войти через ssh. Rpi по-прежнему находит маршрутизатор и подключается. Я могу пропинговать rpi, и порт 22, кажется, слушает (см. Ниже). Я просто не могу войти.

Вот некоторые диагностики:

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 ubuntu@192.168.1.5
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

Ошибка TCP «тайм-аут операции» означает, что клиент отправил попытку подключения TCP на IP-адрес сервера, но сервер так и не ответил. Общие причины этого:

1. Какой-то фильтр пакетов (он же брандмауэр) блокирует связь между клиентом и сервером.
2. Сервер, к которому вы пытаетесь подключиться, отключен, отключен от сети или не использует IP-адрес, который, по вашему мнению, должен использоваться.

"Отфильтрованное" состояние nmap указывает на то, что существует какой-то фильтр пакетов (брандмауэр), блокирующий ваши попытки подключения:

отфильтрованный
Nmap не может определить, открыт ли порт, потому что фильтрация пакетов препятствует тому, чтобы его зонды достигли порта. Фильтрация может осуществляться с выделенного устройства брандмауэра, правил маршрутизатора или программного обеспечения брандмауэра на основе хоста. Эти порты расстраивают злоумышленников, потому что они предоставляют так мало информации. Иногда они отвечают сообщениями об ошибках ICMP, такими как код 13 типа 3 (пункт назначения недоступен: связь административно запрещена), но фильтры, которые просто отбрасывают зонды без ответа, встречаются гораздо чаще.

Nmap говорит, что сервер подключен к сети. Таким образом, самое простое объяснение состоит в том, что какой-то фильтр пакетов блокирует соединение SSH. Если это работало до того, как вы запустили aptitude, я предполагаю, что aptitude мог установить, активировать и / или перенастроить фильтр пакетов, запущенный на Pi.

Другая возможность может заключаться в том, что Pi пришел с неправильным IP-адресом или ему не удалось правильно настроить сетевой интерфейс, и у него нет IP-адреса.