Jak skonfigurować uwierzytelnianie oparte na kluczach SSH na serwerze Linux

Wprowadzenie

SSH, czyli bezpieczna powłoka, jest szyfrowanym protokołem używanym do administrowania i komunikowania się z serwerami. Podczas pracy z serwerem linuksowym większość czasu spędza się w terminalu, łącząc się z nim przez SSH.

Mimo że istnieje kilka różnych sposobów logowania się do serwera SSH, w tym poradniku skupimy się na konfiguracji kluczy SSH. Klucze SSH zapewniają łatwy, a zarazem bardzo bezpieczny sposób logowania się do serwera. Z tego powodu jest to metoda, którą zalecamy wszystkim użytkownikom.

Jak działają klucze SSH?

Serwer SSH może uwierzytelniać klientów za pomocą różnych metod. Najbardziej podstawową z nich jest uwierzytelnianie za pomocą hasła, które jest łatwe w użyciu, ale nie najbezpieczniejsze.

Mimo że hasła są przesyłane do serwera w bezpieczny sposób, nie są one wystarczająco złożone ani długie, aby były odporne na powtarzające się ataki. Nowoczesna moc obliczeniowa w połączeniu z automatycznymi skryptami sprawia, że brute forcing konta chronionego hasłem jest bardzo możliwy. Chociaż istnieją inne metody dodawania dodatkowych zabezpieczeń (fail2ban, itp.), klucze SSH okazują się być niezawodną i bezpieczną alternatywą.

Pary kluczy SSH to dwa kryptograficznie bezpieczne klucze, które mogą być użyte do uwierzytelnienia klienta na serwerze SSH. Każda para kluczy składa się z klucza publicznego i prywatnego.

Klucz prywatny jest przechowywany przez klienta i powinien być utrzymywany w absolutnej tajemnicy. Jakiekolwiek ujawnienie klucza prywatnego pozwoli atakującemu na zalogowanie się do serwerów skonfigurowanych z powiązanym kluczem publicznym bez dodatkowego uwierzytelniania. Jako dodatkowe zabezpieczenie, klucz może być zaszyfrowany na dysku za pomocą hasła.

Przypisany klucz publiczny może być swobodnie udostępniany bez żadnych negatywnych konsekwencji. Klucz publiczny może być użyty do szyfrowania wiadomości, które tylko klucz prywatny może odszyfrować. Ta właściwość jest wykorzystywana jako sposób uwierzytelniania przy użyciu pary kluczy.

Klucz publiczny jest przesyłany na zdalny serwer, do którego chcemy się logować za pomocą SSH. Klucz ten jest dodawany do specjalnego pliku w ramach konta użytkownika, na które będziemy się logować, o nazwie ~/.ssh/authorized_keys.

Gdy klient próbuje uwierzytelnić się przy użyciu kluczy SSH, serwer może sprawdzić, czy jest on w posiadaniu klucza prywatnego. Jeśli klient jest w stanie udowodnić, że posiada klucz prywatny, sesja powłoki jest tworzona lub żądane polecenie jest wykonywane.

Jak utworzyć klucze SSH

Pierwszym krokiem do skonfigurowania uwierzytelniania kluczem SSH do serwera jest wygenerowanie pary kluczy SSH na lokalnym komputerze.

Aby to zrobić, możemy użyć specjalnego narzędzia o nazwie ssh-keygen, które jest dołączone do standardowego zestawu narzędzi OpenSSH. Domyślnie utworzy ono parę kluczy RSA o długości 2048 bitów, co jest wystarczające dla większości zastosowań.

Na lokalnym komputerze wygeneruj parę kluczy SSH, wpisując:

ssh-keygen

Generating public/private rsa key pair.Enter file in which to save the key (/home/username/.ssh/id_rsa):

Narzędzie poprosi o wybranie lokalizacji dla wygenerowanych kluczy. Domyślnie, klucze będą przechowywane w katalogu ~/.ssh w katalogu domowym użytkownika. Klucz prywatny będzie się nazywał id_rsa a powiązany z nim klucz publiczny będzie się nazywał id_rsa.pub.

