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

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

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

Однак, коли я завантажився в Ubuntu, усі з'єднання SSH, HTTP та HTTPS відмовилися. Щоб підтвердити, що це проблеми з підключенням, перезавантажився Ubuntu, і лише Ubuntu, я перезавантажився в Puppy Linux - підключений штраф, і в Windows - штраф. Netbook також міг підключитися до всіх 3 сервісів без проблем. Саме Ubuntu сказав, що з'єднання відмовилося.

Мені хотілося б знати, що не так - я вже зробив усі основні проблеми усунення несправностей: перезавантаження RPI, перезавантаження комп'ютера, перезавантаження бездротового маршрутизатора тощо. У Raspberry Pi не ввімкнено брандмауер, і мій маршрутизатор пропонує всі пристрої, підключені до LAN необмежений доступ один до одного. Я провів обширне тестування, і 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-адресу, ніж очікується. Спробуйте наступне:

• На Raspi перевірте його 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-сервера, ніж того, що знаходиться на вашому малиновому пі, тому зміна брандмауера ubuntu вплинула на нього, і ваші входи не працюють.

Відповідно до того, що є у вашій PasteBin, "з'єднання відмовлено" вказує, що ви отримуєте скидання TCP з того, що знаходиться за цією IP-адресою.

Перевірка здоровості: під час усунення несправностей DISABLE ufw.

Якщо брандмауер на робочому столі вимкнено, чи можете ви пінг Pi на робочому столі? Ви можете пінг робочого столу з вашого Pi?

Спробувавши ping в обох напрямках, подивіться на результат 'arp -n' на обох машинах. Вони бачать адреси один одного MAC (Ethernet hardware) або щось переспрямовує / перехоплює трафік?

Якщо ви можете пінг в обох напрямках і "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 до свого pi, коли раніше я міг на 13.04 та монетний двір 16. Під час спроби

ssh -vvv user@host

Я зрозумів, я отримав :

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

Я наштовхнувся на пропозицію, яка сказала встановити MTU для машини (а не пі) 1200, а не автоматичну. Я зробив це, вимкнув -> потім на моєму wifi і підключився з ssh до PI з першої спроби. Сподіваюся, що це комусь допоможе.