W związku z upowszechnieniem się informatyzacji, jednymi z najczęściej powtarzanych haseł na przestrzeni ostatnich lat są np. "jak to zautomatyzować?", "o ile przyspieszy to moją pracę?" lub "czy może to integrować się z moimi urządzeniami?". Jednak coraz częściej w tym gronie pojawiają się pytania w rodzaju "jak to zabezpieczyć?" lub "czy nikt nie wykradnie mi przez to danych?". Nie da się ukryć, że wygoda powstała przez wprowadzenie rozwiązań IT oraz umieszczanie coraz większej ilości danych w chmurze ma konsekwencje w postaci innego podejścia do ochrony naszych informacji.

Wiemy, że używanie haseł nie jest jedynym sposobem na zabezpieczenie przed niepowołanym dostępem. Mało tego - nie jest to taka dobra blokada, jakby się mogło wydawać. W bardziej wrażliwych przypadkach bardzo przydatne lub wręcz konieczne może być wykorzystanie kryptografii i możliwości, które ona ze sobą niesie. Najbardziej znaną z nich jest wykorzystanie kluczy, zwanymi potocznie kluczami SSH. Wielu osobom ten skrót może wydać się znajomy i słusznie - znamy w końcu takie pojęcie jak "logowanie przez protokół SSH" i klucze są tutaj... kluczowe.

Opowiedzmy sobie zatem, czym one są.

Po co tworzone i używane są klucze SSH?

Klucze SSH (ang. Secure Shell) są plikami, które zawierają ciągi znaków umożliwiające zidentyfikowanie nas jako użytkowników. Co za tym idzie - logowanie się klucz SSH to alternatywa forma udowodnienia, że my to my, dzięki czemu nie będziemy musieli podawać hasła (chyba że sam klucz będzie takie posiadał, co jest możliwe - to tak zwany passphrase). Właśnie ta miła właściwość jest jedną z zalet stosowania tego sposobu uwierzytelniania - nie ma potrzeby zapamiętywania i wpisywania kodu, a także łatwiejsza staje się integracja z różnymi narzędziami. Jednak jeszcze większą zaletą jest zwiększone bezpieczeństwo.

Nie bez powodu napisałem "pliki", a nie "plik". Klucz SSH składa się z dwóch ciągów znaków - klucza prywatnego oraz klucza publicznego. Jak sama nazwa wskazuje, ten pierwszy powinien być zawsze wyłącznie w naszym posiadaniu, natomiast drugi możemy (a nawet musimy) wysłać na serwer, do którego chcemy się logować. Clou całego rozwiązania polega na tym, że klucze pasują do siebie i umożliwiają zaszyfrowanie oraz odszyfrowanie danych - mówią one jednym językiem, które znają tylko one. Jeden służy do zakodowania informacji, a drugi do odkodowania i dzięki temu bezpieczne staje się przesłanie wartości przez sieć.

Klucze SSH są podstawą do działania innych metod uwierzytelniania, z których bardzo znane są choćby certyfikaty SSL. Samo zastosowanie klucza najlepiej widać na przykładzie dostępu do serwerów, jednak programiści doskonale wiedzą, że także przy korzystaniu z repozytoriów ta metoda uwierzytelniania jest w cenie, głównie ze względu na wygodę. Wówczas należy pamiętać, aby w takich serwisach jak GitHub, Bitbucket czy Gogs umieszczać wyłącznie klucz publiczny.

Jak wygląda taki klucz SSH?

Tak, jak wspomniałem, klucze SSH to dwa pliki, które posiadają najczęściej domyślne nazwy:

• klucz prywatny - zazwyczaj jest to plik id_rsa, który zachowujemy na swoim dysku i nigdzie go nie przesyłamy.
• klucz publiczny - zazwyczaj jest to plik id_rsa.pub, który możemy przesłać tam, gdzie chcemy się uwierzytelniać tą metodą.

Najprostsza para plików może wyglądać następująco - najpierw przykładowy klucz prywatny (dokonałem paru zmian w środku w celu bezpieczeństwa):