Zazwyczaj najlepiej jest trzymać się domyślnej lokalizacji na tym etapie. Pozwoli to Twojemu klientowi SSH na automatyczne odnalezienie kluczy SSH podczas próby uwierzytelnienia. Jeśli chcesz wybrać niestandardową ścieżkę, wpisz ją teraz, w przeciwnym razie naciśnij ENTER, aby zaakceptować domyślną.

Jeśli wcześniej wygenerowałeś parę kluczy SSH, możesz zobaczyć monit, który wygląda tak:

/home/username/.ssh/id_rsa already exists.Overwrite (y/n)?

Jeśli wybierzesz opcję nadpisania klucza na dysku, nie będziesz mógł już uwierzytelniać się przy użyciu poprzedniego klucza. Bądź bardzo ostrożny wybierając opcję „tak”, ponieważ jest to destrukcyjny proces, którego nie można odwrócić.

Created directory '/home/username/.ssh'.Enter passphrase (empty for no passphrase):Enter same passphrase again: 

Następnie zostaniesz poproszony o wprowadzenie hasła dla klucza. Jest to opcjonalne hasło, które może być użyte do zaszyfrowania pliku klucza prywatnego na dysku.

Możesz się zastanawiać, jakie korzyści daje klucz SSH, jeśli nadal musisz wpisywać hasło. Niektóre z nich to:

• Prywatny klucz SSH (część, która może być chroniona frazą hasła), nigdy nie jest udostępniany w sieci. Fraza hasła jest używana tylko do odszyfrowania klucza na lokalnym komputerze. Oznacza to, że brute forcing przez sieć nie będzie możliwy w przypadku hasła.
• Klucz prywatny jest przechowywany w katalogu zastrzeżonym. Klient SSH nie rozpozna kluczy prywatnych, które nie są przechowywane w zastrzeżonych katalogach. Sam klucz musi mieć również ograniczone uprawnienia (odczyt i zapis dostępne tylko dla właściciela). Oznacza to, że inni użytkownicy systemu nie mogą węszyć.
• Atakujący, który chciałby złamać hasło prywatnego klucza SSH, musi mieć już dostęp do systemu. Oznacza to, że będzie miał dostęp do Twojego konta użytkownika lub konta root. Jeśli jesteś w takiej sytuacji, fraza hasła może uniemożliwić atakującemu natychmiastowe zalogowanie się na inne serwery. To da Ci czas na stworzenie i wdrożenie nowej pary kluczy SSH i usunięcie dostępu do skompromitowanego klucza.

Ponieważ klucz prywatny nigdy nie jest wystawiony na działanie sieci i jest chroniony przez uprawnienia do plików, plik ten nie powinien być dostępny dla nikogo poza Tobą (i użytkownikiem root). Fraza hasła służy jako dodatkowa warstwa ochrony w przypadku, gdy te warunki zostaną naruszone.

Fraza hasła jest opcjonalnym dodatkiem. Jeśli je wprowadzisz, będziesz musiał je podawać za każdym razem, gdy będziesz używał tego klucza (chyba, że używasz agenta SSH, który przechowuje odszyfrowany klucz). Zalecamy użycie frazy hasła, ale jeśli nie chcesz jej podawać, możesz po prostu nacisnąć ENTER, aby ominąć ten monit.

Your identification has been saved in /home/username/.ssh/id_rsa.Your public key has been saved in /home/username/.ssh/id_rsa.pub.The key fingerprint is:a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_hostThe key's randomart image is:+------+| ..o || E o= . || o. o || .. || ..S || o o. || =o.+. ||. =++.. ||o=++. |+-----------------+

Masz teraz klucz publiczny i prywatny, którego możesz użyć do uwierzytelnienia. Następnym krokiem jest umieszczenie klucza publicznego na serwerze, aby można było użyć uwierzytelniania klucza SSH do logowania.

Jak osadzić klucz publiczny podczas tworzenia serwera

Jeśli uruchamiasz nowy serwer DigitalOcean, możesz automatycznie osadzić klucz publiczny SSH na koncie głównym nowego serwera.

