Klucze SSH – generowanie i konfiguracja

wpis w: ARTYKUŁY | 0

#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).

Subscribe
Powiadom o
guest
0 komentarzy
Inline Feedbacks
View all comments