Как настроить SSH-Jump Server

    Для работы с облачной инфраструктурой рекомендуется создавать 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.2.2.*
        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 декабря, поспешите!

    Cloud4Y
    #1 Корпоративный облачный провайдер

    Комментарии 5

      +1
      Про реверсивный L7 прокси сервер sshpiperd забыли, живет в продакшене больше года, полет нормальный. Настроен без докер контейнера, проксирует на нужный сервер в зависимости от логина, сквозная аутентификация по ключу и krb5 работает, при чем берется туннель с нижестоящего хоста.
        +2
        Есть ещё sshportal. Тоже хорошее решение.
          +4

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


          Зато имеет смысл использовать нестандартный порт, чтобы запускать сервер без прав рута. Поднять 2 SSH-сервера, один на стандартном порту для администрирования, другой на нестандартном от имени пользователя nobody. Вот его и использовать для проксирования, все равно он будет физически неспособен что-либо другое сделать.

            +2
            Teleport не использует SSH-ключи и вместо этого по умолчанию использует более безопасные и гибкие сертификаты SSH


            Если я правильно понимаю документацию (на языке оригинала), там X.509 сертификаты (обычно именуемые SSL-сертификатами), в примере — от LetsEncrypt.

            Можно пояснить подробнее, чем они безопаснее, например, Ed25519-ключа?
              +1
              какой интресньій хостнейм у тунеля…

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

              Самое читаемое