Чи можливий доступ 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 (тоді ми можемо виправити конфігурацію)?

Потрібно мати можливість увійти на інший хост у тому ж сегменті мережі. Деякі із способів отримати доступ до неправильно налаштованого хоста вимагають кореня на проміжному хості, але також існує один простий спосіб отримати доступ, не потребуючи коріння на проміжному хості.

Простий спосіб отримати доступ до хоста за допомогою 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використанню %символу втечі, введена команда 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, ви можете просто перейти звідти до 192.168.1.9. Якщо 192.168.1.8 наразі не призначено, ви можете тимчасово призначити його будь-якому хосту на сегменті, до якого у вас є кореневий доступ.

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.