Server SSH + logowanie bez hasła

Uwierzytelnianie za pośrednictwem pary kluczy RSA (publicznego i prywatnego)

 

 

 

 

 

 

Spis treści

Cel konfiguracji

Instalacja pakietu

Uruchomienie usługi

Uwierzytelnianie i nawiązanie połączenia (klient – serwer)

Generowanie certyfikatów

Instalacja certyfikatu na serwerze

Instalacja certyfikatu na komputerze klienta

Konfiguracja serwera SSH

Okno logowania z programu PuTTY

Wnioski

 

 

 

Cel konfiguracji

 

Celem konfiguracji jest uzyskanie zdalnego dostępu do serwera pracującego pod kontrolą systemu operacyjnego Linux za pośrednictwem usługi SSH. Uwierzytelnianie klienta będzie bazować na podstawie certyfikatów (pary kluczy: prywatny i publiczny).

 

System operacyjny: Linux CentOS7

Serwer: OpenSSH

Klient: Program PuTTY

 

 

Instalacja pakietu

 

W dystrybucji systemu Linux CentOS7 pakiet SSH jest instalowany domyślnie.

W przypadku instalacji ręcznej należy zainstalować pakiet openssh-server oraz openssh

 

 

Instalacja serwera SSH

# yum install openssh-server openssh

 

Wersja zainstalowanego pakietu

# rpm -qi openssh-server | grep Version

Version     : 7.4p1

 

Opcjonalnie możemy również zainstalować pakiet openssh-clients

 

 

Uruchomienie usługi

 

# systemctl start sshd

# systemctl status sshd

sshd.service - OpenSSH server daemon

   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)

   Active: active (running) since sob 2018-08-18 11:46:02 CEST; 4s ago

     Docs: man:sshd(8)

           man:sshd_config(5)

 Main PID: 23357 (sshd)

   CGroup: /system.slice/sshd.service

           └─23357 /usr/sbin/sshd -D

 

sie 18 11:46:02 centos7 systemd[1]: Starting OpenSSH server daemon...

sie 18 11:46:02 centos7 sshd[23357]: Server listening on 0.0.0.0 port 22.

sie 18 11:46:02 centos7 sshd[23357]: Server listening on :: port 22.

sie 18 11:46:02 centos7 systemd[1]: Started OpenSSH server daemon.

 

 

 

Pierwsze uruchomienie serwera SSH powoduje wygenerowanie certyfikatów w katalogu /etc/ssh natomiast konfiguracja serwera znajduje się w pliku /etc/ssh/sshd_config

Domyślnie usługa przyjmuje żądania ze wszystkich adresów IP na porcie 22.

# netstat -lpnt | grep sshd

tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      23357/sshd

tcp6       0      0 :::22                   :::*                    LISTEN      23357/sshd

 

 

Lista wygenerowanych certyfikatów podczas pierwszego uruchomienia usługi:

# ls /etc/ssh/ssh_*

/etc/ssh/ssh_host_ecdsa_key      /etc/ssh/ssh_host_ed25519_key      /etc/ssh/ssh_host_rsa_key

/etc/ssh/ssh_host_ecdsa_key.pub  /etc/ssh/ssh_host_ed25519_key.pub  /etc/ssh/ssh_host_rsa_key.pub

 

*_key (klucz prywatny)

*_key.pub (klucz publiczny)

 

Domyślnie przy połączeniu klient – serwer jest wykorzystuje algorytm RSA i klucze ssh_host_rsa_key oraz ssh_host_rsa_key.pub

 

 

Uwierzytelnianie i nawiązanie połączenia (klient – serwer)

 

Na podstawie loginu i hasła (domyślnie):

Klient:   użytkownik (login) + hasło    →    Serwer:   użytkownik (login) + hasło

 

Na podstawie certyfikatów (klucz prywatny i publiczny):

Klient:    użytkownik (login) + certyfikat (klucz prywatny)    →    Serwer:   użytkownik (login) + certyfikat (klucz publiczny)

Klucz prywatny i klucz publiczny stanowi parę, przy czym klucz prywatny jest instalowany po stronie klienta natomiast klucz publiczny po stronie serwera.

 

 

Uwaga ! W każdym przypadku „klient” musi mieć pewność, że łączy się z serwerem z którym faktycznie zamierza się połączyć.