Na dole strony tworzenia kropli znajduje się opcja dodania kluczy SSH do serwera:

Jeśli dodałeś już plik klucza publicznego do konta DigitalOcean, zobaczysz go tutaj jako opcję do wyboru (w powyższym przykładzie są dwa istniejące klucze: „Klucz do pracy” i „Klucz domowy”). Aby osadzić istniejący klucz, po prostu kliknij na niego, a on zostanie podświetlony. Możesz osadzić wiele kluczy na jednym serwerze:

Jeśli nie masz jeszcze wgranego publicznego klucza SSH na swoim koncie, lub jeśli chcesz dodać nowy klucz do swojego konta, kliknij przycisk „+ Dodaj klucz SSH”. Pojawi się monit:

W polu „Zawartość klucza SSH” wklej treść swojego klucza publicznego SSH. Zakładając, że wygenerowałeś klucze za pomocą powyższej metody, możesz uzyskać zawartość klucza publicznego na swoim lokalnym komputerze wpisując:

cat ~/.ssh/id_rsa.pub

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNqqi1mHLnryb1FdbePrSZQdmXRZxGZbo0gTfglysq6KMNUNY2VhzmYN9JYW39yNtjhVxqfW6ewc+eHiL+IRRM1P5ecDAaL3V0ou6ecSurU+t9DR4114mzNJ5SqNxMgiJzbXdhR+j55GjfXdk0FyzxM3a5qpVcGZEXiAzGzhHytUV51+YGnuLGaZ37nebh3UlYC+KJev4MYIVww0tWmY+9GniRSQlgLLUQZ+FcBUjaqhwqVqsHe4F/woW1IHe7mfm63GXyBavVc+llrEzRbMO111MogZUcoWDI9w7UIm8ZOTnhJsk7jhJzG2GpSXZHmly/a/buFaaFnmfZ4MYPkgJD [email protected]

Wklej tę wartość w całości do większego pola. W polu „Komentarz (opcjonalnie)” możesz wybrać etykietę dla klucza. Będzie to wyświetlane jako nazwa klucza w interfejsie DigitalOcean:

Podczas tworzenia Dropleta, wybrane publiczne klucze SSH zostaną umieszczone w pliku ~/.ssh/authorized_keys konta użytkownika root. To pozwoli Ci zalogować się na serwer z komputera z Twoim kluczem prywatnym.

Jak skopiować klucz publiczny na serwer

Jeśli masz już dostępny serwer i nie osadziłeś kluczy podczas tworzenia, nadal możesz przesłać swój klucz publiczny i użyć go do uwierzytelnienia się na serwerze.

Metoda, której używasz zależy w dużej mierze od narzędzi, które masz dostępne i szczegółów Twojej obecnej konfiguracji. Wszystkie poniższe metody dają ten sam efekt końcowy. Najprostsza, najbardziej zautomatyzowana metoda jest pierwsza, a kolejne wymagają dodatkowych ręcznych kroków, jeśli nie jesteś w stanie użyć poprzednich metod.

Kopiowanie klucza publicznego przy użyciu SSH-Copy-ID

Najprostszym sposobem na skopiowanie klucza publicznego na istniejący serwer jest użycie narzędzia o nazwie ssh-copy-id. Ze względu na swoją prostotę, ta metoda jest zalecana jeśli jest dostępna.

Narzędzie ssh-copy-id jest zawarte w pakietach OpenSSH w wielu dystrybucjach, więc możesz mieć je dostępne w swoim lokalnym systemie. Aby ta metoda zadziałała, musisz mieć już dostęp SSH oparty na haśle do swojego serwera.

Aby użyć tego narzędzia, musisz po prostu określić zdalnego hosta, z którym chcesz się połączyć i konto użytkownika, do którego masz dostęp SSH oparty na haśle. Jest to konto, na które zostanie skopiowany klucz publiczny SSH.

Składnia jest następująca:

ssh-copy-id username@remote_host

Możesz zobaczyć komunikat jak poniżej:

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.Are you sure you want to continue connecting (yes/no)? yes

