ProHoster > Блог > Администрирование > Двухфакторная аутентификация для SSH

Двухфакторная аутентификация для 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. Конечно, злоумышленник может похитить ваш токен, но он всё равно не знает парольную фразу.

Источник: habr.com

Добавить комментарий