Помилка підключення SSH: до хосту немає маршруту

У цьому сценарії три машини:

• Робочий стіл A: user@1.23.xx
• Ноутбук A: user@1.23.yy
• Машина Б: користувач@192.168.zz

Усі машини мають Ubuntu 11.04 (Desktop A - це 64-бітний), мають і opensh-сервер, і openssh-клієнт.

Тепер, коли я намагаюся підключити Desktop A до ноутбука A або навпаки, ssh user@1.23.y.yя отримую помилку як

port 22: No route to host

в обох випадках.

Я володію обома машинами, тепер, якщо я спробую однакові команди з машини свого друга, тобто через Desktop B, я можу отримати доступ як до свого ноутбука, так і до робочого столу. Але якщо я спробую отримати доступ до Desktop B зі свого ноутбука чи з Desktop, я отримаю

port 22: Connection timed out

Я навіть спробував змінити порт ssh ні. у ssh_configфайлі, але успіху немає.

Зауважте : "Ноутбук A" використовує WiFi-з'єднання, тоді як "Machine A" використовує Ethernet Connection, а "Machine B" - у зовсім іншій мережі.

@Lekensteyn Ось це ->

Ноутбук A&& Desktop A -> Маршрутизатор / Nano_Rcvr, наданий мені провайдером. Отже, до одного маршрутизатора підключені два машини, які можуть отримати доступ до них одночасно. ось мій висновок ifconfig для обох машин: - Ноутбук

wlan0

      Link encap:Ethernet  HWaddr X:X:X:X:00:bc  
      inet addr:1.23.73.111  Bcast:1.23.95.255  Mask:255.255.224.0
      inet6 addr: fe80::219:e3ff:fe04:bc/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:108409 errors:0 dropped:0 overruns:0 frame:0
      TX packets:82523 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:44974080 (44.9 MB)  TX bytes:22973031 (22.9 MB)

Настільний

eth0

      Link encap:Ethernet  HWaddr X:X:X:X:c5:78  
      inet addr:1.23.68.209  Bcast:1.23.95.255  Mask:255.255.224.0
      inet6 addr: fe80::227:eff:fe04:c578/64 Scope:Link
      UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
      RX packets:10380 errors:0 dropped:0 overruns:0 frame:0
      TX packets:4509 errors:0 dropped:0 overruns:0 carrier:0
      collisions:0 txqueuelen:1000 
      RX bytes:1790366 (1.7 MB)  TX bytes:852877 (852.8 KB)
      Interrupt:43 Base address:0x2000 

Вихід ip route show

      1.23.64.0/19 dev wlan0  proto kernel  scope link  src 1.23.73.111  metric 2 

      169.254.0.0/16 dev wlan0  scope link  metric 1000 

Вихід traceroute -n 1.23.73.111

       traceroute to 1.23.73.111 (1.23.73.111), 30 hops max, 60 byte packets
       1  1.23.68.209  3008.787 ms !H  3008.786 ms !H  3008.784 ms !H

Маршрути виглядають чудово. Я припускаю, що ці IP-адреси є приватними (LAN) та не є загальнодоступними.

Оскільки ви підключені по-різному до мережі (Wi-Fi / дротовий зв’язок), велика ймовірність, що ваш маршрутизатор розділив дротові / бездротові мережі. Спробуйте підключити їх обох за допомогою дротового (або бездротового) з'єднання. Інша можливість полягає в тому, що брандмауер на машинах Ubuntu блокує з'єднання.

В іншому випадку налаштуйте свій маршрутизатор так, щоб він використовував ту саму мережу (підмережу) для бездротового та дротового з'єднання. Також переконайтесь, що маршрутизатор не блокує зв’язок клієнт-клієнт.

Ваш маршрутизатор, можливо, скидає всі непотрібні пакети, тому ваш друг отримує повідомлення про "призупинення з’єднання" на вашу загальнодоступну IP-адресу. Налаштуйте переадресацію NAT-порту так, щоб загальнодоступна IP-адреса + комбінація портів пересилалася на вашу локальну адресу.

