SSH-соединение не установлено, но стандартное TCP / IP-соединение работает
Я работаю над настраиваемым yocto Linux для Raspberry PI 3 и пытаюсь заставить соединение WIFI работать с SSH Однако при попытке подключиться с моего ПК (Ubuntu 19.10, SSH OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c 28 мая 2019 г.) к PI, на котором работает Dropbear v2019.78, время попытки подключения истекает. Но только когда я попробуйте это через SSH и через wlan0 . Другой трафик TCP / IP работает и также использует тех же участников, но с eth0 . Поскольку это для робота, я бы предпочел не хотя использовать привязку ...
Чтобы попробовать и отладить это, я
- включил последовательную консоль, чтобы я мог работать с отключенным PI
- , eth0
- запустил tcpdump на PI (ip.host = = 192.168.0.105)
- запустил tcpdump на ПК (ip.host == 192.168.0.106)
- использовал простой пример сокета TCP / IP, написанный на Python (взято из https: // realpython.com/python-sockets/#echo-server[119518 7]) для проверки я действительно могу общаться. Передача прошла успешно. Я знаю, что пример отсутствует (нет надлежащего протокола и т. Д.), Но дело не в этом. Этого просто достаточно. PI запускает сервер, прослушивающий порт 2222.
- попытался установить SSH-соединение, время ожидания истекло.
Я отфильтровал результирующий PCAP, чтобы он содержал только TCP, поскольку есть другая информация (например, обнаружение Dropbox), которую я не делаю. не думаю, что имеет значение и потенциально может быть утечка информации. На стороне хоста (enp4s0-tcp-and-pi.pcap) я также отфильтровал с помощью ip.host == 192.168.0.105 , чтобы содержать только любой трафик к PI.
Еще одно примечание по моей настройке здесь: я использую маршрутизатор TP-Link, к которому подключен компьютер к портам LAN, и который предоставляет Wi-Fi 2,4 ГГц для PI. Таким образом, оба являются частью одной и той же подсети, и никакой специальной маршрутизации или чего-либо не настраивается.
Также я остановил демон dropbear и адаптировал свой код Python для использования порта 22. Он работает.
Я лишь в общих чертах знаю об этом. внутренняя работа TCP, поэтому я не могу понять то, что вижу здесь. Любые идеи более чем приветствуются.
https://www.dropbox.com/s/5o4rqr5zdws2wq7/wlan0-tcp-only.pcap?dl=0
https://www.dropbox.com/s/ amypjtk1nvja4qb / enp4s0-tcp-and-pi.pcap? dl = 0
Вывод ssh -vvv (скрытый) (другой IP-адрес из-за DHCP):
14:27 $ ssh -vvv root@192.168.0.102
OpenSSH_8.0p1 Ubuntu-6build1, OpenSSL 1.1.1c 28 May 2019
debug1: Reading configuration data /home/deets/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug2: resolve_canonicalize: hostname 192.168.0.102 is address
debug2: ssh_connect_direct
debug1: Connecting to 192.168.0.102 [192.168.0.102] port 22.
debug1: connect to address 192.168.0.102 port 22: Connection timed out
ssh: connect to host 192.168.0.102 port 22: Connection timed out
Первоначально запрос на SO: https: //stackoverflow.com/questions/61576538/ssh-connection-not-established-but-standard-tcp-ip-connection-works?noredirect=1#comment108936218_61576538
Глядя на трассировку PCAP, Pi фактически отправляет ответ на запрос на подключение (отмеченный SYN, ACK, например, пакет № 14 в wlan0-tcp-only.pcap ), который не отображается в трассировке на стороне клиента. Итак, проблема на пути от Pi обратно к вашему ПК.
Я не могу определить точную проблему на основании предоставленной информации, но вот что нужно проверить:
- Проверьте брандмауэр на ПК, чтобы он не фильтровал трафик
- Поместите Pi ближе к WIFI точка доступа/маршрутизатор