Возможно ли SSH получить доступ к серверу с неправильно настроенной подсетью?

У нас есть сервер, на котором один из наших инженеров неправильно сконфигурировал подсеть, и теперь мы заблокированы на этом сервере, и единственный доступный мне доступ - это последовательная консоль от IDC (это означает, что мы просим инженера IDC помочь нам в этом) ,

Что было неправильно настроено:

address 192.168.1.9 # Original address there was
netmask 255.255.255.254 # Misconfigured, originally should've been .240

Из любопытства - есть ли способ избежать вызова IDC и каким-либо образом подключиться к этому хосту через SSH (тогда мы сможем исправить конфигурацию)?

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

Простой способ получить доступ к хосту с помощью IPv6

ssh -o ProxyCommand='ssh -W [fe80::42:ff:fe:42%%eth0]:%p user@intermediate-host' root@target-server

В следующем примере значение в вышеуказанной необходимости командной быть замещено правильными значениями для случая использования: fe80::42:ff:fe:42, eth0, user, intermediate-host, и target-server.

Подробное объяснение того, как это работает

ProxyCommandэто функция ssh, используемая, когда вы не можете открыть TCP-соединение напрямую с целевым хостом Аргументом ProxyCommandявляется команда, чей stdin / stdout использовать вместо TCP-соединения.

-Wиспользуется для открытия переадресации одного порта и подключения его к stdin / stdout. Это прекрасно сочетается с ProxyCommand.

fe80::42:ff:fe:42%%eth0это локальный адрес ссылки целевого хоста. Обратите внимание, что из-за ProxyCommandиспользования в %качестве escape-символа, набранная команда ssh должна использоваться %%в этом месте. Вы можете найти все локальные адреса в сегменте, запустив ssh user@intermediate-host ping6 -nc2 ff02::1%eth0.

Использование локальных IPv6-адресов для этой цели обычно является самым простым способом, поскольку он включен по умолчанию во всех современных системах, а локальные адреса связи продолжают работать, даже если стеки IPv4 и IPv6 серьезно неверно настроены.

Откат к IPv4

Если IPv6 полностью отключен на неправильно настроенном хосте (абсолютно не рекомендуется), вам, возможно, придется прибегнуть к использованию IPv4. Поскольку у IPv4 нет локальных адресов, как у IPv6, доступ к неверно сконфигурированному хосту с использованием IPv4 усложняется и требует корневого доступа на промежуточном хосте.

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

Если у вас есть логин на 192.168.1.8, вы можете просто перейти от ssh к 192.168.1.9. Если 192.168.1.8 в настоящее время не назначен, вы можете временно назначить его любому хосту в сегменте, к которому у вас есть root-доступ.

kasperdопубликовал отличный ответ, достаточно подробный для меня, чтобы узнать, как я могу оправиться от ситуации в вопросе. Этот ответ является точным пошаговым описанием того, как я это сделал.

1. SSH к серверу в той же физической сети
2. Используя arp -aили, ip neighbor listкак rootнайти MAC-адрес неправильно настроенного сервера.
3. Используя MAC для конвертации локальных ссылок, найдите локальные ссылки для неправильно настроенного сервера
4. Теперь можно SSH к серверу как любой пользователь через ssh user@link-local%devгде:
   • user - имя пользователя, для которого нам разрешен SSH
   • link-local - самоназначенный адрес IPv6, восстановленный на шаге 3
   • dev - физический интерфейс, с которого этот сервер доступен (например, eth0)

Вам необходимо загрузить IP-адрес в настроенной подсети вашей цели, а не только в том диапазоне, который вам действительно нужен.

Если вы отправляете пакет в 10.0.0.2 с подсетью 255.255.255.248 из, например, 10.0.0.220, 10.0.0.2 будет смотреть на свою маску подсети, чтобы выяснить, как ответить. Поскольку .220 WAAY вне подсети 255.255.255.248, .2 вместо этого должен отправить ответ на шлюз по умолчанию.

Так что, если вы можете загрузить IP-адрес в той же подсети, что и .2, например. 10.0.0.3, тогда будет работать.

В вашем конкретном случае для 10.0.0.9 подсеть 255.255.255.254 имеет только 1 дополнительный IP-адрес , а именно 10.0.0.8. Так что, если вы можете загрузить этот IP-адрес, вы сможете использовать SSH.