How To Set Up Multi-Factor Authentication for SSH on CentOS 7

Introduction

An authentication factor is a single piece of information used to prove you have the rights to perform an action, like logging into a system. Kanał uwierzytelniania to sposób w jaki system uwierzytelniania dostarcza czynnik do użytkownika lub wymaga od niego odpowiedzi. Hasła i tokeny bezpieczeństwa są przykładami czynników uwierzytelniających; komputery i telefony są przykładami kanałów.

SSH domyślnie używa haseł do uwierzytelniania, a większość instrukcji hartowania SSH zaleca używanie klucza SSH. Jest to jednak nadal tylko jeden czynnik. Jeśli zły aktor skompromitował twój komputer, może użyć twojego klucza, aby skompromitować twoje serwery.

W tym poradniku skonfigurujemy wieloczynnikowe uwierzytelnianie, aby temu zapobiec. Uwierzytelnianie wieloczynnikowe (MFA) wymaga więcej niż jednego czynnika w celu uwierzytelnienia lub zalogowania się. Oznacza to, że zły aktor musiałby naruszyć wiele rzeczy, takich jak komputer i telefon, aby się do nich dostać. Różne rodzaje czynników są często podsumowywane jako:

1. Coś, co wiesz, jak hasło lub pytanie bezpieczeństwa
2. Coś, co masz, jak aplikacja uwierzytelniająca lub token bezpieczeństwa
3. Coś, czym jesteś, jak odcisk palca lub głos

Jednym wspólnym czynnikiem jest aplikacja OATH-TOTP, jak Google Authenticator. OATH-TOTP (Open Authentication Time-Based One-Time Password) jest otwartym protokołem, który generuje jednorazowe hasło, zazwyczaj 6-cyfrowy numer, który jest odnawiany co 30 sekund.

W tym artykule dowiesz się, jak włączyć uwierzytelnianie SSH za pomocą aplikacji OATH-TOTP oprócz klucza SSH. Dzięki temu logowanie do serwera przez SSH będzie wymagało dwóch czynników w dwóch kanałach, co sprawi, że będzie bezpieczniejsze niż samo hasło lub klucz SSH. Ponadto omówimy kilka dodatkowych przypadków użycia MFA oraz kilka pomocnych wskazówek i trików.

Wymagania wstępne

Aby wykonać ten poradnik, będziesz potrzebował:

• Jednego serwera CentOS 7 z użytkownikiem sudo non-root i kluczem SSH, który możesz skonfigurować, postępując zgodnie z tym poradnikiem dotyczącym początkowej konfiguracji serwera.
• Smartfon lub tablet z zainstalowaną aplikacją OATH-TOTP, taką jak Google Authenticator (iOS, Android).

Krok 1 – Instalacja Google PAM

W tym kroku zainstalujemy i skonfigurujemy Google PAM.

PAM, co jest skrótem od Pluggable Authentication Module, jest infrastrukturą uwierzytelniania używaną w systemach Linux do uwierzytelniania użytkownika. Ponieważ Google stworzył aplikację OATH-TOTP, stworzył również PAM, który generuje TOTP i jest w pełni kompatybilny z każdą aplikacją OATH-TOTP, jak Google Authenticator lub Authy.

Po pierwsze, musimy dodać EPEL (Extra Packages for Enterprise Linux) repo.

sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm

Następnie, zainstaluj PAM. Możesz zostać poproszony o zaakceptowanie klucza EPEL, jeśli jest to pierwsze użycie repo. Po zaakceptowaniu nie zostaniesz ponownie poproszony o zaakceptowanie klucza.

sudo yum install google-authenticator

Po zainstalowaniu PAM, użyjemy aplikacji pomocniczej, która jest dostarczana z PAM, aby wygenerować klucz TOTP dla użytkownika, do którego chcesz dodać drugi czynnik. Ten klucz jest generowany na zasadzie użytkownik po użytkowniku, a nie w całym systemie. Oznacza to, że każdy użytkownik, który chce używać TOTP auth app będzie musiał zalogować się i uruchomić aplikację pomocniczą, aby uzyskać własny klucz; nie można po prostu uruchomić go raz, aby włączyć go dla wszystkich (ale są pewne wskazówki na końcu tego samouczka, aby skonfigurować lub wymagać MFA dla wielu użytkowników).

Run the initialization app.

google-authenticator