-----BEGIN OPENSSH PRIVATE KEY-----
b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABlwAAAAdzc2gtcn
NhAAAAAwEAAQAAAYEAzbQVgfXe985M1/4hOgddtCI+IWNDcyhDGjloBLxYh+WaUcbE8T0d
nwOhTjasFHq0HLUVYmjjZe3BVq1L6yOnX1dG/O2dH7sxBWMvZQci0jZfeneWqZuL9SmgJM
RXNADmSEwsUP0ouaI/FHMkYNnLsyeRhr4mFk60B8YIQThkkiJbzgbDhF9FOXOsjkV+N60m
AChUiNrD5VeUIIGnDCC5Uz85gMIyVISa8i/1dH79Ihkpagt1gGESeug+eBg/C6sRj/jA5E
CyFY51zyYXf79XL+V+CQLJjLT7qrwWzoP61XS39eN0Hap2yDdiXe+wd9mkiPiPjzA9FYm3
hBwSpcBuRyrvbvJCamiK0pqdMTv5jRt5j6cnhTJLjwptxol3+p73tQZe4iGDeepJpZ9nl3
x8RfDhI7AJm+Dy7yFQTCw0H9B3X4cNvky9Ttl2ZotpupaaVq/E/RGtCtldhisHX31YTxv0
MEobNR1ys5WZD/CxnWFE7V8+9h3b2CijNTIus3AVAAAFkGaqRltmqkZbAAAAB3NzaC1yc2
EAAAGBAM20FYH13vfOTNf+IToHXbQiPiFjQ3MoQxo5aAS8WIflmlHGxPE9HZ8DoU42rBR6
tBy1FWJo42XtwVatS+sjp19XRvztnR+7MQVjL2UHItI2X3p3lqmbi/UpoCTEVzQA5khMLF
D9KLmiPxRzJGDZy7MnkYa+JhZOtAfGCEE4ZJIiW84Gw4RfRTlzrI5FfjetJgAoVIjaw+VX
lCCBpwwguVM/OYDCMlSEmvIv9XR+/SIZKWoLdYBhEnroPngYPwurEY/4wORAshWOdc8mF3
+/Vy/lfgkCyYy0+6q8Fs6D+tH0t/XjdB2qdsg3Yl3vsHfZpIj4j48wPRWJt4QcEqXAbkcq
727yQmpoitKanTE7+Y0beY+nJ4UyS48KbcaJd/qe97UGXuIhg3nqSaWfZ5d8fEXw4SOwCZ
vg8u8hUEwsNB/Qd1+HDb5MvU7ZdmaLabqWmlavxP0RrQrZXYYrB199WE8b9DBKGzUdcrOV
mQ/wsZ1hRO1fPvYd29goozUyLrNwFQAAAAMBAAEAAAGAIZWhXVKTUMox6aHoMt05A0wD8N
eQD6EnM4Tj4sINgkKOa4OUa/6ac3fYQjjS55URCw7VqveNCPtEca5hksaDcSGCyZDR8nhR
jJuhBVGg8clG1WvpAVAQDbr6Foan5imvb2ZgZeivWX+P5PrXmah1hY6UR/eLqGC5K/u9JU
jbwrAxZPXdviL/3l1wctoNvXFbnvL2ulFdYnhmCtigOW6uU1UjQk5ygTIVSi1iWd7R3VtW
U6YDTS6MId0BNgJfaLxJGsJWdmL7rJCvMJeMKYOOKUkjXfpMQ19NuQgIjh5sJvlPNT9AGA
ZsW0Jsb74XNgvorhmBozDWKcbQaZ32o/iHWLgtyzM/GKzUrwmWWATae4tHoaLkzEWSEP5w
8yesg5mfHC+5CzcwQiD8AWQ+cG5urIofXwIzKFi+CnE8QGrJ08JmL91jCbNESSjCbiYhp8
an6eeTaVZCGzPRPFMWZKGtqEbw2xutWi8KS63aEjlRCxuSL4te7B2t0IvqRQF2TPmBAAAA
wAbWkL/RACVFAZ9IvSvuzsx5DbDq3tknjh7e7Vt0vPVFeKDNroLA2nc/WTMNYyMqF/9qub
pdit5dQgs9s9v0SwJGXd3/PgYu2dIi15ETjc/JIwLUfLPeTAm6Ovkh7QY/S66fSjld1j4F
+HzNUO+LSO3jyflC9NT7uh9oyEqQ4hPusuKlAdccydA04QK694eLLhLHvn7VMjhCBq8dUc
76+I1mIojZ8tFhdZT4VqSo1lggHVlc8AnpVV1rHAR6wAXmUQAAAMEA7/rsVfj8ti/u650u
b5AdgFI2pX6XHD5JSc9NZ7AjmPRkWD770nn6ZLWVqWMWv7pfbb1KtwTY4QtrAoVIHNLhVZ
8sfNrJwlDXIjoW+wOM9SA13/4GUhx/n2dVihjP41mqmEt96MhVfN7eHQzioKOYHz2qkwDb
9IddCmli4HpiQ4dPakElapRANG+2QoBKGeJO2Ds3GRu34mrF8cF9HEfbRwX1fuHGBJrqTP
I8xdPxL0Xh8P/hBdWhuNvhUwvb/1v9AAAAwQDbb2XofdNu9b2A5bjmdzNA9jfPhd20OvQF
fRDWufJ6SgMR9LscPFf7aeG1KJ42wWr0tRo9piSxXBTMRkzt0QxKp6VjkW9gIJHQYe0+R0
svPhVYUizMoOPMyjCaBUm/RTyDQO0nR3zQg5HBy6gqgUAk9Vg5jxES65FqPRQj2J7i+rr/
C3Xj+4cLvu8n9Cj192OAYatwsmf20BnTR7FQs3jGIjeuhhWx+97A+e2PzZ/jOu/g9v5w/E
o+Evt5LBTrA/kAAAAUdXNlckBERWNLVE9QLUoxU0FVUTcBAgMEBQYH
-----END OPENSSH PRIVATE KEY-----

