Zabezpieczanie logowania SSH kluczem sprzętowym Yubikey.

Po lewej klucz yubikey BIO.
Po prawej klucz sprzętowy yubikey 5 NFC

W ostatnim czasie nabyłem dwie pary kluczy sprzętowych najpopularniejszego ostatnio dostawcy, czyli firmy Yubikey. Pierwsza para to klucze sprzętowe yubikey bio. Zabezpieczanie sprzętu odciskiem palca jest moim zdaniem i efektowne i efektywne, ale nie poleciłbym kupowania dużo droższej wersji klucza (BIO) ze względu na ubogą ilość opcji zabezpieczeń jaką posiada. Nie wdając się w nie do końca potrzebne szczegóły klucz bio umożliwia zabezpieczenie najpopularniejszych usług takich jak strona logowania do facebooka, microsoftu, google i będzie wymagać do zalogowania się włożenia klucza w port USB (wersja C bądź A), a także logowania do komputera domowego. Możemy zabezpieczyć logowanie do desktopu, logowanie do konta root, lub podniesienie uprawnień do poziomu konta root, a także logowanie do serwera SSH.
Wersja tańsza, czyli Yubikey 5 NFC (paradoksalnie) pozwala na wszystko to samo co droga wersja bio i dodatkowo jeszcze możemy zabezpieczyć wiadomości mailowe wysyłane z jednego konkretnego konta pocztowego za pomocą podpisu cyfrowego (Co może, ale nie musi zwiększyć poziomu integralności, czyli będziemy mieć pewność, że nikt nie zmienił zawartości wiadomości), a także możemy zaszyfrować wiadomość. Można też zabezpieczyć logowanie do KeepassXC za pomocą klucza.
Dziś pokażę jak zabezpieczyć logowanie do serwera zdalnego za pomocą FIDO2.

Zakładam, że masz już zainstalowany pakiet SSH i zainstalowałeś poprawki.
Serwer zdalny ma adres 192.168.15.15

ssh-keygen -t ed25519 -O resident -O application=ssh:TESCIK -O verify-required

W skrócie ta komenda generuje klucze prywatny i publiczny z użyciem algorytmu kryptograficznego ed25519. Klucz prywatny będzie przechowywany na yubikey i będzie tam notatka TESCIK. Zamiast TESCIK warto wpisać IP z jakim będziemy się łączyć, żeby wiedzieć który klucz jest do którego połączenia. Oprócz tej zmiennej reszta powinna być starannie skopiowana. Trzeba zwrócić uwagę, czy nie trzeba zatwierdzić generowania klucza przyciskiem na kluczu i PINem yubikey.
Przy generowaniu pojawi się informacja:

Enter file in which to save the key (/home/client/.ssh/id_ecdsa_sk): TEST

Tutaj wpisujemy nazwę klucza. Znów warto wykorzystać tą zmienną do nadania nazwy, która umożliwi łatwą identyfikację. Później można też nadać hasło do logowania tą metodą, ale nie widzę sensu, żeby to robić. o to jest klucz i PIN, żeby nie wpisywać setek haseł. Po wygenerowaniu klucza przesyłamy go na zdalny serwer z już zainstalowanym SSH i zrobionymi update.

ssh-copy-id -i /home/client/.ssh/TEST.pub server@192.168.15.15

Klucz publiczny powinien się elegancko przesłać. Następnie logujemy się już normalnie:

ssh server@192.168.15.15

Powinniśmy móc być w stanie po wpisaniu hasła, PINu (jeśli go nadawaliśmy) i dotknięciu przycisku klucza zalogować się do serwera zdalnego. Dodatkowo możemy wyłączyć logowanie hasłem i ustawić logowanie yubikeyem jako jedyne dopuszczalne. W pliku /etc/ssh/sshd_config zmieniamy nastepujące wpisy:

PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication yes
UsePAM no

Podsumowanie

Zabezpieczenie logowania do jakiejkolwiek usługi eliminuje możliwość ataku słownikowego, siłowego, a także w niektórych przypadkach przed phisingiem. W następnych wpisach pokażę jak zabezpieczam logowanie do kompa i podnoszenie uprawnień za pomocą yubikey. Stay tuned.

Podobne wpisy