Почему Ubuntu не может получить доступ к моему Raspberry Pi через локальную сеть?

Таким образом, пока вы не включили ufw с настройками по умолчанию на вашем компьютере с Ubuntu, соединение всегда сообщало Connection refused. После того, как вы отключили ufw на своем клиенте, соединение установлено, но пароль всегда отклоняется?

В таком случае я думаю, что ваша проблема в том, что ip 192.168.2.128 направляется обратно на ваш клиентский компьютер Ubuntu и на самом деле вы подключаетесь к серверу ssh, работающему на вашем компьютере с Ubuntu. Это объясняет:

• Почему вы можете подключиться из Интернета.

• Почему ваше соединение было отклонено, когда брандмауэр был включен на вашем клиенте Ubuntu.

• Почему соединение больше не отклоняется при отключенном брандмауэре клиента.

• Почему теперь соединение установлено, но аутентификация не удалась.

Для устранения неполадок в этом случае:

• Проверьте ключ хоста сервера с помощью ssh -v pi@192.168.2.128 как для локального, так и для интернет-соединения. Это сообщает тот же ключ?

• Или когда вы подключаетесь из локальной сети, и у вас есть приглашение ввести свой пароль, с другого терминала: sudo netstat -tupan и посмотрите, установлено ли соединение с sshd на вашем Ubuntu.

Хотя этот случай объяснит все, но это так странно, что у меня есть сомнения, что это ваша проблема.

Вполне возможно, что ваш компьютер с Ubuntu получает сетевой IP-адрес, отличный от ожидаемого. Попробуйте сделать следующее:

• На распи проверьте его IP-адрес с помощью ifconfig | grep 192.168
• на машине с Ubuntu, проверьте его IP-адрес с помощью ifconfig | grep 192.168

Чтобы иметь возможность общаться друг с другом в локальной сети, они оба должны использовать одну и ту же подсеть. Посмотрите на третью часть IP-адреса, чтобы узнать, так ли это. В вашем случае они оба должны быть в подсети 192.168.2. *.

Убедитесь, что у них действительно разные IP-адреса. Это может показаться очевидным, но может произойти, если один из них использует DHCP, а другой настроен статически.

Если все получилось, запустите следующую команду, чтобы увидеть, куда должны отправляться ваши пакеты:

route -n

В выходных данных найдите подходящую подсеть назначения, которая применяется к твоему малиновому пи. На самом деле должно быть всего 3 строки:

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

Если у вас есть больше строк или что-то происходит в странных местах, то это ответ.

Я предполагаю, что ваше ssh-соединение заканчивается тем, что оно подключается к другому SSH-серверу, чем тот, что установлен на вашем raspberry pi, поэтому изменение брандмауэра ubuntu повлияло на него, и ваши логины не работают.

Согласно тому, что находится в вашем PasteBin, «отказано в соединении» означает, что вы получаете сброс TCP с любого IP-адреса.

Проверка работоспособности: при устранении неполадок отключите ufw.

Если ваш настольный брандмауэр отключен, можете ли вы пропинговать Pi со своего рабочего стола? Можете ли вы пропинговать рабочий стол с вашего Pi?

После попытки пинга в обоих направлениях посмотрите на вывод «arp -n» на обеих машинах. Видят ли они MAC-адреса (аппаратные) Ethernet друг друга или что-то перенаправляет / перехватывает трафик?

Если вы можете пропинговать в обоих направлениях, а «arp -n» указывает, что используются правильные MAC-адреса (проверьте) ifconfig 'на противоположной машине), следующим шагом является проверка /var/log/auth.log на Pi. Он должен сказать вам, что не так с попыткой подключения.

Если приведенное выше не помогает, пожалуйста, покажите нам вывод следующих команд на Pi:

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

И на вашем рабочем столе:

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

Я вижу некоторые об этом вставлено в комментариях выше, но все это важно сначала захватить с выключенным брандмауэром. Если вы можете заставить его работать с выключенным брандмауэром, вы можете приступить к устранению неполадок в правилах брандмауэра.

Кроме того, даже если вы ориентируетесь на IP-адрес, настройки DNS все равно имеют значение, поскольку SSH использует DNS во время проверки ключа хоста.

Удалите файл ~/.ssh/known_hosts и попробуйте снова. Если ранее был доступен хост с таким же IP-адресом ssh, вы можете оставить недопустимый отпечаток пальца

В Ubuntu 13.10 я не мог ssh к своему пи, когда раньше мог 13.04 и Mint 16. При попытке

ssh -vvv user@host

я получил:

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

через предложение, в котором сказано установить MTU для машины (не пи) в 1200 вместо автоматического. Я сделал это, выключил -> затем на моем Wi-Fi, и подключился с SSH к PI с первой попытки. Надеюсь, это кому-нибудь поможет.