Po uruchomieniu polecenia, zostaniesz poproszony o kilka pytań. Pierwsze z nich pyta czy tokeny uwierzytelniające powinny być oparte na czasie.

Output
Do you want authentication tokens to be time-based (y/n) y

Ten PAM pozwala na tokeny oparte na czasie lub sekwencyjne. Korzystanie z sekwencyjnych tokenów oznacza, że kod zaczyna się od pewnego punktu, a następnie zwiększa kod po każdym użyciu. Użycie tokenów opartych na czasie oznacza, że kod zmienia się losowo po upływie określonego czasu. Będziemy trzymać się opartych na czasie, ponieważ to jest to, co aplikacje takie jak Google Authenticator przewidują, więc odpowiedz y na tak.

Po udzieleniu odpowiedzi na to pytanie przewinie się wiele danych wyjściowych, w tym duży kod QR. W tym momencie użyj aplikacji authenticator w telefonie, aby zeskanować kod QR lub ręcznie wpisz tajny klucz. Jeśli kod QR jest zbyt duży do zeskanowania, możesz użyć adresu URL powyżej kodu QR, aby uzyskać jego mniejszą wersję. Po dodaniu go, zobaczysz sześciocyfrowy kod, który zmienia się co 30 sekund w aplikacji.

Uwaga: Upewnij się, że nagrywasz tajny klucz, kod weryfikacyjny i kody odzyskiwania w bezpiecznym miejscu, jak menedżer haseł. Kody odzyskiwania są jedynym sposobem na odzyskanie dostępu, jeśli na przykład utracisz dostęp do swojej aplikacji TOTP.

Pozostałe pytania informują PAM o sposobie działania. Przejdziemy przez nie jedno po drugim.

Output
Do you want me to update your "/home/sammy/.google_authenticator" file (y/n) y

To zapisuje klucz i opcje do pliku .google_authenticator. Jeśli powiesz „nie”, program zakończy działanie i nic nie zostanie zapisane, co oznacza, że uwierzytelniacz nie będzie działał.

Output
Do you want to disallow multiple uses of the same authenticationtoken? This restricts you to one login about every 30s, but it increasesyour chances to notice or even prevent man-in-the-middle attacks (y/n) y

Odpowiadając tutaj „tak”, zapobiegasz atakowi powtórkowemu, sprawiając, że każdy kod wygasa natychmiast po użyciu. Uniemożliwia to napastnikowi przechwycenie kodu, którego właśnie użyłeś, i zalogowanie się przy jego użyciu.

Output
By default, tokens are good for 30 seconds. In order to compensate forpossible time-skew between the client and the server, we allow an extratoken before and after the current time. If you experience problems withpoor time synchronization, you can increase the window from its defaultsize of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens). Do you want to do so? (y/n) n

Odpowiedź „tak” pozwala na użycie do 8 ważnych kodów w ruchomym czterominutowym oknie. Odpowiadając nie, ograniczasz to do 3 ważnych kodów w ruchomym oknie 1:30 minutowym. Jeśli nie znajdziesz problemów z oknem 1:30 minutowym, odpowiedź „nie” jest bezpieczniejszym wyborem.

Output
If the computer that you are logging into isn't hardened against brute-forcelogin attempts, you can enable rate-limiting for the authentication module.By default, this limits attackers to no more than 3 login attempts every 30s.Do you want to enable rate-limiting (y/n) y

Ograniczenie prędkości oznacza, że zdalny napastnik może próbować tylko określonej liczby prób przed zablokowaniem. Jeśli nie skonfigurowałeś wcześniej ograniczania prędkości bezpośrednio w SSH, zrobienie tego teraz jest świetną techniką zabezpieczającą.

Uwaga: Po zakończeniu tej konfiguracji, jeśli chcesz wykonać kopię zapasową swojego tajnego klucza, możesz skopiować plik ~/.google-authenticator do zaufanej lokalizacji. Stamtąd można go wdrożyć na dodatkowych systemach lub ponownie wdrożyć po utworzeniu kopii zapasowej.

Gdy PAM Google jest zainstalowany i skonfigurowany, następnym krokiem jest skonfigurowanie SSH, aby używał twojego klucza TOTP. Będziemy musieli powiedzieć SSH o PAM, a następnie skonfigurować SSH do korzystania z niego.

Krok 2 – Konfiguracja OpenSSH

