Двухфакторная аутентификация для SSH

    «Безопасная оболочка» SSH — сетевой протокол для установления защищённого соединения между хостами, стандартно по порту 22 (который лучше поменять). SSH-клиенты и SSH-серверы доступны для большинства ОС. Внутри SSH работает практически любой другой сетевой протокол, то есть можно удалённо работать на другом компьютере, передавать по шифрованному каналу звуковой поток или видео и т.д. Кроме того, через SOCKS-прокси на удалённом хосте можно подключаться к другим хостам уже от имени этого удалённого хоста.

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

    Как реализовать двухфакторную аутентификацию


    Разработчики из компании Honeycomb недавно опубликовали подробную инструкцию, как реализовать соответствующую инфраструктуру на клиенте и сервере.

    Инструкция предполагает, что у вас есть некий базовый хост, открытый в интернет (бастион). Вы хотите подключаться к этому хосту с ноутбуков или компьютеров через интернет, и получать доступ ко всем остальным устройствам, который находятся за ним. 2FA гарантирует, что злоумышленник не сможет проделать то же самое, даже если получит доступ к вашему ноутбуку, например, установив вредоносное ПО.

    Первый вариант — OTP


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

    В данном случае на серверной стороне в конфиг Chef прописываются следующие строки:

    • metadata.rb
    • attributes/default.rb (из attributes.rb)
    • files/sshd
    • recipes/default.rb (копия из recipe.rb)
    • templates/default/users.oath.erb

    На клиентской стороне ставится любое OTP-приложение: Google Authenticator, Authy, Duo, Lastpass, устанавливается brew install oath-toolkit или apt install oathtool openssl, потом генерируется случайная строка base16 (ключ). Она конвертируется в формат Base32, который используют мобильные аутентификаторы, и импортируется непосредственно в приложение.

    В итоге вы можете подключиться к бастиону и убедиться, что теперь тот требует не только парольную фразу, но и код OTP для аутентификации:

    ➜ ssh -A bastion
    Enter passphrase for key '[snip]': 
    One-time password (OATH) for '[user]': 
    Welcome to Ubuntu 18.04.1 LTS...

    Второй вариант — аппаратная аутентификация


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

    Тут конфигурация Chef немного сложнее, а конфигурация клиентов зависит от ОС. Но зато после выполнения всех действий клиенты на MacOS могут подтверждать аутентификацию в SSH по парольной фразе и приложением пальца к сенсору (второй фактор).

    Владельцы iOS и Android подтверждают вход нажатием одной кнопки на смартфоне. Это специальная технология от Krypt.co, которая даже безопаснее, чем OTP.

    На Linux/ChromeOS есть вариант работы с USB-токенами YubiKey. Конечно, злоумышленник может похитить ваш токен, но он всё равно не знает парольную фразу.
    • –6
    • 4,7k
    • 9
    GlobalSign
    252,99
    Компания
    Поделиться публикацией

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

      +4
      Хорошо, что существуют нормальные статьи по настройке 2FA, а то можно было бы впасть в отчаяние…
        0
        Что это было?
          0
          Если «угнали» обе пары ключей… то 2FA поможет как кроличий помёт от раковой опухоли.
            0
            Внутри SSH работает практически любой другой сетевой протокол

            Но при выполнении суммы некоторых условностей:
            1. SSH-Сервер умеет желаемое.
            2. У нас есть возможность включить необходимые опции в конфиге SSH-Сервера.
            3. SSH-Клиент способен осилить нужную нам фичу.
              0
              Не очень понятно, про что статья, какие-то свои Chef-конфиги… А уже думалось по названию что что-то прям про настройку.
                0
                Это просто твит про статью о настройке:
                Разработчики из компании Honeycomb недавно опубликовали подробную инструкцию, как реализовать соответствующую инфраструктуру на клиенте и сервере.
                0
                Второй вариант — аппаратная аутентификация

                А можно просто так.

                  0
                  с использованием смарт-карт или USB-токенов на базе российской криптографии

                  Вот так точно не надо.
                  Хотя я очень надеюсь дожить до того дня, когда российскому шифрованию/криптографии можно будет доверять, не оглядываясь на возможные последствия.
                  0
                  «Разработчики пишут, что это неидеальный вариант, потому что злоумышленник может поднять фальшивый бастион, перехватить ваш OTP и использовать его.»
                  Смотрим google auth — там срок жизни ключа 30с что ли. Перехватывать чуть менее чем бесполезно, разве что сразу залогиниться, но если пользователь не сможет войти за пару попыток — скорее всего он поднимет тревогу и уведомит о проблемах админов хоста. Да и сделать это сложно, учитывая шифрованный трафик.

                  «специальная технология от Krypt.co» — что за бред? Банально — есть duo security (https://duo.com/), купленный циской, оно много куда прикручивается, включая ssh. Настраивается тоже просто, а с системами деплоя запускается просто на раз.
                  А сейчас есть такая реализация и от гугла, когда он присылает пуш на смарт.

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

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