Jednym ze sposobów, który poprawia bezpieczeństwo systemów i ułatwia administrację, jest zastosowanie kluczy SSH zamiast standardowego logowania za pomocą hasła.

Zalety wykorzystania kluczy SSH zamiast logowania przy pomocy hasła

• Zwiększenie bezpieczeństwa: Szczególnie słabe hasła są podatne na złamanie metodą brute-force lub atakiem słownikowym.
• Łatwe zarządzanie dostępem: Możliwość łatwego zarządzania kluczami, umożliwiając lub blokując dostęp użytkownikom.
• Ułatwienie automatyzacji: Operacje takie jak kopie zapasowe mogą być łatwiej automatyzowane przy użyciu kluczy niż w przypadku wymagania interakcji z konsolą.
• Ochrona przed phishingiem: Stosowanie kluczy SSH zmniejsza ryzyko phishingu i wykradzenia haseł.
• Przygotowanie pod logowanie wielostopniowe: Ułatwia wprowadzenie w przyszłości logowania wielostopniowego, np. 2FA.

Jak wykorzystać klucze SSH do logowania

Aby wprowadzić logowanie do systemu przy użyciu kluczy SSH, należy przeprowadzić następujące kroki:

1. Generacja pary kluczy (publiczny oraz prywatny) na maszynie wykorzystywanej do zdalnego logowania się do serwera.
2. Konfiguracja klienta.
3. Konfiguracja serwera.

Dodatkowo w celu poprawienia bezpieczeństwa możliwe jest ustawienie systemu w sposób uniemożliwiający logowanie przy użyciu hasła, co zostało opisane w sekcji dotyczącej konfiguracji serwera.

Generowanie lokalnych kluczy

Pierwszym krokiem jest wygenerowanie pary kluczy na maszynie, z której ma następować logowanie do serwera. Jako typ klucza zalecany jest ed25519.

Do wygenerowania kluczy należy użyć polecenia:

ssh-keygen -t ed25519 -C "email@example.com"

Opcja -t ed25519 generuje parę kluczy, a -C "email@example.com" jest opcjonalna – ułatwia identyfikację klucza na serwerze, gdzie może być zapisanych wiele kluczy publicznych. Podczas generowania kluczy można ustalić hasło, co zwiększa bezpieczeństwo. Jednak wymaga to wpisywania hasła przy każdym użyciu klucza, co może komplikować procesy automatyzacji.

Wygenerowana para zostanie automatycznie umieszczona w katalogu ~/.ssh. Program stworzy dwa pliki:

• id_ed25519 – jest to klucz prywatny i należy go szczególnie chronić, ponieważ umożliwia on odszyfrowanie wiadomości zaszyfrowanych kluczem publicznym.
• id_ed25519.pub stanowi klucz publiczny. W przypadku uzyskiwania zdalnego dostępu zawartość tego pliku należy umieścić na liście autoryzowanych kluczy na serwerze.

Konfiguracja klienta SSH

Czynności opisane poniżej nie są wymagane do zdalnego logowania za pomocą kluczy, ale znacząco ułatwiają zarządzanie listą zdalnych serwerów oraz upraszczają sposób w jaki można się do nich podłączyć.

Konfiguracja klienta SSH polega na utworzeniu lub modyfikacji pliku ~/.ssh/config, którego przykładowa zawartość może wyglądać następująco:

# Dla serwera produkcyjnego
Host production
    HostName production.example.com
    User user_name
    Port 54343
    IdentityFile ~/.ssh/key_production

# Dla serwera developerskiego
Host dev
    HostName dev.example.com
    User developer
    Port 33234
    IdentityFile ~/.ssh/key_dev

# Domyślna konfiguracja dla innych serwerów
Host *
    User default_user
    IdentityFile ~/.ssh/default_key

Nazwy produkcja oraz dev stanowią etykietę którą można łatwo wykorzystać wraz z poleceniem ssh, np:

ssh production

W przypadku braku wpisów w pliku konfiguracyjnym do zdalnego serwera można połączyć się wykorzystując poniższe polecenie. Wykorzystując takie podejście wszystkie parametry połączenia, takie jak użytkownik, port oraz wykorzystywany klucz muszą zostać przekazane jako parametry do programu ssh.

ssh -i ~/.ssh/key_production -p 54343 user_name@production.example.com 

Jeżeli w systemie istnieje tylko jedna para wygenerowanych kluczy, w pliku konfiguracyjnym nie trzeba używać IdentityFile. Wykorzystany zostanie jedyny dostępny klucz.

Konfiguracja serwera

Umożliwienie logowania do serwera przy użyciu kluczy SSH wymaga realizacji dwóch kolejnych kroków:

Przygotowanie pliku authorized_keys

Aby umożliwić logowanie klientów do serwera za pomocą kluczy SSH, należy na serwerze utworzyć plik ~/.ssh/authorized_keys i dopisać do niego zawartość klucza publicznego klienta. Plik ten może zawierać wiele kluczy publicznych, umieszczonych jeden pod drugim.