Приклад мережі:

YOUR NETWORK (A)
    Router A (public address: 198.51.100.1)
    Desktop A - 10.0.0.2
    Laptop  A - 10.0.0.3

YOUR FRIENDS NETWORK (B)
    Router B (public address: 203.0.113.1)
    Machine B - 192.168.0.2

На маршрутизаторі A встановіть NAT переадресацію:

To make your desktop accessible:
  forward the public port 22 to 10.0.0.2
To make your laptop accessible:
  forward the public port 2222 to 10.0.0.3

Якщо у Вас є брандмауер ( ufw, iptables, ...) на машинах , встановлених, щоб дозволити вхідний трафік на порт 22 (Desktop A) і порт 2 222 (ноутбук).

Тепер на робочий стіл можна отримати доступ за допомогою SSH за допомогою:

ssh user@198.51.100.1 -p 22

Тепер доступ до ноутбука можна використовувати за допомогою SSH за допомогою:

ssh user@198.51.100.1 -p 2222

Якщо ви хочете отримати доступ до машини друзів, застосуйте ці інструкції до його машини + роутера.

у мене була подібна проблема. Одна машина на дроті, одна бездротова. Я знайшов прапорець у своєму маршрутизаторі, окрім "окремого ips for lan and wlan", і поставив його. Тепер я можу увійти до комп'ютера проводів. До цього я отримав повідомлення про помилку "Нема маршруту до хоста".

Установіть прапорець ssh під час встановлення RHEL. Я цього не перевіряв і викликав ту саму проблему. Перевірте цей параметр

Я отримав таку саму проблему зараз на vps, і це абсолютно дивно, ніколи не бачив нічого подібного.

Я досвідчений адміністратор сервера, і така помилка, як правило, ріжеться і суха.

Жоден маршрут до хосту не означає, що сервер не знає, як маршрутизувати пакет (таблиця маршрутизації, проте я ніколи не бачив, щоб це відбувалося лише на одному протоколі, а не на іншому).

У моєму випадку.

Немає підключення до Інтернету NAT. Ніяких IPTABLES Ping не працює. Я можу підключитись до ip з будь-якої сторони зламаного ip. Зламаний ip каже, що "жоден маршрут до хоста" на будь-який порт TCP.

Це говорить про те, що щось посередині повертає код помилки або помилку в ОС з таблицею маршрутизації.

Зауважте, помилка є миттєвою, а не затримкою, що означає, що відмова є локальним. Але це все, що я можу діагностувати.

root@vps1 network # telnet 83.149.xx.xx 23
Trying 83.149.xx.xx...
telnet: Unable to connect to remote host: No route to host
root@vps1 network # telnet 83.149.xx.xx 80
Trying 83.149.xx.xx...
telnet: Unable to connect to remote host: No route to host
root@vps1 network # ping 83.149.xx.xx
PING 83.149.xx.xx (83.149.xx.xx) 56(84) bytes of data.
64 bytes from 83.149.xx.xx: icmp_seq=1 ttl=56 time=8.89 ms
64 bytes from 83.149.xx.xx: icmp_seq=2 ttl=56 time=7.93 ms

Я б дивно отримав цю помилку навіть після успішного запуску SSH між моїм ПК та малиною Pi. Це для мене виправлення - це вимкнення та включення Wi-Fi (і клієнта, і хоста), перезапуск терміналу та використання нових ip-адрес.

У моєму випадку була мережа Docker на тому ж CIDR, що і моя VPN.

Я використовував таку команду, щоб визначити, яка мережа, а потім видалив її:

docker inspect $(docker network ls -q) | jq '.[] | {name: .Name, cidr: .IPAM.Config[0].Subnet}'

Після цього воно спрацювало чудово.

Якщо ви змінили / замінили корпус жорсткого диска системи, то спробуйте видалити ключ хоста з .ssh / known_hosts файлу, а потім спробуйте підключитися знову.