Ponieważ będziemy dokonywać zmian w SSH przez SSH, ważne jest aby nigdy nie zamykać początkowego połączenia SSH. Zamiast tego należy otworzyć drugą sesję SSH w celu przeprowadzenia testów. W ten sposób unikniemy zablokowania dostępu do serwera, jeśli wystąpił błąd w konfiguracji SSH. Gdy wszystko działa, możesz bezpiecznie zamknąć wszystkie sesje.

Na początek edytujemy plik konfiguracyjny sshd. Używamy tutaj nano, który nie jest domyślnie zainstalowany w CentOS. Możesz go zainstalować za pomocą sudo yum install nano, lub użyć swojego ulubionego alternatywnego edytora tekstu.

sudo nano /etc/pam.d/sshd

Dodaj następującą linię na dole pliku.

. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Słowo nullok na końcu ostatniej linii mówi PAM, że ta metoda uwierzytelniania jest opcjonalna. To pozwala użytkownikom bez tokena OATH-TOTP logować się przy użyciu klucza SSH. Gdy wszyscy użytkownicy posiadają token OATH-TOTP, możesz usunąć nullok z tej linii, aby MFA stało się obowiązkowe.

Zapisz i zamknij plik.

Następnie skonfigurujemy SSH do obsługi tego rodzaju uwierzytelniania. Otwórz plik konfiguracyjny SSH do edycji.

sudo nano /etc/ssh/sshd_config

Poszukaj linii ChallengeResponseAuthentication. Wykreśl linię no i odkomentuj linię no.

. . .# Change to no to disable s/key passwordsChallengeResponseAuthentication yes#ChallengeResponseAuthentication no. . .

Zapisz i zamknij plik, a następnie uruchom ponownie SSH, aby ponownie załadować pliki konfiguracyjne. Ponowne uruchomienie usługi sshd nie spowoduje zamknięcia otwartych połączeń, więc nie będziesz ryzykował zablokowania się za pomocą tego polecenia.

sudo systemctl restart sshd.service

Aby sprawdzić, czy wszystko działa jak dotąd, otwórz inny terminal i spróbuj zalogować się przez SSH. Jeśli wcześniej utworzyłeś klucz SSH i używasz go, zauważysz, że nie musisz wpisywać hasła użytkownika ani kodu weryfikacyjnego MFA. Dzieje się tak, ponieważ klucz SSH domyślnie zastępuje wszystkie inne opcje uwierzytelniania. W przeciwnym razie powinieneś otrzymać monit o hasło i kod weryfikacyjny.

Jeśli chcesz się upewnić, że to, co zrobiłeś do tej pory, działa, w otwartej sesji SSH przejdź do ~/.ssh/ i zmień nazwę pliku authorized_keys, tymczasowo, a następnie otwórz nową sesję i zaloguj się przy użyciu naszego hasła i kodu weryfikacyjnego.

 
cd ~/.ssh
 
mv authorized_keys authorized_keys.bak
 

Gdy już sprawdzisz, że token TOTP działa, zmień nazwę pliku 'authorized_keys.bak’ z powrotem do poprzedniego stanu.

mv authorized_keys.bak authorized_keys

Następnie musimy włączyć klucz SSH jako jeden czynnik i kod weryfikacyjny jako drugi oraz powiedzieć SSH, które czynniki mają być używane i zapobiec nadrzędności klucza SSH nad wszystkimi innymi typami.

Krok 3 – Uświadomienie SSH o MFA

Otwórz ponownie plik konfiguracyjny sshd.

sudo nano /etc/ssh/sshd_config

Dodaj następującą linię na dole pliku. To mówi SSH jakie metody uwierzytelniania są wymagane. Ta linia mówi SSH, że potrzebujemy klucza SSH i albo hasła, albo kodu weryfikacyjnego (lub wszystkich trzech).

. . .# Added by DigitalOcean build processClientAliveInterval 120ClientAliveCountMax 2AuthenticationMethods publickey,password publickey,keyboard-interactive

Zapisz i zamknij plik.

Następnie otwórz ponownie plik konfiguracyjny PAM sshd.

sudo nano /etc/pam.d/sshd

Znajdź linię auth substack password-auth na górze pliku. Skomentuj ją, dodając znak # jako pierwszy znak w linii. To mówi PAM, aby nie pytał o hasło.

. . .#auth substack password-auth. . .

Zapisz i zamknij plik, a następnie zrestartuj SSH.

sudo systemctl restart sshd.service

