Для работы с облачной инфраструктурой рекомендуется создавать SSH Jumpstation. Это позволяет повысить безопасность и удобство администрирования серверов. В этой статье мы расскажем, как настроить единую точку входа для подключений по ssh – SSH Jump Server. Для реализации выбраны два проекта с открытым исходным кодом.

  • Традиционный подход с использованием OpenSSH. Преимущество в том, что на ваших Linux-серверах уже предустановлены необходимые пакеты OpenSSH

  • Использование альтернативного opensource-проекта Teleport

Оба этих сервера просты в установке и настройке, бесплатны, имеют открытый исходный код и представляют собой демоны Linux с одним бинарником.

Что такое SSH Jump Server?

SSH Jump Server — это обычный сервер Linux, доступный из интернета, который используется в качестве шлюза для доступа к другим машинам Linux в частной сети с использованием протокола SSH. Иногда SSH Jump Server также называют jump host или bastion host. Назначение SSH Jump Server — быть единственным шлюзом для доступа к вашей инфраструктуре, уменьшая размер потенциальной поверхности атаки. Наличие выделенной точки доступа SSH также упрощает ведение сводного журнала аудита всех SSH подключений.

Почему бы не использовать термин SSH-proxy? Отчасти по историческим причинам. В первые дни использования SSH пользователям приходилось подключаться по SSH к Jump Server, а оттуда им приходилось снова вводить ssh, чтобы «перейти» к хосту назначения. Сегодня это делается автоматически, и Teleport фактически использует термин SSH-proxy для описания этой функции.

Настройка SSH Jump Server

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

  • Чтобы предотвратить непреднамеренное обновление конфигурации jump-сервера

  • Чтобы исключить возможность использования jump-сервера для других задач

Также неплохо изменить порт TCP по умолчанию на сервере перехода SSH с 22 на другой.

Давайте рассмотрим настройку сервера перехода SSH с использованием двух проектов с открытым исходным кодом. Начнём с OpenSSH, самого распространённого варианта.

Но сначала давайте введём некоторые имена, которые будут использоваться в примерах ниже:

  • Домен организации: example.com

  • DNS-имя jump-сервера организации будет proxy.example.com

Также предполагается, что proxy.example.com — это единственная машина в локальной сети организации, доступная из Интернета.

OpenSSH

Этот пакет SSH-сервера по умолчанию входит в состав большинства дистрибутивов Linux, и есть почти 100% вероятность, что он у вас уже установлен. Если у вас есть доступ к jump-серверу proxy.example.com, вы можете получить доступ к другим серверам в локальной сети за этим NAT с помощью -J флага в командной строке:

$ ssh -J proxy.example.com 10.3.3.1

В приведённом примере 10.3.3.1 – это адрес конечной станции в локальной сети, к которой вы подключаетесь. Выглядит довольно просто.

Чтобы не печатать в командной строке параметры -J proxy.example.com, вы можете обновить конфигурацию SSH на вашем клиенте в файле ~/.ssh/config следующим образом:

Host 10.3.3.*
    ProxyJump proxy.example.com

Теперь, когда пользователь вводит ssh 10.3.3.1, SSH-клиент даже не пытается разрешить адрес 10.3.3.1 локально, а вместо этого устанавливает соединение c proxy.example.com, которое перенаправляет его на 10.3.3.1 в своем локальном сегменте.

Теперь нужно немного усилить конфигурацию безопасности jump-сервера, отключив интерактивные сеансы SSH на jump-сервере для обычных пользователей, но оставив их включёнными для администраторов. Для этого необходимо обновить конфигурацию sshd, обычно она лежит в файле /etc/ssh/sshd_config:

# Do not let SSH clients do anything except be forwarded to the destination:
PermitTTY no
X11Forwarding no
PermitTunnel no
GatewayPorts no
ForceCommand /sbin/nologin

Приведённый выше пример будет работать для Debian и его производных, советуем проверить наличие файла /sbin/nologin.

Это конфигурация будет работать, если на jump-сервере есть учётные записи для всех пользователей SSH, что не очень удобно. Вместо этого рассмотрите возможность создания отдельной учётной записи на jump-сервере, предназначенной для перенаправляемых пользователей ssh. Назовём эту учётную запись jumpuser и обновим конфигурацию ssh-сервера:

Match User jumpuser
  PermitTTY no
  X11Forwarding no
  PermitTunnel no
  GatewayPorts no
  ForceCommand /usr/sbin/nologin

И пользователям нужно будет обновить конфигурацию своего клиента SSH в файле ~/.ssh/config:

Host 10.2.2.*
    ProxyJump jumpuser@proxy.example.com

Для получения дополнительной информации по конфигурированию SSH для вашей конкретной ситуации, обратитесь к man ssh_config и man sshd_config.

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

Teleport

Teleport — это SSH-сервер и клиент, который был выпущен в 2016 году. Teleport ориентирован на работу с кластерами и большим количеством узлов.

  • Он настаивает на использовании прокси-сервера SSH по умолчанию, а его прокси-сервер SSH имеет веб-интерфейс, позволяющий пользователям подключаться к SSH с помощью браузера.

  • В отличие от традиционных серверов SSH, Teleport устраняет необходимость в ведении «инвентаризации» серверов, поскольку предлагает оперативный самоанализ, то есть вы можете увидеть все онлайн-серверы за прокси, как показано на скриншоте:

Помимо современных функций прокси, Teleport предлагает несколько преимуществ по сравнению с традиционным SSH:

  • Teleport не использует SSH-ключи и вместо этого по умолчанию использует более безопасные и гибкие сертификаты SSH. Это устраняет необходимость в управлении ключами и сильно упрощает настройку SSH-серверов.

  • Teleport поддерживает другие протоколы в дополнение к SSH, поэтому тот же jump-сервер можно использовать для доступа к другим ресурсам за NAT, таким как кластеры Kubernetes или даже внутренние приложения через HTTP(s).

  • Teleport не полагается на пользователей Linux для аутентификации. Вместо этого он поддерживает отдельную базу данных пользователей или может интегрироваться с помощью единого входа с другими поставщиками аутентификации, такими как Github, Google Apps, или корпоративными опциями, такими как Okta и Active Directory.

Teleport всегда поставляется с прокси (то есть то же самое, что и jump-сервер), и нет необходимости в специальных инструкциях по его настройке. Скачать его можно здесь.

Другие особенности Teleport:

  • Помимо традиционного интерфейса командной строки имеется возможность входа через HTTPS с эмуляцией терминала в web-браузере

  • Поддержка функций аудита и повторения типовых операций. Содержимое SSH-сеансов может записываться и при необходимости воспроизводиться на других хостах

  • Режим совместного решения проблем, при котором несколько человек могут совместно использовать один сеанс SSH

  • Автоматическое определение доступных рабочих серверов и контейнеров Docker в кластерах с динамическим присвоением имён хостам

  • Поддержка обратного туннелирования для подключения к кластерам, ограждённым межсетевым экраном

  • Возможность определения меток для наглядного разделения узлов кластера

  • Поддержка блокировки доступа после нескольких неудачных попыток входа

  • Сопоставление пользователей с логинами на конечных узлах осуществляется через специальные списки маппинга

  • Для подсоединения к хосту требуется указать два имени — имя кластера и имя узла в кластере. Teleport ориентирован на управление кластерами, а не отдельными серверами. Для каждого пользователя и хоста определяется принадлежность к кластеру

  • Узлы подключаются к кластеру через определение статичестких или генерацию динамических токенов, которые при желании можно отозвать для запрета входа на данный узел

  • Для подсоединения к серверам Teleport внутри кластера можно использовать обычный клиент OpenSSH (требуется копирование ключей)

  • Успешно пройден аудит безопасности кода, заказанный в независимой проверяющей компании

Заключение

Итак, мы рассказали, как настроить SSH-jump сервер с помощью двух проектов с открытым исходным кодом: OpenSSH и Teleport. Но какой  же выбрать?

Используйте OpenSSH, если:

  • Количество серверов и/или пользователей в вашей организации невелико

  • Вам нужна быстрая настройка jump-сервера, и у вас не так много времени, чтобы изучить новые технологии

Используйте Teleport, если:

  • Ваш парк серверов или размер вашей команды растёт

  • Вам необходимо подключиться к серверам, расположенным «в дикой природе», то есть не ограничиваться только локальной сетью.

  • У вас есть пара часов, чтобы поиграться изучить новый инструмент

Что ещё интересного есть в блоге Cloud4Y

→ В тюрьму за приложение

→ Детям о Кубернете, или приключения Фиппи в космосе

→ Определённо не Windows 95: какие операционные системы поддерживают работу в космосе?

→ Рассказываем про государственные защищенные сервисы и сети

→ Внутри центра обработки данных Bell Labs, 1960-е

Подписывайтесь на наш Telegram-канал, чтобы не пропустить очередную статью. Пишем не чаще двух раз в неделю и только по делу.

Кстати, у нас сейчас действует акция: -65% на IaaS-инфраструктуру. Условия актуальны до 6 декабря, поспешите!