Dlatego też przed każdym zestawieniem połączenia „klient” zawsze sprawdza tzw. odcisk palca tzw. „fingerprint” klucza wykorzystanego do szyfrowania transmisji.

O ile mówimy o kliencie należy przez to rozumieć np. program PuTTY, który sprawdza klucz i porównuje z kluczem zapisanym w swojej bazie (o ile istnieje).

Jeśli klucz publiczny jest zgodny następuje zestawienie połączenia, w innym przypadku Administrator otrzymuje ostrzeżenie „WARNING – POTENTIAL SECURITY BREACH!” o niezgodności kluczy.

Na tym etapie Administrator podejmuje decyzje o dalszym kontynuowaniu połączenia (dlatego też warto znać tzw. „fingerprint” swojego serwera).

Weryfikacja kluczy publicznych zabezpiecza przed atakiem Man-in-the-middle attack, kiedy na drodze połączenia klient – serwer może pojawić się serwer pośredniczący.

 

 

Przykład ostrzeżenia z programu PuTTY:

 

 

 
 

Generowanie certyfikatów

 

Certyfikaty do uwierzytelnienia możemy wygenerować programem ssh-keygen z pakietu openssh (aktualna wersja: openssh-7.4p1-16.el7.src.rpm)

 

parametry programu:

-t – wybór algorytmu

-b – długość klucza (zalecane do: 2048 do 4096)

-f – wskazujemy katalog/plik w którym mają zostać zapisane klucze

-C – komentarz do klucza

 

Jeżeli nie podamy parametrów zostaną przyjęte wartości domyślne takie jak:

algorytm: RSA

długość klucza: 2048

zapis certyfikatów: w katalogu .ssh (domyślnie znajduje się w domowym katalogu użytkownika)

komentarz: nazwa użytkownika oraz nazwa serwera, który wygenerował certyfikaty

nazwa certyfikatów: id_rsa (dla klucza prywatnego) oraz id_rsa.pub (dla klucza publicznego)

 

 

Instalacja certyfikatu na serwerze

 

użytkownik (login): szymon

katalog domowy: /home/szymon

 

Przykład wygenerowania pary kluczy:

[szymon@centos7 /]$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/home/szymon/.ssh/id_rsa): <ENTER>

Created directory '/home/szymon/.ssh'.

Enter passphrase (empty for no passphrase): <ENTER>

Enter same passphrase again: <ENTER>

Your identification has been saved in /home/szymon/.ssh/id_rsa.

Your public key has been saved in /home/szymon/.ssh/id_rsa.pub.

The key fingerprint is:

SHA256:cwZehEYJJHlIpArhqorhvvV8ydZ5fK5H8wu8nbdmhDk szymon@centos7

The key's randomart image is:

+---[RSA 2048]----+

|.  o++oo.o.      |

|.. .o.. +.       |

|...  . .. .      |

|o.     . o       |

|o       S o   o  |

|.        +  .E . |

|o  .  . o o .o=  |

|+.. o  = o o o++o|

|++.  oo   ..=oo=+|

+----[SHA256]-----+

 

 

Certyfikat opcjonalnie możemy zabezpieczyć również hasłem:

Enter passphrase (empty for no passphrase):<moje_haslo><ENTER>

Enter same passphrase again:<moje_haslo><ENTER>

 

 

Lista certyfikatów w katalogu domowym użytkownika:

[szymon@centos7 ~]$ ls -l ~/.ssh

razem 8

-rw-------. 1 szymon szymon 1675 08-19 10:12 id_rsa  - klucz prywatny

-rw-r--r--. 1 szymon szymon  396 08-19 10:12 id_rsa.pubklucz publiczny

 

 

Klucz publiczny id_rsa.pub należy umieścić w pliku /home/szymon/.ssh/authorized_keys

[szymon@centos7 ~]$ cd /home/szymon/.ssh

[szymon@centos7 .ssh]$ cp id_rsa.pub authorized_keys

 

Klucz prywatny id_rsa należy umieścić na komputerze z którego będziemy realizować połączenie do serwera.

Nie ma potrzeby aby klucz prywatny były przechowywany na serwerze, dlatego też możemy go usunąć z serwera.

 

 

Drugi przykład generowania pary kluczy:

[root@centos7 /]# mkdir /root/klucze

