Narzędzia użytkownika

Narzędzia witryny


materialy:bezpieczenstwo:ssh

SSH

Materiał poniższy obejmuje zakres tematu 110.3 Securing data with encryption dla LPI, egzamin 102, certyfikat LPIC-1. Jeśli chcesz sprawdzić praktycznie zakres poniższego materiału, możesz również zrealizować zadania.

Dla pełnego zakresu tematu 110.3 Securing data with encryption zapoznaj się również z GPG.

Secure Shell i OpenSSH - wstęp

SSH (tłum. bezpieczny shell) został zaprojektowany głównie w celu bezpiecznego uruchamiania powłoki tekstowej na zdalnym serwerze i kopiowania danych między systemami . Jest alternatywą dla niezabezpieczonych usług telnet i ftp (sftp korzysta z ssh). Dzięki SSH można również zestawić szyfrowane połączenie, tzw. tunel, między jednym a drugim urządzeniem. Można więc szyfrować transmisję danych między dowolnymi usługami, nawet takimi, które nie mają zaimplementowanej funkcjonalności szyfrowania i uwierzytelniania. SSH jest uznane za podstawowe narzędzie pracy administratora systemów Linux i podobnych.

SSL (ang. Secure Sockets Layer), mimo iż stosuje identyczne algorytmy szyfrowania, jest znany głównie w szyfrowaniu transmisji stron WWW i poczty. Protokół HTTPS (ang. Hyper Text Transfer Protcol Secure) korzysta z SSL, aby szyfrować połączenie HTTP oraz uwierzytelniać serwery WWW.

Działanie protokołów SSH oraz SSL oparte jest na wymianie kluczy publicznych, sesyjnych, potwierdzeniu tożsamości (uwierzytelnianie) oraz wyborze obsługiwanej wspólnej metody (algorytmu) szyfrowania. W praktycznie każdej dystrybucji serwerowej podczas instalacji systemu instalowany jest pakiet OpenSSH implementujący protokół SSH. Zawiera on wśród swoich narzędzi najważniejszy demon tej usługi – sshd. Demon odpowiedzialny jest za udostępnianie usługi SSH zdalnym klientom. Podczas instalacji generowane są również klucze publiczny i prywatny serwera. Administrator otrzymuje narzędzie już skonfigurowane i gotowe do działania. Mimo tego, dobrze jest przejrzeć konfigurację i dopasować ją do swoich potrzeb.

Konfiguracja serwera

Wszystkie ustawienia konfiguracyjne usługi ssh znajdują się w plikach katalogu /etc/ssh/. Te, które dotyczą demona sshd, nasłuchującego domyślnie na porcie 22 można znaleźć w pliku /etc/ssh/sshd_config. Opis parametrów znajduje się w dokumentacji:

man sshd_config

W tekstowym pliku konfiguracyjnym parametrom konfiguracyjnym przypisywane są wartości w formie:

nazwa-parametru lista-wartości

