Есть такая тенденция, что при упоминании слова "проксирование", последнее время на ум приходит сразу веб сервер типа nginx и apache. Но ведь "проксирование" - это по своей сути перенаправление запроса куда-то дальше. И работает это не только с вебом и http запросами.
Не знаю, почему, но в последнее время не слышал интересных вопросов по каким-то базовым вещам, которые заставили бы задуматься. Под все задачи придумывают оболочки, которые упрощают нам жизнь. Но "под капотом" эти оболочки все так же используют старые и проверенные сервисы, функционал которых мы потихоньку начали забывать.
Сегодня разберем несколько трюков с ssh сессиями.
Есть у меня одна задача, которую почему-то ни разу не задавали мне на собеседованиях, но которую я часто давал своим соискателям "на подумать".
Задача звучит следующим образом:
"Есть 3 сервера. Сервер 1 имеет общую локальную сеть только с Сервером 2, Сервер 2 имеет общую сеть с Сервером 1 и Сервером 3. Из внешней сети можно попасть только на Сервер 1. Как Вы будете действовать, если нужно пробиться на Сервер 3?"
И сразу примечания к задаче:
"ssh порты открыты, root доступ по паролю отключен, ваш ключ авторизован на всех серверах, обращаться можно только по 22 порту"
Звучит довольно сложно, да? На практике - типичная ситуация с ПК в локальной сети за шлюзом с NAT.
Вариант с пробросом ssh порта мы не рассматриваем из-за условия "обращаться по 22 порту". Пробросив порт, мы тут же потеряем возможность обращаться к серверу 1 и серверу 2, т.к. наш запрос будет автоматически будет уходить на сервер 3.
Вариант "зайти на сервер 1, с него - на сервер 2 и т.д." не сработает. Во-первых, если на сервере 1 есть своя связка ключей у пользователя, ssh потребует пароль от нее. Во-вторых, если ключей нет, ssh попробует подключиться по паролю, но получит ответ "Permission denied".
Давайте разбираться, как это делать правильно.
Терминальный способ
Для начала вспомним, что наш ssh ключ авторизован на каждом сервере, значит, по одному и тому же ключу мы можем в теории попасть на каждый из них.
- Авторизуем наш ключ в системе:
ssh-add ~/.ssh/{файл закрытой части ключа}
Система попросит пароль от ключа, после успешной проверки напишет "Identity added".
- После авторизации ключа в сессии, мы можем добавлять к команде ssh ключ A, который будет указывать на то, что использовать нужно именно авторизованный ключ:
ssh -A root@{Server 1}
ssh -A root@{Server 2}
Все довольно легко и банально. Но можно ли еще проще? Не хотелось бы каждый раз прописывать данные авторизации. Конечно можно.
Конфигурация ssh клиента
В папке ~/.ssh создаем файл config с правами 644 (права 600 нужны только для ключей)
- Если мы хотим заходить по ssh на сервер по его имени, нам достаточно добавить такой блок:
host server1
User root
Hostname IP.IP.IP.IP
Но нам этого недостаточно, нам нужно пробрасывать наше подключение еще дальше.
- На помощь приходит параметр ProxyCommand:
host server1
User root
Hostname IP.IP.IP.IP
host server2
User root
ProxyCommand ssh -W %h:%p server1
Hostname 192.168.1.2
host server3
User root
ProxyCommand ssh -W %h:%p server2
Hostname 192.168.1.3
Важно понимать, что по условиям нашей задачи, Сервер 3 может общаться по сети только с Сервером 2. Значит, проксировать запрос мы будем с Сервера 1 на Сервер 2, а уже далее на Сервер 3.
По сути, на этом можно и закончить решение задачи. Мы описали сразу два способа, а на практике вы можете это применять в тех случаях, когда необходимо попасть на локальный сервер извне, имея возможность подключаться по ssh к шлюзу.