Teraz spróbuj zalogować się do serwera ponownie z inną sesją. Inaczej niż ostatnio, SSH powinno poprosić o kod weryfikacyjny. Po jego wpisaniu zostaniesz zalogowany. Nawet jeśli nie widzisz żadnej informacji o tym, że użyto Twojego klucza SSH, oznacza to, że przy próbie logowania użyto dwóch czynników. Jeśli chcesz to zweryfikować, możesz dodać -v (dla verbose) po poleceniu SSH:

Example SSH output\
. . .debug1: Authentications that can continue: publickeydebug1: Next authentication method: publickeydebug1: Offering RSA public key: /Users/sammy/.ssh/id_rsadebug1: Server accepts key: pkalg ssh-rsa blen 279Authenticated with partial success.debug1: Authentications that can continue: keyboard-interactivedebug1: Next authentication method: keyboard-interactiveVerification code:

Pod koniec wyjścia zobaczysz, że SSH używa Twojego klucza SSH, a następnie prosi o podanie kodu weryfikacyjnego. Teraz możesz zalogować się przez SSH za pomocą klucza SSH i hasła jednorazowego. Jeśli chcesz wymusić wszystkie trzy typy uwierzytelniania, możesz wykonać następny krok.

Krok 4 – Dodawanie trzeciego czynnika (opcjonalnie)

W kroku 3 wymieniliśmy zatwierdzone typy uwierzytelniania w pliku sshd_config:

1. publickey (klucz SSH)
2. password publickey (hasło)
3. keyboard-interactive (kod weryfikacyjny)

Ale chociaż wymieniliśmy trzy różne czynniki, z opcjami, które wybraliśmy do tej pory, pozwalają one tylko na klucz SSH i kod weryfikacyjny. Jeśli chciałbyś mieć wszystkie trzy czynniki (klucz SSH, hasło i kod weryfikacyjny), jedna szybka zmiana włączy wszystkie trzy.

Otwórz plik konfiguracyjny PAM sshd.

sudo nano /etc/pam.d/sshd

Znajdź linię, którą wcześniej skomentowałeś, #auth substack password-auth, i odkomentuj ją, usuwając znak #. Zapisz i zamknij plik. Teraz ponownie uruchom SSH.

sudo systemctl restart sshd.service

Dzięki włączeniu opcji auth substack password-auth, PAM będzie teraz pytał o hasło oprócz sprawdzania klucza SSH i pytania o kod weryfikacyjny, co działało wcześniej. Teraz możemy użyć czegoś, co znamy (hasło) i dwóch różnych typów rzeczy, które mamy (klucz SSH i kod weryfikacyjny) na dwóch różnych kanałach.

Do tej pory, ten artykuł przedstawił jak włączyć MFA z kluczem SSH i czasowym hasłem jednorazowym. Jeśli to wszystko, czego potrzebujesz, możesz zakończyć tutaj. Jednakże, nie jest to jedyny sposób na uwierzytelnianie wieloczynnikowe. Poniżej znajduje się kilka dodatkowych sposobów użycia tego modułu PAM do uwierzytelniania wieloczynnikowego oraz kilka wskazówek i sztuczek dotyczących odzyskiwania, automatycznego użycia i więcej.

Porada 1 – Odzyskiwanie dostępu

Jak z każdym systemem, który utwardzasz i zabezpieczasz, stajesz się odpowiedzialny za zarządzanie tym bezpieczeństwem. W tym przypadku oznacza to, że nie tracimy klucza SSH lub tajnego klucza TOTP i upewniamy się, że mamy dostęp do aplikacji TOTP. Czasami jednak coś się dzieje i można stracić kontrolę nad kluczami lub aplikacjami, które są potrzebne do zalogowania się do systemu.

Utrata klucza SSH lub tajnego klucza TOTP

Jeśli utracimy klucz SSH lub tajny klucz TOTP, odzyskanie danych może być podzielone na kilka etapów. Pierwszym z nich jest powrót bez znajomości kodu weryfikacyjnego, a drugi jest znalezienie tajnego klucza lub regeneracji go do normalnego MFA login.

Aby dostać się po utracie tajnego klucza, który generuje kod weryfikacyjny na DigitalOcean Droplet, można po prostu użyć wirtualnej konsoli z pulpitu nawigacyjnego, aby zalogować się przy użyciu nazwy użytkownika i hasła.

