#1 FTP, FTPs, sFTP, SSH – Para kluczy, czy hasło?
Będąc posiadaczem VPS lub serwera dedykowanego komunikujemy się na linii klient – serwer, wykorzystując protokół SSH. Przed zaimplementowaniem rozwiązania SHH, należało pobrać plik z serwer FTP do stacji roboczej, nanieść zmiany i spowrotem wysłać na FTP. W celu bezpieczeństwa przesyłanych plików pomiędzy serwerem a klientem, przyszedł protokół FTPs, który szyfrował dane i umożliwiał autoryzację za pomocą hasła. Nie można go natomiast mylić z protokołem sFTP, działającym w zasadzie jak SSH – czyli umożliwiającym autoryzację przy wykorzystaniu par kluczy. Jak wiadomo, logując się za pomocy hasła, jesteśmy narażeni na ataki typu brute force. Korzystając z kluczy kryptograficznych również jesteśmy narażeni na ataki z tym, że ich złożoność i komplikacja jest dużo większa. Zabezpieczając serwer parą kluczy, należy zadbać o bezpieczeństwo systemu lokalnego – ponieważ dostęp do serwera nie będzie wymagał hasła (zablokujemy autoryzację, przy jego pomocy).
#2 Generowanie kluczy, konfiguracja
Duża część osób tworzy klucze z poziomu serwera – logując się przez SSH. Jest to błędem, ponieważ plik id_rsa (zawierający klucz prywatny) powinien znajdować się w systemie lokalnym klienta. Tym sposobem atakujący w celu zdobycia klucza prywatnego, musiałby uzyskać dostęp nie tylko do serwera, lecz również do systemu lokalnego. Przechowując zarówno plik id_rsa jak i id_rsa.pub (klucz publiczny), jesteśmy narażeni na przejęcie ich obydwu. W celu wygenerowania pary kluczy, użyjemy komendy:
ssh-keygen -t rsa
W sytuacji, gdy chcielibyśmy stworzyć nowy klucz, ponieważ źle skonfigurowaliśmy aktualny, należy go usunąć zarówno ze stacji klienta jak i serwera. Zrobimy to przy wykorzystaniu poniższych komend:
cd ~./ssh
ls -a (sprawdza zawartość katalogu)
sudo rm -r ssh (usuwa plik wraz z katalogami)
Przejdźmy jednak do generowania klucza od podstaw. Gdy to zrobimy, para kluczy zostanie zapisana pod ścieżką /home/użytkownik/.ssh – wejdźmy do tego katalogu i wyświetlmy zawartość kluczy, które następnie zapiszemy na nośniku zewnętrznym – w celu bezpieczeństwa. Niemniej również, przydałoby się zaszyfrować poniższe pliki.
cd ~./ssh cat .ssh/id_rsa cat .ssh/id_rsa.pub
W następnej kolejności przeniesiemy klucz publiczny z komputera lokalnego na serwer, który chcemy zabezpieczyć. Podamy nazwę użytkownika i adres serwera. Jeśli nie stworzyliśmy nowego użytkownika, zróbmy to. Nie korzystajmy z roota. W kolejnej części artykułu zablokujemy do niego dostęp.
ssh-copy-id -i ~/.ssh/id_rsa.pub użytkownik@12.123.12.123 scp /home/użytkownik/.ssh/id_rsa.pub użytkownik@12.123.12.123:/home/użytkownik/.ssh/authorized_keys
W sytuacji, gdy nie posiadamy katalogu .ssh i pliku authorized_keys po stronie serwera – stwórzmy je.
cd /home mkdir .ssh cd ~/.ssh chmod 700 .ssh (nadaliśmy wyłączny dostęp użytkownika do tego katalogu) touch .ssh/authorized_keys chmod 600 authorized_keys (analogiczne uprawnienia jak wyżej)
Porównajmy teraz id_rsa.pub znajdujący się na lokalnej stacji roboczej z id_rsa.pub serwera. Powinny być identyczne. W sytuacji, gdy posiadamy inny klucz publiczny, przepiszmy ten właściwy z komputera lokalnego. Plik zapisujemy za pomocą kombinacji klawiszy (ctrl + o), zaś zamykamy (ctrl + x).
nano .ssh/authorized_keys
Następnie w katalogu kluczy (czyli .ssh) stwórzymy plik config i skonfigurujmy połączenie. Zróbmy to z poziomu stacji roboczej.
Host (nazwa - obojętnie jaka) 12.123.12.123 HostName 12.123.12.123 Port 22222 IdentityFile ./.ssh/id_rsa User (nazwa użytkownika serwera)
Konfiguracja prawie dobiegła końca. Wyłączmy jeszcze logowanie za pomocą hasła i uniemożliwmy dostęp do roota. Zrobimy to z poziomu pliku sshd_config:
nano /etc/ssh/sshd_config
We skazanym pliku znajdźmy i zmieńmy następujące wiersze (tak jak zilustrowano to poniżej – zlikwidujmy przed znak # , jeśli taki się pojawia). Dodajmy również coś swojego:
RSAAuthentication yes PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no #PermitEmptyPasswords no #LoginGraceTime 2m PermitRootLogin no #StrictModes yes #MaxAuthTries 6 #MaxSessions 10
Całość zapiszmy za pomocą komendy:
sudo systemctl restart sshd / ssh
Wylogujmy się z serwera i spróbujmy zalogować ponownie – wspomniana czynność powinna udać się bez hasła. W celu weryfikacji tego, czy ktoś z zewnątrz nie może się dostać na nasz serwer (ponieważ wyłączyliśmy autoryzację przy pomocy hasła), dokonajmy audytu. Najlepiej jak ktoś zrobi to z zewnątrz z poziomu Linuxa lub programu PuTTy, w przypadku Windowsa. Od strony osoby, chcącej dostać się na serwer z innego komputera, powinien wyświetlić się następujący komunikat:
(1) Set up SSH public-key authentication to connect a remote system, www.kb.iu.eu, (01.07.2020).
(2) Average Linux User, How to use SSH Public Key authentication, www.youtube.com, (21.06.2019).