Tymczasem klucz publiczny jest trochę krótszy i zawiera także komentarz, jak np. nazwę komputera, na którym został wygenerowany:

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDNtBWB9d73zkzX/iE6B120Ij4hY0NzKEMaOWgEvFiH5ZpRxsTxPR2fA6FONqwUerQctRViaONl7cFWrUvrI6dfV0b87Z0fuzEFYy9lByLSNl96d5apm4v1KaAkxFc0AOZITCxQ/Si5oj8UcyRg2cuzJ5GGviYWTrQHxghBOGSSIlvOBsOEX0U5c6yORX43rSYAKFSI2sPlV5YggacMILlTPzmAwjJUhJryL/V0fv0iGSlqC3WAJRJ66D54GD8LqxGP+MDkQLIVjnXPJhd/v1cv5X4JAsmMtPuqvBbOg/rVdLf143QdqnbIN2Jd77B32aSI+I+PND0VibeEHBKlwG5HKu9u8kJqaIrSmp0xO/mNG3mPpyeFMkuPCm3GiXf6nve1Bl7iIYN56kmln2eXfHxF8OEjsAmb4PLvIVBMLDQf0Hdfhw2+TL1O2XZmi2m6lppWr8T9Ea0K2V2GKwdffVhPG/QwShs1HXKzlZkP8LGdYUTtXz72HdvYKKM1Mi6zcBU= user@DESKTOP-ABC1234

To domyślna wersja - nic nie stoi na przeszkodzie, aby wygenerować dłuższy klucz o większej liczbie bitów, co oznacza większe bezpieczeństwo, ale też niższą wydajność. Klucze gromadzone są zazwyczaj w katalogu domowym użytkownika, w folderze .ssh. W przypadku Linuxa będzie to ~/.ssh (lub, używając pełnej ścieżki, /home/nazwauzytkownika/.ssh), natomiast w Windowsie domyślna lokalizacja to C:/Users/nazwauzytkownika/.ssh).

