Сервер перехода SSH – это прокси, стоящий между клиентами и остальной частью парка SSH. Узлы Jump минимизируют угрозы, заставляя весь трафик SSH проходить через одно защищенное местоположение и сводя к минимуму конечные точки SSH отдельного узла во внешний мир. (Читать далее: “Как настроить SSH-сервер перехода. »)

Один из способов настроить многопоточную настройку – сохранить закрытый ключ для целевого сервера на вашем сервере перехода. Делать нет сделай это. Сервер перехода обычно является многопользовательской средой, что означает, что любая сторона с повышенными привилегиями может скомпрометировать любой закрытый ключ. Решение этой угрозы безопасности – включение пересылки агентов. Учитывая, насколько распространен этот метод, вы можете удивиться, узнав, что он не рекомендуется. Чтобы понять почему, давайте копнем глубже.

[ Also on InfoWorld: Make life easy with ssh_config ]

Как работает переадресация агентов?

ssh-agent – это менеджер ключей, который существует как отдельная программа от SSH. (Читать далее: “Как управлять ключами SSH. ») Он содержит закрытые ключи и сертификаты, используемые для аутентификации в памяти. Он не записывает на диск и не экспортирует ключи. Вместо этого функция пересылки агента позволяет нашему локальному агенту подключаться через существующее соединение SSH и аутентифицироваться на удаленном сервере с помощью переменной среды.

По сути, когда клиентский SSH получает ключевые запросы, агент пересылает эти запросы вверх на наш локальный компьютер, где ответ на запрос будет создан с помощью локально сохраненного закрытого ключа и переадресован обратно вниз на целевой сервер для аутентификации. (Читать далее: “Объяснение рукопожатия SSH. »)

За кулисами ssh-agent связывается с сокетом домена Unix для связи с другими программами ($SSH_AUTH_SOCK переменная окружения). Проблема в том, что любой, у кого есть права root в любом месте цепочки, может использовать созданный сокет для взлома нашего локального ssh-агента. Несмотря на то, что файлы сокетов хорошо защищены ОС, пользователь root может выдавать себя за другого пользователя и направлять SSH-клиент на своего собственного вредоносного агента. По сути, пересылка с использованием агента – это то же самое, что обмен секретным ключом с кем-либо, у кого есть root на машине по всей цепочке.

Фактически, страница руководства, посвященная ForwardAgent читает:

Пересылку агента следует включать с осторожностью. Пользователи с возможностью обхода файловых разрешений на удаленном хосте (для сокета домена Unix агента) могут получить доступ к локальному агенту через перенаправленное соединение. Злоумышленник не может получить ключевой материал от агента, однако он может выполнять операции с ключами, которые позволяют им аутентифицироваться с использованием идентификаторов, загруженных в агент.

Вместо этого используйте ProxyJump

Для навигации по серверам перехода мы на самом деле не нужно агент экспедирования. Современный подход – использовать ProxyJump или его эквивалент в командной строке -J. (Читать далее: “Конфигурация SSH: ssh_config. »)

Host myserver
    HostName myserver.example.com
    User virag
    IdentityFile /users/virag/keys/ed25519
    ProxyJump jump
Host jump
    HostName jump.example.com
    User default   

Вместо пересылки ответа на запрос ключа через агента, ProxyJump направляет stdin а также stdout нашего локального клиента на целевой хост. Таким образом, мы не бежим ssh на jump.example.com; sshd подключается напрямую к myserver.example.com и передает управление этим подключением нашему локальному клиенту.

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

ProxyJump для нескольких переходов

Смоделируем более сложный сценарий. Мы пытаемся получить доступ к критически важному ресурсу в глубине нашей корпоративной сети из дома. Сначала мы должны пройти через внешний хост-бастион с динамическим IP, внутренний хост перехода и, наконец, к ресурсу. Каждый сервер должен пройти аутентификацию по уникальному локальному ключу на нашей машине. (Читать далее: “Настройка хоста-бастиона SSH. »)

ssh несколько переходов Телепорт

SSH с несколькими прыжками.

Еще раз, наш локальный файл конфигурации будет содержать все, что нам нужно для выполнения ssh myserver.

Host myserver
HostName myserver.example.com
User virag
IdentityFile /users/virag/keys/myserver-cert.pub
ProxyJump jump
Host bastion
#Used because HostName is unreliable as IP address changes frequently
HostKeyAlias bastion.example
User external 
Host jump
HostName jump.example.com
User internal 
IdentityFile /users/virag/keys/jump-cert.pub
ProxyJump bastion

А теперь представьте, что нам нужно управлять парой сотен сред у нескольких облачных провайдеров по всей стране с помощью OpenSSH, настроенного внутри компании. (Вы можете посмеяться над этим, но мы слышали эти истории от клиентов.) Невозможно полагаться только на команды времени выполнения, утверждая, что они обеспечивают надежную степень безопасности.

В этом масштабе эффективное управление парком требует сознательной архитектуры подсетей, DNS, цепочек прокси, ключей, файловых структур и т. Д., Которые следуют предсказуемым шаблонам и могут быть преобразованы в ~ / .ssh / ssh_config. Либо так, либо используя Телепорт.

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

Форум новых технологий предоставляет площадку для изучения и обсуждения новых корпоративных технологий с беспрецедентной глубиной и широтой. Выбор носит субъективный характер и основан на нашем выборе технологий, которые мы считаем важными и представляющими наибольший интерес для читателей InfoWorld. InfoWorld не принимает маркетинговые материалы для публикации и оставляет за собой право редактировать весь предоставленный контент. Все запросы отправляйте по адресу newtechforum@infoworld.com.

Авторские права © 2021 IDG Communications, Inc.


#ProxyJump #безопаснее #чем #перенаправление #агента #SSH

Source link