Umożliwienie eskalacji uprawnień SUDO bez podawania hasła

Ponieważ możliwość używania hasła zostanie wyłączona należy zapewnić możliwość eskalacji uprawnień dla użytkownika (sudo) żeby umożliwić przeprowadzanie prac administracyjnych wymagających uprawnień zarządcy systemu.

Jedną z metod jest stworzenie pliku: /etc/sudoers.d/90-nopass-users (nazwa pliku może być dowolna, ponieważ nadrzędny plik konfiguracyjny załącza do konfiguracji wszystkie pliki znajdujące się w podkatalogu /etc/sudoers.d. Pliki załączane są w kolejności alfabetycznej. Zachowanie to może doprowadzić do sytuacji, że w przypadku definicji tych samych opcji w kilku plikach – wykorzystana zostanie ta, która znajduje się w pliku będącym na końcu listy.

Wspomniany plik powinien zawierać następujący wpis:

# User rules for debian
debian ALL=(ALL) NOPASSWD:ALL

Uwaga! Należy zwrócić uwagę na nazwę użytkownika – w tym przypadku debian. Tylko użytkownicy określeni w ten sposób mają możliwość eskalacji uprawnień (bez użycia hasła).

Dodatkowo warto zwrócić uwagę, że oprócz definicji w pliku 90-nopass-users użytkownik, który może używać polecenia sudo musi również znajdować się w grupie sudo. Można to sprawdzić w pliku /etc/group używając polecenia:

cat /etc/group | grep sudo

Zmiana pliku konfiguracyjnego serwera ssh

Większość standardowych instalacji serwera SSH (sshd) umożliwia domyślnie logowanie za pośrednictwem kluczy SSH. Ta metoda uwierzytelniania jest zalecana jako bardziej bezpieczna niż logowanie przy użyciu tradycyjnych haseł, ponieważ wykorzystuje kryptografię asymetryczną, która jest trudniejsza do złamania.

Aby sprawdzić, czy logowanie przy użyciu kluczy jest włączone na serwerze, należy sprawdzić plik konfiguracyjny serwera sshd, /etc/ssh/sshd_config pod kątem występowania linii:

PubkeyAuthentication yes

To ustawienie włącza uwierzytelnianie za pomocą kluczy publicznych. Jeżeli wspomniana linia nie występuje, domyślna wartość dla większości dystrybucji Linuxa i innych systemów operacyjnych obsługujących SSH jest zazwyczaj ustawiona na yes.

Tak jak poprzednim razem, po wprowadzeniu zmian należy ponownie uruchomić serwer sshd w celu przeładowania nowej konfiguracji:

sudo systemctl restart sshd

Weryfikacja konfiguracji

Po zakończeniu konfiguracji serwera, należy się z niego wylogować i ponownie zalogować. Prawidłowa konfiguracja oraz użycie odpowiednich kluczy powinny umożliwić dostęp bez konieczności wprowadzania hasła.

Następnie, należy zweryfikować możliwość eskalacji uprawnień za pomocą polecenia sudo bez żądania hasła. Jeśli jest to możliwe, oznacza to, że konfiguracja została przeprowadzona poprawnie.

Wyłączenie możliwości logowania hasłem

Uwaga! Bardzo ważne jest przeprowadzenie weryfikacji konfiguracji opisanej w poprzedniej sekcji, gdyż w przypadku błędu utracona zostanie możliwość zarządzania systemem.

Po potwierdzeniu prawidłowego działania zdalnej administracji systemem przy użyciu kluczy SSH, można zwiększyć bezpieczeństwo, wyłączając możliwość logowania hasłem. W tym celu w pliku /etc/ssh/sshd_config należy ustawić lub odkomentować następującą wartość:

PasswordAuthentication no

Następnie należy zweryfikować katalog /etc/ssh/sshd_config.d czy nie zawiera dodatkowych plików konfiguracyjnych. Jeżeli takie pliki występują, wymagają one sprawdzenia czy nie nadpisują wartości zdefiniowanych w głównym pliku konfiguracyjnym, a następnie w razie potrzeby je zmodyfikować lub usunąć.

Podsumowanie

Omówione operacje dotyczą wszelkich maszyn działających pod kontrolą systemów Linux, zarówno zdalnych serwerów wirtualnych (VPS), jak i urządzeń w lokalnych sieciach komputerowych. Przykłady to komputery jednopłytkowe, takie jak Raspberry Pi, BeagleBone czy Orange Pi.

Konfiguracja klienta wpływa również na działanie programu scp. Dzięki temu ułatwione zostaje przesyłanie np. aplikacji zbudowanej poprzez kompilację krzyżową do urządzenia na którym będzie ona uruchamiana.

Autoryzację za pomocą klucza SSH można wykorzystać do procedury automatycznego testowania oprogramowania zbudowanego w procesie kompilacji krzyżowej. Jeżeli serwer będzie posiadał wpis reprezentujący system CI – możliwe jest napisanie pipelina, który wgra skompilowany program oraz uruchomi testy na docelowym sprzęcie.