Wartości w liście oddzielone są białym znakiem lub przecinkiem. Komentarze są poprzedzone znakiem hash (#) na początku linii. Po zainstalowaniu aplikacji w pliku /etc/ssh/sshd_config, w komentarzach znajdują się domyślne wartości poszczególnych parametrów. Podstawowe z nich to:

  • Port - numer portu na którym ma nasłuchiwać usługa (domyślnie 22);
  • ListenAddress – na jakim adresie IP usługa SSH ma oczekiwać połączeń (otworzyć port), wartość 0.0.0.0 oznacza nasłuchiwanie na wszystkich skonfigurowanych IP dla komputera;
  • Protocol – wersję wykorzystywanego protokołu (pierwsza, druga lub obydwa);
  • HostKey – ścieżki do plików zawierających klucze prywatne hosta;
  • SyslogFacility, LogLevel – informacje o sposobie logowania zdarzeń.

Ustawienia domyślne demona sshd (zależy od dystrybucji) są teoretycznie wystarczające dla zapewnienia podstawowego bezpieczeństwa. Jednak niewielkim kosztem możemy ryzyko problemów zminimalizować, dlatego warto zmienić wartości przynajmniej dwóch parametrów albo zweryfikować, czy w używanej dystrybucji są one ustawione na „bezpieczniejszą” wartość. Konfiguracja czasami zezwala na połączenia w dwóch możliwych wersjach protokołu: wersji starszej - pierwszej i nowszej – drugiej. Wersja pierwsza nie okazała się w pełni bezpieczna ze względu na możliwość przechwycenia i odszyfrowania sesji. Programiści OpenSSH udostępniają możliwość korzystania z tej wersji dla kompatybilności wstecznej z pewnymi klientami ssh, których nie da się podmienić i nie mają obsługi nowszej wersji. Dobrą praktyką, przy nowo instalowanych systemach, jest zablokowanie protokołu starszego i zezwolenie tylko na komunikację w jego drugiej wersji, jeśli środowisko na to pozwala. Parametrem, który określa, w jakiej wersji protokołu mogą łączyć się klienci z systemem jest Protocol.

Bardzo często domyślnym ustawieniem jest również możliwość bezpośredniego, zdalnego logowania się na konto root. Również i ta praktyka nie jest zalecana, gdyż zezwala na próby logowania na konto roota. W niektórych dystrybucjach serwis sshd jest prekonfigurowany tak, aby logowanie na roota nie było możliwe. Parametr, który pozwoli zmienić domyślne zachowanie to PermitRootLogin, ustawiony na wartość no. Jak zatem zalogować się na konto roota zdalnie przy takim ustawieniu? Administracja serwerem wymaga przecież często dostępu do najważniejszego konta w systemie. Rozwiązaniem jest utworzenie dodatkowego konta zwykłego użytkownika, zalogowanie się na to konto, a następnie przelogowanie na konto roota

itmzsrv$ su -

lub korzystanie z sudo Próba zalogowania do systemu wymaga nie tylko hasła, ale również loginu. Stosując powyższe rozwiązanie wzmacniamy bezpieczeństwo systemu, gdyż „włamywacz” musi również posiąść nazwę konta na które potencjalnie może się zalogować do systemu.

Uruchamianie demona

Po zainstalowaniu paczki OpenSSH można zarządzać tą usługą tak jak pozostałymi. W CentOS usługa ma nazwę sshd, w Debian ssh. Uruchamianie demona:

centos-itmzsrv# service sshd start

Zarządzenie usługą i decydowanie czy ma być ona uruchamiana przy starcie czy nie należy do zakresu zarządzania serwisami.

Klucze prywatne i publiczne

Klucze publiczne i prywatne serwera, na systemie z serwerem sshd przechowywane są w plikach /etc/ssh/*key*. Aby wygenerować nowe klucze można posłużyć się narzędziem dostarczanym razem z pakietem OpenSSH o nazwie ssh-keygen. Lista wszystkich narzędzi wraz z dokumentacją znajduje się na stronie projektu

Generowanie nowych kluczy:

itmzsrv# /usr/bin/ssh-keygen -t rsa1 -N "" -f /etc/ssh/ssh_host_key 
itmzsrv# /usr/bin/ssh-keygen -t dsa -N "" -f /etc/ssh/ssh_host_dsa_key 
itmzsrv# /usr/bin/ssh-keygen -t rsa -N "" -f /etc/ssh/ssh_host_rsa_key 

Dwa ostatnie klucze wykorzystywane są do komunikacji w wersji drugiej protokołu. Powyższych poleceń nie trzeba wywoływać ręcznie, gdyż w praktycznie każdej dystrybucjiklucze są automatycznie generowane przy pierwszym uruchomieniu serwisu, który nie znajdzie powyższych plików.

Klient SSH

Aby zalogować się na zdalny system przy pomocy protokołu SSH:

itmzcli$ ssh uzytkownik@adres-serwera

Jeśli użytkownik loguje się na zdalny system po raz pierwszy, prosi serwer o przesłanie mu jego klucza publicznego, który następnie zostaje zapisany w katalogu domowym klienta, w odpowiednim pliku ~/.ssh/known_hosts. Dowolna informacja zaszyfrowana kluczem publicznym serwera będzie możliwa do odszyfrowania tylko przy pomocy klucza prywatnego, którego jedynym posiadaczem jest serwer. Przy każdym następnym logowaniu, klient może mieć więc pewność, iż komunikuje się cały czas z tym samym serwerem. Jeśli przy połączeniu serwer ssh informuje, iż serwer zmienił swój klucz publiczny lub ktoś próbuje się pod niego podszyć, należy taką sesję traktować ze szczególną ostrożnością i nie łączyć się, jeśli nie mamy pewności, iż rzeczywiście serwer zmienił klucz publiczny.

Wywoływane zdalne komend

Obok pracy zdalnej, klient ssh posiada funkcjonalność wykonywania komend na zdalnym serwerze tak, aby wynik pojawił się w konsoli lokalnego komputera.

itmzcli$ ssh uzytkownik@adres-serwera komenda

Poniższe polecenie wywoła komendę uptime na zdalnym serwerze, a wynik zapisze w pliku o nazwie czas-serwera utworzonym lokalnie w systemie itmzcli.

itmzcli$ ssh kasia@moj.serwer.pocztowy.pl uptime > czas-serwera

Dla systemu MS Windows dostępny jest przyjazny, w pełni darmowy klient SSH o nazwie Putty

Bezpieczne kopiowanie plików

Oprócz zdalnego zarządzania poprzez powłokę, możliwe jest kopiowanie plików z systemu zdalnego na lokalny za pomocą polecenia scp (ang. Secure CoPy), dostarczanego również z pakietem OpenSSH. Składnia polecenia, przy kopiowaniu pliku na zdalny serwer:

itmzcli$ scp /sciezka/do/pliku [uzytkownik@]serwer:/sciezka/do/pliku

Składnia przy kopiowaniu pliku z serwera zdalnego na system lokalny:

itmzcli$ scp [uzytkownik@]serwer:/sciezka/do/pliku /sciezka/do/pliku

Jeśli użytkownik chciałby utworzyć lokalnie, w swoim katalogu domowym kopię domyślnych ustawień pliku dla oprogramowania grub znajdującego się na zdalnym komputerze o pełnej nazwie domenowej host.serwerjasia.pl to powinien wykonać komendę:

itmzcli$ scp jas@host.serwerjasia.pl:/etc/default/grub ~/default-grub.kopia-z-serwerjasia.pl

Program zapyta o hasło dostępu do konta jas. Jeśli użytkownik ten będzie miał prawo odczytu do pliku /etc/default/grub na serwerze zdalnym to polecenie wykona się bez przeszkód.

Jeśli administrator chciałby utworzyć kopię lokalnego pliku na zdalnym serwerze, w katalogu domowym użytkownika jas, może użyć następującego polecenia:

itmzsrv# scp /etc/proftpd.conf jas@serwerjasia.pl:~/proftpd.conf-kopia

W systemie MS Windows, jako klienta SCP, można użyć darmowego narzędzia – WinSCP. Dzięki temu narzędziu można bezpiecznie kopiować pliki między systemami MS Windows i Linux.

Bezpieczna komunikacja – tunelowanie wirtualnego pulpitu

SSH pozwala na tworzenie bezpiecznego tunelu komunikacyjnego. Jego budowa polega on na tym, iż po zestawieniu połączenia między klientem a serwerem przy pomocy ssh, otwarty zostaje lokalny port komunikacyjny (TCP) na systemie klienta, dostępny tylko dla niego. Port ten jest powiązany z wybranym portem na systemie serwera. Informacje przesyłane na port lokalny u klienta będą szyfrowane, przesyłane kanałem SSH do serwera, u niego rozszyfrowywane i przesyłane na określony port tego serwera.

Przykładem może być zbudowanie tunelu dla nieszyfrowanego protokołu. VNC (ang. Virtual Network Computing) służy również zdalnej administracji ale w trybie graficznym (ekwiwalent „remote desktop” dla systemu MS Windows). Niestety, przesyłane tym protokołem informacje nie są szyfrowane.

Załóżmy, iż na zdalnym serwerze dystrybucji Debian (w przykładach poniżej oznaczany jako @zdalny) administrator zainstalował oprogramowanie serwera VNC dostępne z oprogramowaniem tightvnc, którego paczka ma nazwę tightvncserver.

Michał, który ma konto na zdalnym serwerze, loguje się ze swojego, lokalnego komputera (oznaczanego poniżej jako @lokalny) na zdalny system, uruchamia serwis VNC, a jako numer ekranu (display number) podaje 77.

michal@lokalny$ ssh michal@zdalny
michal@zdalny's password:
MOTD: Welcome to zdalny
michal@zdalny$ vncserver :77
...uruchamienie serwera vnc...

Na zdalnym serwerze otwiera się, między innymi, port komunikacyjny dla VNC o numerze 5977 (5900 + display number).

michal@zdalny$ netstat -ltnp | grep 77
tcp  0  0 0.0.0.0:5977  0.0.0.0:*        LISTEN      3847/Xtightvnc
tcp  0  0 0.0.0.0:6077  0.0.0.0:*        LISTEN      3847/Xtightvnc

Tak przygotowany system gotowy jest do komunikacji z klientem VNC uruchomionym gdziekolwiek w sieci. Michał może na swoim, lokalnym komputerze uruchomić klienta VNC w trybie graficznym, aby na ekranie pojawił się wirtualny pulpit:

michal@zdalny$ exit
michal@lokalny$ vncviewer zdalny:77
...otwiera się okno wirtualnego pulpitu...

Takie połączenie nie jest bezpieczne, gdyż informacje (również hasło, które Michał musi podać podczas logowania do sesji VNC) są przesyłane w sposób nieszyfrowany. Osoby niepowołane, mogłyby przechwycić komunikację Michała z serwerem i ją podejrzeć. Komunikacja z portem zdalnym 5977 może być jednak przeprowadzana w sposób bezpieczny dzięki tunelowaniu.

Na jednej z własnych konsol Michał musi zalogować się na swoje zdalne konto otwierając jednocześnie szyfrowany tunel między swoim portem, załóżmy 5999 a portem 5977 otwartym na zdalnym komputerze:

michal@lokalny$ ssh -L 5999:localhost:5977 michal@zdalny
michal@zdalny's password:
MOTD: Welcome to zdalny
michal@zdalny$

Nie wylogowując się z systemu zdalnego, Michał w drugiej konsoli może połączyć się klientem VNC ze swoim lokalnym portem 5999. Numer ekranu będzie równy 99 (5999-5900).

michal@lokalny$ netstat -ltnp | grep 5999
tcp  0  0 127.0.0.1:5999   0.0.0.0:*        LISTEN      650/ssh
michal@lokalny$ vncviewer localhost:99
...otwiera sie okno wirtualnego pulpitu...

Takie połączenie jest w pełni bezpieczne i całkowicie szyfrowane.

Połączenia tunelowane wspiera również oprogramowanie Putty – można zatem z systemu MS Windows bezpiecznie administrować systemem Linux w trybie graficznym. Należy jedynie doinstalować klienta VNC, dostarczanego na przykład w darmowym oprogramowaniu tightvnc dla MS Windows.

Bezpieczna komunikacja – tunelowanie sesji X11

Za pomocą SSH można w wygodny sposób i przede wszystkim bezpieczny uruchamiać zdalnie programy w trybie graficznym. X Windows Systems (X11) pracuje w trybie klient-serwer, więc z definicji można uruchamiać programy tak, aby graficzny interfejs wyświetlany był na jednym komputerze a sam program działał na innym systemie. Dzięki SSH komunikacja klient-serwer jest w pełni bezpieczna.

Aby zapewnić sobie tą możliwość po stronie serwera ssh w pliku konfiguracyjnym /etc/ssh/sshd_config należy upewnić się, że poniższy parametr przyjmuje wartość yes:

X11Forwarding yes

Po ewentualnej korekcie i zrestartowaniu serwisu ssh można zalogować się do serwera tak jak przy tradycyjnym logowaniu od strony klienta, ale z parametrem -X

michal@lokalny$ ssh -X michal@zdalny
michal@zdalny's password:
MOTD: Welcome to zdalny
michal@zdalny$

Po zalogowaniu można uruchamiać programy graficzne, których interfejs pokaże się na systemie lokalny:

michal@zdalny$ firefox &

Logowanie do systemu zdalnego bez hasła

Za pomocą SSH oraz przy wykorzystaniu zestawu kluczy prywatny-publiczny można logować się na inne konta bez podawania hasła. Uwierzytelnianie takie oparte jest na posiadaniu klucza prywatnego, które daje możliwość logowania się na inne konta. Najpierw takie docelowe konto trzeba w odpowiedni sposób „powiadomić”, że użytkownik o określonym publicznym kluczu jest zaufany i można go uwierzytelnić za pomocą jego klucza a nie hasła.

Załóżmy, że w dwóch systemach centosm05 oraz debiansrv05 istnieją konta o nazwach u1 (konta nie muszą mieć takich samych nazw). Zadanie jakie stawiamy przed sobą to logowanie bez hasła użytkownika u1@centosm05 na konto u1@debiansrv05.

Na początek należy wykonać próbę zdalnego zalogowania z jednego systemu do drugiego:

[u1@centosm05 ~]$ ssh u1@debiansrv05
The authenticity of host 'debiansrv05 (192.168.122.115)' can't be established.
RSA key fingerprint is b9:94:71:4b:02:25:e6:36:b4:2a:6a:8e:a4:38:96:12.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'debiansrv05,192.168.122.115' (RSA) to the list of known hosts.
u1@debiansrv05's password: 
MOTD: Welcome to debiansrv05
u1@debiansrv05:~$ 

Jeśli to pierwsze logowanie to po wykonaniu powyżej komendy na serwerze centosm05 do pliku ~/.ssh/known_hosts został dopisany klucz systemu debiansrv05. Dzięki temu, próba podszycia się pod debiansrv05 będzie rozpoznana przez klienta ssh, który z centosm05 będzie próbował się zalogować do debiansrv05.

Kolejnym krokiem, wykonywanym na serwerze centosm05 w kontekście użytkownika u1, jest wygenerowanie zestawu kluczy prywatnego i publicznego, którymi będzie posługiwał się użytkownik:

[u1@centosm05 ~]$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/home/u1/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/u1/.ssh/id_rsa.
Your public key has been saved in /home/u1/.ssh/id_rsa.pub.
The key fingerprint is:
f5:83:44:98:93:27:5b:04:9b:e2:c4:57:a3:8e:e0:43 u1@centosm05
The key's randomart image is:
+--[ RSA 2048]----+
|        .*=      |
|     .  **o.     |
|    E + =*o      |
|   o + =.o o     |
|    o o S . o    |
|     .       .   |
|                 |
|                 |
|                 |
+-----------------+

Pytanie o hasło dotyczy klucza. Hasło może pozostać puste, wtedy korzystanie z klucza nie wymaga jego podawania a nasze bezpieczeństwo oparte jest jedynie na bezpieczeństwie przechowywania klucza prywatnego.

Powyższa komenda powinna utworzyć zestaw kluczy prywatny i publiczny w katalogu ~/.ssh/:

[u1@centosm05 ~]$ ls -l .ssh
razem 12
-rw-------. 1 u1 u1 1675 06-09 03:54 id_rsa
-rw-r--r--. 1 u1 u1  394 06-09 03:54 id_rsa.pub
-rw-r--r--. 1 u1 u1  409 06-09 03:47 known_hosts

Klucze:

  • id_rsa - prywatny - dostęp tylko dla właściciela
  • id_rsa.pub - publiczny - dystrybuowany do kogokolwiek

Kolejny krok - na koncie systemu docelowego - u1@debiansrv05 należy upewnić się, że istnieje katalog ~/.ssh/, utworzyć go i nadać tylko właścicielowi uprawnienia:

u1@debiansrv05:~$ cd ~
u1@debiansrv05:~$ mkdir .ssh
u1@debiansrv05:~$ chmod 700 .ssh
u1@debiansrv05:~$ ls -lad .ssh
drwx------ 2 u1 u1 4096 Jun  9 03:59 .ssh

Następnie, należy dopisać treść klucza publicznego z konta u1 z systemu centosm05 do pliku ~/.ssh/autorized_keys na systemie debiansrv05 (wystarczy wywołać jedną jedną z poniższych komend, które są równoznaczne):

[u1@centosm05 ~]$ ssh-copy-id -i .ssh/id_rsa.pub u1@debiansrv05
[u1@centosm05 ~]$ cat ~/.ssh/id_rsa.pub | ssh u1@debiansrv05 'cat >> .ssh/authorized_keys'

Od teraz każde kolejne logowanie z konta u1@centosm05 na konto u1@debiansrv05 będzie odbywało się bez podawania hasła do tego konta. Na koncie u1@debiansrv05 jest bowiem zapisany klucz publiczny konta u1@centosm05 wśród autoryzowanych dostępów. Dzięki temu serwer ssh ufa temu kontu i może uwierzytelnić użytkownika bez podania hasła.

Agent SSH - zapamiętywanie kluczy

Jeśli dla bezpieczeństwa użytkownik przy generowaniu klucza prywatnego zdecyduje się na zabezpieczenie go dodatkowo hasłem, będzie musiał za każdym razem, gdy go chce użyć podać to hasło. Jest to rozwiązanie bardziej bezpieczne, ale też bardziej uciążliwe. Aby użyć tego samego klucza kilkukrotnie bez konieczności co chwila podawania do niego hasła można skorzystać z agenta ssh - ssh-agent. Agent ten przechowuje bezpiecznie klucz po podaniu raz hasła i używa go do momentu ponownego zalogowania do systemu lub po zdefiniowanym czasie.

Uruchomienie programu, który będzie wykorzystywał klucze u agenta (na przykład bash):

ssh-agent bash

Dodanie do agenta kluczy (argumentem plik z kluczem prywatnym) lub pusta wartość, która spowoduje pobranie klucza z ~/.ssh/id_rsa

ssh-add

Aby obejrzeć listę obecnie przechowywanych w pamięci agenta kluczy:

ssh-add -l

Aby dodać kolejny klucz do agenta:

ssh-add sciezka/do/pliku-z-kluczem-prywatnym

Niektóre dystrybucje uruchamiają ssh-agenta zaraz po zalogowaniu dla domyślnej powłoki. Dzięki temu agent jest zawsze dostępny.

110.3 Securing data with encryption

Zakres tematyki 110.3 Securing data with encryption w zapisie oryginalnym ze strony http://www.lpi.org

Description: The candidate should be able to use puplic key techniques to secure data and communication.

Key Knowledge Areas:

  • Perform basic OpenSSH 2 client configuration and usage.
  • Understand the role of OpenSSH
  • Understand SSH port tunnels (including X11 tunnels).
  • Perform basic GnuPG configuration and usage.
  • Terms and Utilities: ssh ssh-keygen ssh-agent ssh-add ~/.ssh/id_rsa id_rsa.pub ~/.ssh/id_dsa id_dsa.pub /etc/ssh/ssh_host_rsa_key ssh_host_rsa_key.pub /etc/ssh/ssh_host_dsa_key ssh_host_dsa_key.pub ~/.ssh/authorized_keys /etc/ssh_known_hosts gpg ~/.gnupg/*

Masz potrzebę, aby powyższa strona była rozbudowana? - Napisz do nas!.

materialy/bezpieczenstwo/ssh.txt · ostatnio zmienione: 2016/02/17 10:00 przez mzalewski

(C) 2017 ITMZ Mariusz Zalewski