W przeciwnym razie, trzeba będzie użytkownika administracyjnego, który ma dostęp sudo; upewnij się, że nie włączyć MFA dla tego użytkownika, ale użyj tylko klucz SSH. Jeśli ty lub inny użytkownik straci swój tajny klucz i nie będzie mógł się zalogować, wtedy użytkownik administracyjny może się zalogować i pomóc odzyskać lub zregenerować klucz dla dowolnego użytkownika używając sudo.

Po zalogowaniu istnieją dwa sposoby, aby pomóc w uzyskaniu sekretu TOTP:

1. Odzyskiwanie istniejącego klucza
2. Generowanie nowego klucza

W katalogu domowym każdego użytkownika tajny klucz i ustawienia Google Authenticator są zapisane w pliku ~/.google-authenticator. Pierwszą linią tego pliku jest klucz tajny. Szybkim sposobem na zdobycie tego klucza jest wykonanie poniższego polecenia, które wyświetli pierwszy wiersz pliku google-authenticator (tj. tajny klucz). Następnie weź ten tajny klucz i ręcznie wpisz go do aplikacji TOTP.

head -n 1 /home/sammy/.google_authenticator

Jeśli istnieje powód, aby nie używać istniejącego klucza (na przykład, nie można łatwo udostępnić tajnego klucza użytkownikowi, który ma wpływ na bezpieczeństwo lub istniejący klucz został naruszony), można całkowicie usunąć plik ~/.google-authenticator. Pozwoli to użytkownikowi zalogować się ponownie przy użyciu tylko jednego czynnika, zakładając, że nie wymusiłeś MFA przez usunięcie 'nullok’ w pliku '/etc/pam.d/sshd’. Następnie można uruchomić google-authenticator, aby wygenerować nowy klucz.

Utrata dostępu do aplikacji TOTP

Jeśli musisz zalogować się na swój serwer, ale nie masz dostępu do aplikacji TOTP, aby uzyskać kod weryfikacyjny, nadal możesz zalogować się przy użyciu kodów odzyskiwania, które zostały wyświetlone podczas pierwszego tworzenia tajnego klucza. Należy pamiętać, że te kody odzyskiwania są jednorazowe. Gdy jeden z nich zostanie użyty do zalogowania się, nie może być ponownie użyty jako kod weryfikacyjny.

Porada 2 – Zmiana ustawień uwierzytelniania

Jeśli chcesz zmienić ustawienia MFA po wstępnej konfiguracji, zamiast generować nową konfigurację ze zaktualizowanymi ustawieniami, możesz po prostu edytować plik ~/.google-authenticator. Ten plik jest ułożony w następujący sposób:

<secret key><options><recovery codes>

Opcje, które są ustawione w tym pliku, mają linię w sekcji opcji; jeśli odpowiedziałeś „nie” na daną opcję podczas początkowej konfiguracji, odpowiednia linia jest wykluczona z pliku.

Oto zmiany, jakie można wprowadzić w tym pliku:

• Aby włączyć kody sekwencyjne zamiast kodów czasowych, zmień linię " TOTP_AUTH na " HOTP_COUNTER 1.
• Aby zezwolić na wielokrotne użycie pojedynczego kodu, usuń linię " DISALLOW_REUSE.
• Aby rozszerzyć okno wygaśnięcia kodu do 4 minut, dodaj linię " WINDOW_SIZE 17.
• Aby wyłączyć wielokrotne nieudane logowanie (ograniczanie szybkości), usuń wiersz " RATE_LIMIT 3 30.
• Aby zmienić próg ograniczania szybkości, znajdź wiersz " RATE_LIMIT 3 30 i dostosuj liczby. 3 w oryginale oznacza liczbę prób w danym okresie czasu, a 30 oznacza okres czasu w sekundach.
• Aby wyłączyć używanie kodów odzyskiwania, usuń pięć 8-cyfrowych kodów na dole pliku.

Porada 3 – Unikanie MFA dla niektórych kont

Może zaistnieć sytuacja, w której pojedynczy użytkownik lub kilka kont usługowych (tj. kont używanych przez aplikacje, a nie ludzi) potrzebuje dostępu SSH bez włączonego MFA. Na przykład, niektóre aplikacje używające SSH, takie jak niektóre klienty FTP, mogą nie obsługiwać MFA. Jeśli aplikacja nie ma sposobu na żądanie kodu weryfikacyjnego, żądanie może utknąć, dopóki połączenie SSH się nie skończy.

Dopóki kilka opcji w /etc/pam.d/sshd jest ustawionych poprawnie, możesz kontrolować, które czynniki są używane na podstawie poszczególnych użytkowników.