Powyżej przedstawiony ciąg znaków został zakodowany za pomocą algorytmu RSA (od nazwisk twórców - Rivesta-Shamira-Adlemana), który pod spodem opiera się na operowaniu bardzo dużymi liczbami pierwszymi. Jest to domyślna metoda szyfrowania dostępna dla SSH, choć istnieją też inne, rzadziej używane, jak np. ECDSA.

Jak wygenerować klucz SSH?

Klucz najczęściej generuje się za pomocą polecenia ssh-keygen, które zaraz omówimy, natomiast nie oznacza to, że jesteśmy na nie skazani i dodatkowo musimy to robić na Linuxie. Jeśli mamy zainstalowanego Gita na Windowsie i wraz z nim program Git GUI, to istnieje w nim opcja wygenerowania pary kluczy za pomocą jednego kliknięcia. Jeszcze bardziej popularny PuTTy ma taką możliwość. Samo polecenie jest dostępne także w Git Bashu czy PowerShellu po zainstalowaniu odpowiedniego rozszerzenia. Skupmy się jednak na podstawowej komendzie.

Najprostsze wywołanie polecenia ssh-keygen spowoduje:

• sprawdzenie, czy w domyślnym katalogu istnieją już klucze - jeśli tak, to program zapyta, czy je zamienić (należy przy tym bardzo uważać - poprzednie klucze bezpowrotnie stracimy),
• wyświetlenie prośby o podanie i powtórzenie passphrase'a, dodatkowo zabezpieczający klucz (bardzo często zostawia się go pustego),
• pokazanie informacji o powodzeniu operacji i tzw. odcisku palca (ang. fingerprint) klucza, służącego do weryfikacji, czy łączymy się z właściwą maszyną.

Jest to zatem całkiem proste, ale czasami chcemy coś zmienić - umieścić klucz w innym pliku, zastosować mocniejsze szyfrowanie itd. Na szczęście, polecenie udostępnia parę przełączników, z których można wyróżnić kilka szczególnie użytecznych:

• -t - wybór metody szyfrowania (domyślnie RSA)
• -b - liczba bitów klucza (czyli jego długość)
• -f - lokalizacja i nazwa pliku, do którego zostaną zapisane klucze (domyślnie ~/.ssh/id_rsa)

Można zatem wygenerować klucz w następujący sposób, używając innych parametrów niż domyślne:

ssh-keygen -t ecdsa -b 384 -f ./my_key

Czy klucz SSH jest bezpieczny?

Podobnie, jak większość uznanych metod związanych z ochroną danych i dostępu do zasobów, klucze SSH nie są bezpieczne w 100%. Są jednak na tyle dobre (powiedzmy w 99,8%), że jeśli mamy taką możliwość, powinniśmy używać ich zamiast podawania zwykłego hasła. Gdzie zatem leży sekret?

W stopniu złożoności samego klucza. Pamiętamy, że klucz publiczny jest jawny i teoretycznie może zostać "wykradziony". Jednak do wykorzystania go w nieuprawniony sposób konieczna jest jeszcze zawartość klucza prywatnego, a ten jest bardzo trudno "odgadnąć". To trochę tak, gdybyśmy zgubili zamek do skrzyni, ale nie sam klucz, który go otwiera. Tym niemniej, przy ogromnej mocy obliczeniowej lub gigantycznym szczęściu, złamanie klucza jest możliwe i dlatego nie można powiedzieć, że klucze SSH są nie do podrobienia. Dają jednak na tyle dużą pewność, że musielibyśmy używać naprawdę słabych i krótkich ciągów znaków, aby realnie bać się o swoje bezpieczeństwo.

Zwykle do normalnego korzystania z Internetu nie musimy wiedzieć, w jaki sposób powstają te klucze i do czego służą. To jednak nie oznacza, że nie warto znać tego zagadnienia, a w przypadku programistów jest ono wręcz niezbędne, aby czuć się swobodnie we współpracy z różnymi usługami i administratorami. W końcu - im większą wiedzę mamy, tym lepiej rozumiemy, co dzieje się dookoła, a jeśli dodatkowo dotyczy to naszego bezpieczeństwa, to wybór staje się jeszcze prostszy.

Pozdrawiam i dziękuję - Jakub Rojek.