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

Хорошо, недавно я получил Raspberry Pi и подключил его к своему Wi-Fi - я включил SSH и установил Hiawatha, и я мог получить к нему отличный доступ с моего рабочего стола, на котором в то время работал Puppy Linux.

Я мог бы также получить к нему прекрасный доступ при загрузке в Windows (PuTTY на Win XP Pro), и нетбук мог получить к нему доступ также через PuTTY. (Win 7 Starter)

Однако, когда я загрузился в Ubuntu, все соединения SSH, HTTP и HTTPS были отклонены. Чтобы подтвердить, что это были Ubuntu и только Ubuntu, у которого были проблемы с подключением, я перезагрузился в Puppy Linux - подключен нормально, и в Windows - подключен нормально. Нетбук мог подключиться ко всем 3 сервисам без проблем. Просто Ubuntu сказал, что соединение отказано.

Я хотел бы знать, что не так - я уже выполнил все основные проблемы: перезагрузка RPi, перезагрузка компьютера, перезагрузка беспроводного маршрутизатора и т. Д. Raspberry Pi не имеет брандмауэра, и мой маршрутизатор предлагает все устройства, подключенные к ЛВС неограниченный доступ друг к другу. Я провел обширное тестирование, и Ubuntu, вне всякого сомнения, оказался единственным, кто не хочет подключаться.

ОБНОВЛЕНИЕ: только что проверил доступ через мой внешний IP, и все работает без проблем в Ubuntu! Тем не менее, Ubuntu по-прежнему не может получить доступ к Pi из чего-либо локального, и я просто подтвердил, что другие мои ОС могут . Я думаю, что это странно, что Ubuntu имеет проблемы с локальным подключением (в отличие от других моих ОС), но просто прекрасно получает доступ к Pi через мой внешний IP.

ОБНОВЛЕНИЕ 2: Отключение брандмауэра позволяет мне получить доступ к устройству, но пароль сообщает как неправильный каждый . холост . время . Я попытался ввести его в Gedit, а затем перетащить его в строку ввода пароля при входе по SSH, и он авторизуется при доступе pi@jamestheawesomedude.cu.cc, но НЕ при доступе pi@192.168.2.128. Это невероятно расстраивает.

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

Я думаю, что в этом случае ваша проблема заключается в том, что 192.168.2.128ip направляется обратно на ваш клиентский компьютер с 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

Посмотрите в выходных данных для подсети назначения, которая применяется к вашему Raspberry Pi. На самом деле должно быть всего 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 со своего рабочего стола? Можете ли вы пинговать рабочий стол от своего Пи?

После попытки пинга в обоих направлениях посмотрите на вывод команды 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 с первой попытки. Надеюсь, это кому-нибудь поможет.