Jakiś czas temu pisałem o zdalnej synchronizacji danych między różnymi komputerami/serwerami przy wykorzystaniu programu rsync i połączenia po SSH. Przy tej okazji wspomniałem, że do uwierzytelnienia przy połączeniach (SSH/SCP) można wykorzystać również certyfikaty/pliki-klucze, dzięki czemu może być nie tylko bezpieczniej, ale i – przy rezygnacji z hasła dla pewnych zadań – wygodniej (da się też w ten sposób zautomatyzować połączenia, np. na potrzeby skryptów). I właśnie logowaniu do/przez SSH/SCP z wykorzystaniem kluczy chciałbym poświęcić ten wpis…

Logowanie SSH/SCP z certyfikatem

Zacznijmy może od tego, po co w ogóle zawracać sobie głowę jakimiś tam plikami-kluczami, skoro logowanie za pomocą loginu i hasła działa, i zapewne w wielu przypadkach faktycznie nie potrzeba niczego więcej (lub tak tylko może się wydawać).

Pierwsze co pewnie usłyszycie od „bardziej zaawansowanych” (w tym też takich, którym się tylko tak wydaje ;-)) będzie to, że tak jest bezpieczniej, i w żadnym wypadku nie zezwalajcie na logowanie się po SSH do systemu za pomocą tylko loginu i hasła, a już na pewno w przypadku konto o podwyższonych uprawnieniach (m.in. root).

I oczywiście jest w tym sporo prawdy, i każdemu zalecam korzystanie z pliku-klucza (i/lub uwierzytelnienia dwuskładnikowego) jako dodatkowego (!) elementu zabezpieczenia, to bym jednak nie przesadzał – bo wprawdzie łatwiej jest przechwycić Wasz login i hasło niż plik klucza, to jednak w niektórych przypadkach przechwycenie tego pliku również nie będzie stanowić problemu.

Klucz z hasłem czy bez

Zanim przejdę do spraw bardziej technicznych, to chciałbym jeszcze poruszyć jeden temat – czy generować (i używać) certyfikat/klucz zabezpieczony hasłem, tak, że oprócz wskazania tego pliku trzeba byłe jeszcze podać hasło zabezpieczające ów plik.

Nie ma tu chyba jednej właściwej odpowiedzi, choć ja do hasła zabezpieczającego certyfikat (plik klucza) podchodzę dość sceptycznie, i sens widzę tylko w niektórych przypadkach, np. gdy plik-klucza jest naszym jedynym uwierzytelnieniem – w takim przypadku oprócz wskazania pliku-klucza, musimy jeszcze podać do niego dodatkowy element, czyli hasło (a użytkownik z ograniczeniami, np. wykorzystywany przez skrypty korzysta z klucza bez hasła).

Osobiście preferuje wariant, gdy logowanie zabezpieczone jest wieloskładnikowo, choć bez przesady – czyli właśnie certyfikatem (często bez hasła), do tego koniecznie nazwa użytkownika i hasło (drugi składnik), i jako ostatni (trzeci) element zabezpieczenia stosuje kod jednorazowy (token).

A do tego obowiązkowo wiadomość e-mail z informacją o każdorazowym zalogowaniu użytkownika…

I w takim układzie dodawanie jeszcze hasła do certyfikatu uważam – najczęściej – za zbyteczne, choć w niektórych sytuacjach sięgam również i po ten dodatkowy – czwarty – element zabezpieczający proces logowania przez SSH/SCP (tak samo, jak restrykcje dotyczące konkretnych adresów IP).

W każdym razie wybór zostawiam Wam, macie kilka elementów, możecie miksować je właściwie swobodnie:

• Login i hasło (system)
• Certyfikat (plik klucza)
• Kod jednorazowy (token)
• Hasło do certyfikatu (wymaga certyfikatu)
• Ograniczenie logowania do wybranych adresów IP
• Powiadomienie e-mail o logowaniu użytkownika do systemu

Generowanie (pary) kluczy

Generowanie kluczy możemy przeprowadzić wprawdzie na dowolnym urządzeniu, to ja w tym poradniku pokaże to na przykładzie komputera, z którym będę chciał się później zdalnie połączyć, dodatkowo będąc zalogowanym, na którego użytkownika będę wykorzystywał do tego połączenia.

Zaczynamy od wygenerowania pary kluczy – prywatny i publiczny:

ssh-keygen -t rsa -b 4096 

Podczas tej operacji możemy wybrać, czy certyfikat (prywatny) będzie zabezpieczony hasłem (gdy nie chcecie hasła, to po prostu nie wpisujecie żadnego hasła), oraz wskazać lokalizację do zapisania plików – domyślnie jest to katalog domowy użytkownika.

Po tej operacji w podkatalogu „.ssh” w Waszym domowym katalogu (jeśli nie zmieniliście ścieżki zapisu podczas generowania) pojawią się 2 pliki:

• $HOME/.ssh/id_rsa – klucz prywatny, który będzie służył do uwierzytelnienia (maszyna lokalna)
• $HOME/.ssh/id_rsa.pub – klucz publiczny, który będzie na zdalnej maszynie (maszyna zdalna)

chmod 700 $HOME/.ssh
chmod 600 $HOME/.ssh/*

Kopiowanie klucza publicznego

Kolejnym krokiem jest skopiowanie (przesłanie) wygenerowanego klucza publicznego (id_rsa.pub) na serwer, z którym będziemy się łączyć i zapisanie w katalogu domowym użytkownika, który będzie wykorzystywany do połączenia (klucz publiczny zapisujemy pod nazwą „authorized_keys” w podkatalogu „.ssh”).

Jeśli jest to komputer, na którym były generowane klucze, to wystarczy skorzystać z polecenia:

cp $HOME/.ssh/id_rsa.pub $HOME/.ssh/authorized_keys

Lub np. w przypadku użytkownika root może to być:

cp /root/.ssh/id_rsa.pub /root/.ssh/authorized_keys

Jeśli klucz musimy przesłać na zdalny (inny) komputer/serwer, to możemy to zrobić za pomocą WinSCP, lub korzystając z polecenia:

ssh-copy-id -i $HOME/.ssh/id_rsa.pub użytkownik@IP/host -p PORT

Lub:

scp -P PORT $HOME/.ssh/id_rsa.pub użytkownik@IP-lub-host:~/.ssh/authorized_keys

Np.:

ssh-copy-id -i $HOME/.ssh/id_rsa.pub [email protected] -p 22
scp -P 22 $HOME/.ssh/id_rsa.pub [email protected]:~/.ssh/authorized_keys

Jeśli planujecie ze zdalnym serwerem – na którym znalazł się klucz publiczny – połączyć się zdalnie, to oczywiście w programie wykorzystywanym do połączenia musicie wskazać lokalizację klucza prywatnego.

Nie dotyczy połączenia SSH, gdzie zostanie od automatycznie pobrany z lokalizacji $HOME/.ssh/id_rsa, i nie trzeba ścieżki do niego wskazywać w poleceniu:

ssh 123.124.125.126 -p 22 -l patryk

Z kluczem czy (czasem) bez

Na maszynie zdalnej, czyli na tej, z którą będziecie się łączyli z wykorzystaniem wygenerowanej pary kluczy, warto jeszcze ustalić, jak system ma podchodzić do (braku) klucza.

Przy standardowych ustawieniach zdalny system będzie korzystał z klucza prywatnego, ale nie będzie go wymagał – w przypadku niewskazania/braku klucza prywatnego autoryzacja nastąpi za pomocą nazwy użytkownika i hasła.

Wygodne, ale skoro zadaliśmy sobie trud wygenerowania klucza, to chyba nie po to, by można było do systemu nadal zalogować się bez niego.

Dlatego edytujemy plik (na maszynie, z która będziemy się łączyć):

sudo nano /etc/ssh/sshd_config

I dodajemy linijkę, która wymusi korzystanie z certyfikatów:

AuthenticationMethods publickey

W powyższym wariancie autoryzacja będzie odbywać się tylko i wyłącznie za pomocą klucza, który będzie wymagany (bez nazwy użytkownika i hasła, chyba że hasła do certyfikatu – jeśli ustawione).

Możemy też ustawić parametr tak, by system wymagał zarówno klucza prywatnego, jak i autoryzacji za pomocą loginu i hasła:

AuthenticationMethods publickey,keyboard-interactive

AuthenticationMethods publickey,password

Na koniec jeszcze tylko restart usługi:

sudo /etc/init.d/ssh restart

PuTTY Key Generator

W przypadku, gdy do połączenia ze zdalnym hostem będziecie korzystać z programu PuTTY (konsola) lub WinSCP (transfer plików), to czeka Was jeszcze jeden krok – konwersja klucza OpenSSH do formatu obsługiwanego przez te programy.

W tym celu wystarczy uruchomić program „puttygen” (znajdziecie go w katalogu z programem PuTTY), i wybrać w nim plik do konwersji:

• Conversions -> Import Key -> wskazujemy/wybieramy klucz prywatny -> Save Private Key

Na tym etapie również możecie zdecydować, czy klucz będzie miał dodatkowe zabezpieczenie w postaci hasła, czy nie.

Tak wygenerowany (skonwertowany) klucz wystarczy teraz wskazać w ustawieniach PuTTY:

• Connection -> SSH -> Auth: Private key file for authentication

Lub WinSCP:

• Advenced -> SSH -> Authentication: Private key file

Privacy Enhanced Mail (PEM)

Możecie też trafić na aplikację, która będzie wymagać klucza prywatnego w formie pliku PEM. W takim przypadku wystarczy skorzystać z polecenia:

openssl rsa -in /ścieżka/do/pliku/id_rsa -outform pem > /ścieżka/dla/pliku/id_rsa.pem