To oznacza, że Twój lokalny komputer nie rozpoznaje zdalnego hosta. Zdarzy się to przy pierwszym połączeniu z nowym hostem. Wpisz „tak” i naciśnij ENTER, aby kontynuować.

Następnie narzędzie przeskanuje Twoje konto lokalne w poszukiwaniu klucza id_rsa.pub , który utworzyliśmy wcześniej. Po znalezieniu klucza zapyta o hasło do konta zdalnego użytkownika:

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new [email protected]'s password:

Wpisz hasło (ze względów bezpieczeństwa nie będzie ono wyświetlane) i naciśnij ENTER. Narzędzie połączy się z kontem na zdalnym hoście używając podanego hasła. Następnie skopiuje zawartość twojego klucza ~/.ssh/id_rsa.pub do pliku w katalogu domowym zdalnego konta ~/.ssh o nazwie authorized_keys.

Zobaczysz dane wyjściowe, które wyglądają tak:

Number of key(s) added: 1Now try logging into the machine, with: "ssh '[email protected]'"and check to make sure that only the key(s) you wanted were added.

W tym momencie Twój id_rsa.pub klucz został przesłany na zdalne konto. Możesz przejść do następnej sekcji.

Kopiowanie klucza publicznego za pomocą SSH

Jeśli nie masz ssh-copy-id dostępnego, ale masz dostęp SSH oparty na haśle do konta na serwerze, możesz przesłać swoje klucze używając konwencjonalnej metody SSH.

Możemy to zrobić poprzez wypisanie zawartości naszego klucza publicznego SSH na naszym lokalnym komputerze i przesłanie go przez połączenie SSH do zdalnego serwera. Po drugiej stronie, możemy upewnić się, że katalog ~/.ssh istnieje pod kontem, którego używamy, a następnie wypisać zawartość, którą przesłaliśmy do pliku authorized_keys w tym katalogu.

Użyjemy symbolu przekierowania >>, aby dołączyć zawartość zamiast ją nadpisywać. To pozwoli nam dodawać klucze bez niszczenia wcześniej dodanych kluczy.

Pełne polecenie będzie wyglądało tak:

cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Możesz zobaczyć komunikat taki jak ten:

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.Are you sure you want to continue connecting (yes/no)? yes

To tylko oznacza, że twój lokalny komputer nie rozpoznaje zdalnego hosta. Zdarzy się to przy pierwszym połączeniu z nowym hostem. Wpisz „tak” i naciśnij ENTER, aby kontynuować.

Potem zostaniesz poproszony o podanie hasła do konta, z którym próbujesz się połączyć:

[email protected]'s password:

Po wpisaniu hasła, zawartość twojego klucza id_rsa.pub zostanie skopiowana na koniec pliku authorized_keys konta zdalnego użytkownika. Przejdź do następnej sekcji, jeśli to się udało.

Kopiowanie klucza publicznego ręcznie

Jeśli nie masz dostępu SSH opartego na haśle do swojego serwera, będziesz musiał wykonać powyższy proces ręcznie.

Zawartość twojego pliku id_rsa.pub będzie musiała zostać dodana do pliku ~/.ssh/authorized_keys na twoim zdalnym komputerze.

Aby wyświetlić zawartość twojego id_rsa.pub klucza, wpisz to na swoim lokalnym komputerze:

cat ~/.ssh/id_rsa.pub

Zobaczysz zawartość klucza, która może wyglądać mniej więcej tak:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

Dostań się do swojego zdalnego hosta za pomocą dowolnej dostępnej metody. Na przykład, jeśli Twój serwer to DigitalOcean Droplet, możesz zalogować się za pomocą konsoli internetowej w panelu sterowania:

Gdy masz już dostęp do swojego konta na zdalnym serwerze, powinieneś upewnić się, że katalog ~/.ssh jest utworzony. To polecenie utworzy katalog, jeśli to konieczne, lub nie zrobi nic, jeśli już istnieje:

mkdir -p ~/.ssh

Teraz możesz utworzyć lub zmodyfikować plik authorized_keys w obrębie tego katalogu. Możesz dodać zawartość swojego pliku id_rsa.pub na koniec pliku authorized_keys, tworząc go w razie potrzeby, używając tego:

echo public_key_string >> ~/.ssh/authorized_keys

W powyższym poleceniu zastąp public_key_string danymi wyjściowymi z polecenia cat ~/.ssh/id_rsa.pub, które wykonałeś w swoim lokalnym systemie. Powinno ono zaczynać się od ssh-rsa AAAA....

Jeśli to zadziała, możesz przejść do próby uwierzytelnienia bez hasła.

Uwierzytelnianie na serwerze przy użyciu kluczy SSH

Jeśli pomyślnie wykonałeś jedną z powyższych procedur, powinieneś być w stanie zalogować się na zdalnego hosta bez hasła zdalnego konta.

Podstawowy proces jest taki sam:

ssh username@remote_host

Jeśli jest to Twoje pierwsze połączenie z tym hostem (jeśli użyłeś ostatniej metody powyżej), możesz zobaczyć coś takiego:

The authenticity of host '111.111.11.111 (111.111.11.111)' can't be established.ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe.Are you sure you want to continue connecting (yes/no)? yes

To oznacza, że Twój lokalny komputer nie rozpoznaje zdalnego hosta. Wpisz „tak”, a następnie naciśnij ENTER, aby kontynuować.

Jeśli nie podałeś hasła dla klucza prywatnego, zostaniesz natychmiast zalogowany. Jeśli podałeś hasło dla klucza prywatnego podczas jego tworzenia, będziesz musiał je teraz wprowadzić. Następnie powinna zostać utworzona nowa sesja powłoki z kontem na zdalnym systemie.

Jeśli się powiedzie, przejdź dalej, aby dowiedzieć się, jak zablokować serwer.

Wyłączanie uwierzytelniania hasłem na serwerze

Jeśli udało Ci się zalogować na swoje konto za pomocą SSH bez hasła, to znaczy, że uwierzytelnianie oparte na kluczach SSH do Twojego konta zostało pomyślnie skonfigurowane. Jednak Twój mechanizm uwierzytelniania oparty na haśle jest nadal aktywny, co oznacza, że Twój serwer jest nadal narażony na ataki typu brute-force.

Przed wykonaniem kroków w tej sekcji upewnij się, że albo masz skonfigurowane uwierzytelnianie oparte na kluczach SSH dla konta root na tym serwerze, albo najlepiej, że masz skonfigurowane uwierzytelnianie oparte na kluczach SSH dla konta na tym serwerze z dostępem sudo. Ten krok zablokuje logowania oparte na hasłach, więc upewnienie się, że nadal będziesz w stanie uzyskać dostęp administracyjny, jest kluczowe.

Po spełnieniu powyższych warunków zaloguj się do zdalnego serwera za pomocą kluczy SSH, jako root lub na konto z uprawnieniami sudo. Otwórz plik konfiguracyjny demona SSH:

sudo nano /etc/ssh/sshd_config

Wewnątrz pliku poszukaj dyrektywy o nazwie PasswordAuthentication. To może być zakomentowane. Odkomentuj tę linię i ustaw wartość na „no”. To wyłączy możliwość logowania się przez SSH z użyciem haseł do kont:

PasswordAuthentication no

Zapisz i zamknij plik, gdy skończysz. Aby faktycznie wdrożyć zmiany, które właśnie wprowadziliśmy, należy ponownie uruchomić usługę.

Na maszynach Ubuntu lub Debian możesz wydać to polecenie:

sudo service ssh restart

Na maszynach CentOS/Fedora demon nazywa się sshd:

sudo service sshd restart

Po wykonaniu tego kroku pomyślnie przekształciłeś swojego demona SSH tak, aby odpowiadał tylko na klucze SSH.

Wniosek

Powinieneś teraz mieć skonfigurowane i działające uwierzytelnianie oparte na kluczach SSH na swoim serwerze, pozwalające na zalogowanie się bez podawania hasła do konta. Stąd jest wiele kierunków, w których możesz się udać. Jeśli chcesz dowiedzieć się więcej o pracy z SSH, zajrzyj do naszego przewodnika po podstawach SSH.