Ошибка соединения SSH: нет маршрута к хосту

В этом сценарии есть три машины:

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

Все машины имеют Ubuntu 11.04 (рабочий стол A является 64-битным) и имеют как openssh-сервер, так и openssh-клиент.

Теперь, когда я пытаюсь подключить рабочий стол A к ноутбуку A или наоборот, ssh user@1.23.y.yя получаю сообщение об ошибке

port 22: No route to host

в обоих случаях.

Я владею обеими машинами, и теперь, если я попробую те же команды с машины моего друга, то есть через Рабочий стол B, я смогу получить доступ как к своему ноутбуку, так и к рабочему столу. Но если я пытаюсь получить доступ к Desktop B с моего ноутбука или с рабочего стола, я получаю

port 22: Connection timed out

Я даже попытался изменить порт SSH нет. в ssh_configфайле, но безуспешно.

Обратите внимание : что «Портативный компьютер A» использует соединение WiFi, а «Устройство A» использует соединение Ethernet, а «Устройство B» находится в совершенно другой сети.

@Lekensteyn Вот оно ->

Ноутбук A && Desktop A -> Router / 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) и порт 2222 (ноутбук).

Доступ к рабочему столу теперь можно получить с помощью SSH с:

ssh user@198.51.100.1 -p 22

Доступ к ноутбуку теперь можно получить по SSH:

ssh user@198.51.100.1 -p 2222

Если вы хотите получить доступ к своей машине друзей, примените эти инструкции к его машине + маршрутизатор.

У меня была аналогичная проблема. Одна машина на проводе, одна беспроводная. Я нашел галочку в моем роутере помимо «отдельных ips для локальной сети и wlan» и снял галочку. Теперь я могу войти на компьютер Wireles. Перед этим я получил сообщение об ошибке «Нет маршрута к хосту».

Установите флажок ssh при установке RHEL. Я не проверял это и вызывал ту же проблему. Пожалуйста, проверьте этот параметр

Я сам получил ту же проблему на VPS, и это совершенно странно, никогда не видел ничего подобного.

Я опытный администратор сервера и такого рода ошибки, как правило, мелкие.

Отсутствие маршрута к хосту означает, что сервер не знает, как маршрутизировать пакет (таблица маршрутизации, однако я никогда не видел, чтобы это происходило только по одному протоколу, а не по другому).

В моем случае.

Нет NAT подключения к интернету. Нет IPTABLES Пинг работает, я могу подключиться к 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 между моим ПК и Raspberry Pi. Для меня это исправляет отключение и включение wifi (как клиента, так и хоста), перезапуск вашего терминала и использование новых IP-адресов.

В моем случае была сеть Docker на том же CIDR, что и мой VPN.

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

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

После этого все заработало нормально.

Если вы изменили / заменили системный жесткий диск, попробуйте удалить hostkey из файла .ssh / known_hosts, а затем повторите попытку подключения.