[root@centos7 /]# ssh-keygen -t rsa -b 4096 -f /root/klucze/szymon_rsa -C "serwer_centos7_1"

Generating public/private rsa key pair.

Enter passphrase (empty for no passphrase):<ENTER>

Enter same passphrase again:<ENTER>

Your identification has been saved in /root/klucze/szymon_rsa.

Your public key has been saved in /root/klucze/szymon_rsa.pub.

The key fingerprint is:

SHA256:5KNVTkXkiKtgEkbHS0TGKOZjqEWcAec8QzIm1RUSNlw serwer_centos7_1

The key's randomart image is:

+---[RSA 4096]----+

|==*@X+E.   o+    |

|+X=+*o   . +     |

|+oB. .  o + .    |

|.=.+.  o =       |

|o.o o   S .      |

|.  o . + .       |

|      o          |

|                 |

|                 |

+----[SHA256]-----+

 

 

[root@centos7 /]# ls -l /root/klucze/

razem 8

-rw-------. 1 root root 3243 08-19 10:16 szymon_rsa

-rw-r--r--. 1 root root  742 08-19 10:16 szymon_rsa.pub

 

 

 

Instalacja certyfikatu na komputerze klienta

 

Klient SSH: program PuTTY w systemie Windows

Program min. do generowania i konwersji certyfikatów: PuTTY Key Generator

 

Klucz prywatny id_rsa należy umieścić w pliku tekstowym np. id_rsa.txt

 

Następnie należy uruchomić program PuTTY Key Generator i przekonwertować certyfikat do formatu *.ppk

program: PuTTY Key Generator

Menu → Conversions → Import key → Save private key

 

 

 

 

 

Przyjmując, że klucz prywatny został zapisany np. jako  id_rsa.ppk możemy go teraz zaimportować do programu PuTTY

program: PuTTY

PuTTY Configuration → Connection → SSH → Auth → Private key file for authentication: i wskazać plik id_rsa.ppk

 

 

 
 

 

 

Link do oprogramowania puttygen.exe oraz putty.exe

https://www.chiark.greenend.org.uk/~sgtatham/putty/latest.html

 

 

 

Konfiguracja serwera SSH

 

Sposób pierwszy:

 

W pliku konfiguracyjnym serwera SSH  /etc/ssh/sshd_config  należy uaktywnić dyrektywę:

PubkeyAuthentication yes

 

Nie ma potrzeby aby w dalszym ciągu można było zalogować się na serwer z wykorzystaniem loginu i hasła. Dlatego też należy uaktywnić dyrektywę:

PasswordAuthentication no

 

 

Sposób drugi:

 

W pliku konfiguracyjnym serwera SSH  /etc/ssh/sshd_config  należy ustawić dyrektywę:

AuthenticationMethods publickey

 

przykład:

# echo "AuthenticationMethods publickey" >> /etc/ssh/sshd_config

 

restart usługi:

# systemctl restart sshd

 

 

Okno logowania z programu PuTTY

 

Przykładowe okno logowania klienta PuTTY do serwera SSH (autoryzacja na podstawie certyfikatu)

 

 
 

 

 

Wnioski

 

Zalety

1. Uwierzytelnianie i logowanie się do serwera za pośrednictwem certyfikatów jest o wiele bezpieczniejsze w porównaniu z tradycyjnym loginem i hasłem.

2. Na serwerze może być umieszczonych wiele certyfikatów publicznych (na każdym koncie z osobna) i każdy z Administratorów może posiadać swój własny klucz prywatny.

3. Na podstawie pary certyfikatów mogą zostać przydzielone określone „role” i uprawnienia w systemie.

4. Konto uprzywilejowane „root” o ile jest taka potrzeba może mieć swój własny klucz publiczny do uwierzytelnienia.

5. Klucz prywatny można zabezpieczyć hasłem, dlatego też użytkownik podczas logowania na serwer zostanie poproszony dodatkowo o podanie hasła.

 

Wada, a może jednak zaleta biorąc pod uwagę bezpieczeństwo...

1. Klucz prywatny musimy zapisać gdzieś fizycznie na nośniku zewnętrznym lub dysku komputera (np. koncie użytkownika w systemie Windows). Stąd możliwość logowania się na serwer jest ściśle uzależniona od fizycznego posiadania takiego klucza.

 

 

 

Autor: Szymon Urbańczyk, 19.08.2018 r.