Двухфактарная аўтэнтыфікацыя для SSH

"Бяспечная абалонка" SSH – сеткавы пратакол для ўсталявання абароненага злучэння паміж хастамі, стандартна па порце 22 (які лепш памяняць). SSH-кліенты і SSH-серверы даступныя для большасці АС. Усярэдзіне SSH працуе практычна любы іншы сеткавы пратакол, гэта значыць можна выдалена працаваць на іншым кампутары, перадаваць па шыфраваным канале гукавы струмень ці відэа і т.д. Акрамя таго, праз SOCKS-проксі на выдаленым хасце можна падлучацца да іншых хастаў ужо ад імя гэтага выдаленага хаста.

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

Як рэалізаваць двухфактарную аўтэнтыфікацыю

Распрацоўнікі з кампаніі Honeycomb нядаўна апублікавалі падрабязную інструкцыю, як рэалізаваць адпаведную інфраструктуру на кліенце і серверы.

Інструкцыя мяркуе, што ў вас ёсць нейкі базавы хост, адчынены ў інтэрнэт (бастыён). Вы хочаце падлучацца да гэтага хасту з наўтбукаў або кампутараў праз інтэрнэт, і атрымліваць доступ да ўсіх астатніх прылад, які знаходзяцца за ім. 2FA гарантуе, што зламыснік не зможа прарабіць тое ж самае, нават калі атрымае доступ да вашага наўтбука, напрыклад, усталяваўшы шкоднаснае ПЗ.

Першы варыянт - OTP

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

У дадзеным выпадку на серверным боку ў канфіг Chef прапісваюцца наступныя радкі:

  • metadata.rb
  • attributes/default.rbattributes.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

Дадаць каментар