Aby zezwolić na MFA dla niektórych kont i tylko na klucz SSH dla innych, upewnij się, że następujące ustawienia w /etc/pam.d/sshd są aktywne.

#%PAM-1.0auth required pam_sepermit.so#auth substack password-auth. . .# Used with polkit to reauthorize users in remote sessions-session optional pam_reauthorize.so prepareauth required pam_google_authenticator.so nullok

Tutaj auth substack password-auth jest wykomentowane, ponieważ hasła muszą być wyłączone. MFA nie może być wymuszone, jeśli niektóre konta mają mieć wyłączone MFA, więc zostaw opcję nullok w ostatniej linii.

Po ustawieniu tej konfiguracji po prostu uruchom google-authenticator jako każdy użytkownik, który potrzebuje MFA, i nie uruchamiaj go dla użytkowników, dla których będą używane tylko klucze SSH.

Porada 4 – Automatyzacja konfiguracji za pomocą zarządzania konfiguracją

Wielu administratorów systemów używa narzędzi do zarządzania konfiguracją, takich jak Puppet, Chef lub Ansible, do zarządzania swoimi systemami. Jeśli chcesz użyć takiego systemu do zainstalowania tajnego klucza, gdy tworzone jest konto nowego użytkownika, jest na to sposób.

google-authenticatorobsługuje przełączniki wiersza poleceń, aby ustawić wszystkie opcje w pojedynczym, nieinteraktywnym poleceniu. Aby zobaczyć wszystkie opcje, możesz wpisać google-authenticator --help. Poniżej znajduje się polecenie, które ustawiłoby wszystko tak, jak opisano w kroku 1:

google-authenticator -t -d -f -r 3 -R 30 -W

To odpowiada na wszystkie pytania, na które odpowiedzieliśmy ręcznie, zapisuje je do pliku, a następnie wyprowadza tajny klucz, kod QR i kody odzyskiwania. (Jeśli dodasz flagę -q, nie będzie żadnych danych wyjściowych.) Jeśli użyjesz tego polecenia w sposób zautomatyzowany, upewnij się, że przechwycisz tajny klucz i/lub kody odzyskiwania i udostępnisz je użytkownikowi.

Porada 5 – Wymuszanie MFA dla wszystkich użytkowników

Jeśli chcesz wymusić MFA dla wszystkich użytkowników nawet przy pierwszym logowaniu, lub jeśli wolisz nie polegać na użytkownikach przy generowaniu ich własnych kluczy, jest na to prosty sposób. Możesz po prostu użyć tego samego pliku .google-authenticator dla każdego użytkownika, ponieważ w pliku nie są przechowywane żadne dane specyficzne dla użytkownika.

Aby to zrobić, po początkowym utworzeniu pliku konfiguracyjnego, uprzywilejowany użytkownik musi skopiować plik do katalogu głównego każdego katalogu domowego i zmienić jego uprawnienia na odpowiedniego użytkownika. Możesz również skopiować plik do /etc/skel/, aby był on automatycznie kopiowany do katalogu domowego nowego użytkownika przy jego tworzeniu.

Ostrzeżenie: Może to stanowić zagrożenie bezpieczeństwa, ponieważ wszyscy dzielą ten sam drugi czynnik. Oznacza to, że jeśli dojdzie do jego wycieku, to tak jakby każdy użytkownik miał tylko jeden czynnik. Weź to pod uwagę, jeśli chcesz użyć tego podejścia.

Inną metodą wymuszenia utworzenia tajnego klucza użytkownika jest użycie skryptu basha, który:

1. Tworzy token TOTP,
2. Poprosi użytkownika o pobranie aplikacji Google Authenticator i zeskanowanie kodu QR, który zostanie wyświetlony, oraz
3. Uruchamia dla niego aplikację google-authenticator po sprawdzeniu, czy plik .google-authenticator już istnieje.

Aby upewnić się, że skrypt zostanie uruchomiony, gdy użytkownik się zaloguje, możesz nadać mu nazwę .bash_login i umieścić go w głównym katalogu domowym użytkownika.

Wnioski

Podsumowując, dzięki dwóm czynnikom (klucz SSH + token MFA) w dwóch kanałach (komputer + telefon), bardzo utrudniłeś zewnętrznemu agentowi sforsowanie drogi do twojej maszyny przez SSH i znacznie zwiększyłeś bezpieczeństwo swojej maszyny.