2008.01_Bezpieczna powłoka – OpenSSH_[Bezpieczenstwo].pdf - Bezpieczenstwo - Kapy97

Rozwiązania

Bezpieczna powłoka – OpenSSH

Bezpieczna powłoka

Grzegorz Madajczak

W dawnych czasach standardem komunikacji pomiędzy klientem a serwerem był Telnet – usługa, dzięki której

można zdalnie podłączyć się przez sieć do oddalonego komputera. Dzięki telnetowi można pracować zdalnie

na komputerze, który może znajdować się na drugim końcu świata. Zasadniczo wszystko byłoby dobrze, gdyby

nie fakt, że telnet nie oferuje jakichkolwiek możliwości zabezpieczania transmisji – szyfrowania – a i jego inne

możliwości są skromne. W sukurs przychodzi tu następca telnetu – SSH.

jest obecnie standardem protokołów komuni-

kacyjnych w sieciach komputerowych TCP/IP.

W systemie Linux mówiąc o SSH w rzeczy-

wistości mamy na myśli otwartą implementację tej usłu-

gi – OpenSSH . Na potrzeby tego artykułu będę również

stosował ten skrót myślowy – pisząc SSH mam na myśli

OpenSSH . Usługa SSH zdecydowanie przerosła swojego

poprzednika – telnet . Różnica pomiędzy obydwoma pro-

gramami polega przede wszystkim na tym, że SSH używa

jedynie szyfrowanego połączenia. Ponadto SSH poza ter-

minalem znakowym, jak w telnet, oferuje jeszcze narzę-

dzia do bezpiecznego przesyłania plików – SCP i SFTP,

zdalna kontrolę zasobów, tunelowanie oraz możliwość

uruchamiania programów w trybie graicznym. Jakość i

bezpieczeństwo usług oferowanych przez SSH sprawiła,

że wszelkie inne tego typu usługi, np. Rlogin, RSH, prze-

stały funkcjonować.

nie stosując szyfrowaną transmisję danych. SSH w wersji

2 (obecnie stosowana), stosuje najlepsze algorytmy szy-

frujące, które do tej pory nie zostały złamane: AES, Blow-

ish, 3DES oraz nieco słabszy RC4 (szyfr strumieniowy

Rivest Cipher 4 ). Szyfrowanie następuje jeszcze przed

uwierzytelnieniem, dzięki czemu ani hasło, ani jakiekol-

wiek inne informacje nie są przesyłane w sposób niebez-

pieczny. Szyfrowanie transmisji danych zabezpiecza rów-

nież przed fałszywymi pakietami.

Kolejnym mechanizmem poprawiającym bezpie-

czeństwo w SSH jest bardzo dobrze dopracowane uwie-

rzytelnianie. Zapobiega to takim próbom włamania jak

fałszowanie adresu IP ( IP spooing ), fałszowanie DNS

( DNS spooing ) oraz inny metodom włamań do serwe-

ra SSH. SSH oferuje proste uwierzytelnianie przy użyciu

hasła, rozpoznawanie klienta wraz z kluczem RSA lub

sam klucz RSA oraz uwierzytelnianie z użyciem proto-

kołu Kerberos .

Bezpieczeństwo w SSH

Sama nazwa usługi ( secure shell – bezpieczna powłoka)

podkreśla oferowane bezpieczeństwo. Uzyskano to głów-

Instalacja OpenSSH

Praktycznie we wszystkich dystrybucjach Linuksa znaj-

dują się pakiety binarne OpenSSH. Jednak ze względów

styczeń 2008

– OpenSSH

S SH (z ang. secure shell – bezpieczna powłoka)

Rozwiązania

Bezpieczna powłoka – OpenSSH

bezpieczeństwa, warto mieć zawsze naj-

nowszą stabilną wersję SSH. Dlatego pro-

ponuję zajrzeć na stronę jednego z mirrorów

[1], gdzie znajdują się pakiety ze źródłami

oraz gotowe do instalacji pakiety binarne

*.rpm , przygotowane dla Fedora Core i Re-

dHat. Literka p przy numerze wersji pakietu

oznacza, że jest to odmiana przenośna ( por-

table ) SSH, tzn. przygotowana między inny-

mi dla Linuksa, gdyż pierwotnie OpenSSH

powstało dla systemu OpenBSD. Zachęcam

wszystkich do samodzielnej kompilacji i in-

stalacji OpenSSH. Całość procesu sprowa-

dza się bowiem do kilku prostych poleceń

wydanych w konsoli.

bezpieczeństwo, należy zmienić kilka usta-

wień. Oczywiście zaprezentowane ustawie-

nia są jedynie propozycją, ednak ich zastoso-

wanie może znacząco poprawić bezpieczeń-

stwo serwera SSH w porównaniu do domyśl-

nych ustawień.

Obydwa powyższe polecenia są równoznacz-

ne i oznaczają zalogowanie się na serwer na

konto użytkownika nazwa_użytkownika . Je-

śli nazwa użytkownika lokalnego i zdalne-

go pokrywają się, w powyższych polece-

niach można nazwę zdalnego użytkownika

pominąć.

Dla każdego serwera SSH, z którym się

łączymy do pliku ~/.ssh/know_hosts zapisane

są odciski palca zdalnego komputera utwo-

rzone podczas pierwszego logowania. Na-

stępnie podczas każdego następnego logowa-

nia na ten komputer ponownie sprawdzany

jest odcisk palca, co ma zapobiec logowaniu

się na serwer z fałszywym IP ( IP spooing ).

W przypadku gdy w pliku koniguracyj-

nym serwera SSH zmieniliśmy numer portu

(patrz Tabela 1.), łącząc się z serwerem musi-

Korzystanie z SSH

Zastosowanie SSH jest bardzo proste. W ce-

lu zalogowania się na zdalnym serwerze wy-

dajemy polecenie:

$ ssh nazwa_użytkownika@adres_serwera

lub

# tar xvzf openssh-4.7p1.tar.gz | cd

openssh-4.7p1

# ./conigure --preix=/usr

# make | sudo make install

$ ssh -l nazwa_użytkownika adres_

serwera

Przed instalacją warto zapoznać się z in-

formacjami zawartymi w pliku README

oraz INSTALL zlokalizowanymi w katalo-

gu ze źródłami. Dobrze jest też przed wła-

ściwą koniguracją źródeł wydać polecenie

./conigure --help , aby zapoznać się z do-

stępnymi opcjami koniguracyjnymi. Tak np.

kompilacja programu ze wsparciem dla ha-

seł jednorazowych wymaga podania podczas

koniguracji lagi --with-skey .

server OpenSSH

server IRC

Koniguracja serwera SSH

Przed nami w tej chwili najtrudniejsza część

pracy – koniguracja serwera SSH. Od jako-

ści naszej pracy, odpowiednich ustawień za-

leży nie tylko to, czy serwer będzie działał.

Najważniejszą sprawą jest bowiem bezpie-

czeństwo serwera, zależne od odpowiednich

opcji koniguracyjnych, które na tym etapie

ustawimy.

Pliki koniguracyjne serwera SSH zloka-

lizowane są w katalogu /etc/ssh . Najważniej-

szym plikiem jest /etc/ssh/sshd_conig , któ-

rym w tej chwili się zajmiemy. Jest to zwy-

kły plik tekstowy, który edytować może-

my w ulubionym edytorze. Oczywistym jest

za pewne dla każdego, że do wprowadzania

zmian w pliku sshd_conig musimy posiadać

uprawnienia administratora systemu. Więk-

szość opcji zawartych w pliku jest zahaszo-

wana (nieaktywna), tzn. na początku linii

znajduje się znak # . Jeśli chcemy uaktywnić

jakieś ustawienie, należy wykasować znak #

z początku linii i czasami zmienić wartość.

Do prawidłowej pracy serwera wystarczy do-

myślna koniguracja omawianego pliku. Za-

znaczam jednak, że słowo prawidłowa nie

oznacza bezpiecznej pracy. Aby poprawić

SSH

IRC

6667

klient

Rysunek 1. Przykładowa koniguracja pliku ~/.ssh/conig dla dwóch serwerów SSH

klient

poczty

serwer

pocztowy

port

1234

port

110

klient

SSH

port

Tunel SSH

port

serwer

SSH

komputer

lokalny

zdalny

serwer

Rysunek 2. Tunelowanie SSH jako sposób ominięcia zapory ogniowej aby korzystać z zablokowanego IRCa

www.lpmagazine.org

Rozwiązania

Bezpieczna powłoka – OpenSSH

my wskazać ten numer, gdyż w przeciwnym

wypadku klient będzie łączył się na domyśl-

nym porcie – 22. Służy do tego laga -p w po-

leceniu ssh.

komputerze, którego efekt np. zostanie na-

tychmiast wyświetlony na monitorze. Na

przykład, gdy chcemy zobaczyć, kto aktu-

alnie jest zalogowany na serwerze SSH, wy-

starczy wydać polecenie:

Z innych użytecznych opcji ssh war-

to zapamiętać flagę -i służącą do wska-

zania pliku z kluczem prywatnym służą-

cym do logowania się na serwerze (więcej

o kluczach w następnym rozdziale artyku-

łu). Drugą przydatną flagą jest -f , przeno-

si działanie polecenia w tło. Flaga ta mo-

że być wykorzystywana przy wykonywaniu

szczególnie pracochłonnych i czasochłon-

nych poleceń:

$ ssh -p 55 192.168.0.0

$ ssh 192.168.0.5 who

Jeśli nie chcemy za każdym razem podawać

numeru portu, zmianę ta można zapisać w

pliku koniguracyjnym klienta SSH – ~/.ssh/

conig . W pliku tym należy zapisać, że dla

komputera o danym IP (nazwie) port SSH

przyjmuje następującą wartość. Przykłado-

wy wygląd takiego pliku z koniguracją dla

dwóch komputerów przedstawia Listing 1.

Czasami istnieje potrzeba wykonania

jednego prostego polecenia na zdalnym

Można również efekt działania polecenia

wykonanego na zdalnym serwerze zapi-

sać do lokalnego pliku. Na przykład w ce-

lu przejrzenia logów systemowych pod ką-

tem aktywności na serwerze SSH można wy-

dać polecenie:

$ ssh -i /mnt/usb/id_rsa 192.168.0.5

W powyższym poleceniu wskazujemy na

klucz zapisany na pamięci w pliku id_rsa .

$ ssh 192.168.0.5 cat /var/log/

messages | grep ssh > logi_ssh

Logowanie na serwerze

SSH przy użyciu klucza

Zaprezentowane w Tabeli 1. ustawienia za-

kładają, że do serwera SSH można zalogo-

wać się jedynie przy użyciu klucza. Rozwią-

zanie to przewyższa logowanie przy użyciu

samego hasła, gdyż hipotetycznie możemy

założyć sytuację, w której niepożądana oso-

ba podpatrzy wpisywane przez nas hasło, np.

za pomocą programu śledzącego aktywność

klawiatury. Znając hasło uzyskuje dostęp do

serwera SSH. Najgorzej, jeśli logujemy się

bezpośrednio na konto administratora – wte-

dy straty mogą być ogromne. W sytuacji lo-

gowania z użyciem klucza, podpatrzenie ha-

sła zabezpieczającego klucz nic nie daje wo-

bec braku samego klucza. Zastosowanie klu-

cza RSA daje ponadto jeszcze jedną możli-

wość – logowanie się na serwerze bez użycia

hasła poprzez wskazanie kluczanie zabezpie-

czonego hasłem. Rozwiązanie takie jest nie-

co mniej bezpieczne od logowania z kluczem

zabezpieczonym. Jednak np. obrębie sieci

domowej taka koniguracja ułatwia pracę z

serwerem SSH.

SSH daje możliwość wykorzystania do

logowania się par kluczy utworzonych za

pomocą algorytmu RSA lub DSA. Zalecam

jednak wykorzystanie bezpieczniejszego al-

gorytmu RSA, gdyż DSA został złamany i

nie zapewnia należytego poziomu bezpie-

czeństwa.

W celu utworzenie pary kluczy RSA

(prywatnego i publicznego), na lokalnym

komputerze (kliencie serwera SSH) w kon-

soli użytkownika, z konta którego będzie-

my się logować na serwer wydajemy po-

lecenie:

Rysunek 3. Schemat działania tunelu SSH do bezpiecznego przesyłania poczty

$ ssh-keygen -t rsa

Rysunek 4. Program PuTTY

Po wydaniu powyższego polecenia zostanie-

my zapytani o nazwę pliku, w którym ma zo-

styczeń 2008

Rozwiązania

Bezpieczna powłoka – OpenSSH

stać zapisany klucz prywatny. Proponuję

trzymać się w tym względzie domyślnych

ustawień ( ~/.ssh/id_rsa ). Jeśli istnieje wcze-

śniej utworzony klucz, zostaniemy zapytani,

czy chcemy go nadpisać. W kolejnym kroku

program poprosi nas o podanie hasła zabez-

pieczającego klucz. Jeśli nie podamy hasła

( dwa razy Enter ), uzyskamy klucz niezabez-

pieczony hasłem. Jeśli nie chcemy tego zro-

bić, należy podac odpowiednio długie i bez-

pieczne hasło. Najlepiej jest posłużyć się spe-

cjalnymi skryptami generującymi losowy ze-

staw znaków. Po zatwierdzeniu hasła, zosta-

nie utworzony klucz prywatny – zapisany w

pliku ~/.ssh/id_rsa oraz klucz publiczny – w

pliku ~/.ssh/id_rsa.pub . Gdy po utworzeniu

klucza bez hasła dojdziemy jednak do wnio-

sku, że nie było to rozsądne rozwiązanie, mo-

żemy ponownie zabezpieczyć klucz wywołu-

jąc w konsoli polecenie:

Listing 1. Przykładowa koniguracja pliku ~/.ssh/conig dla dwóch serwerów SSH

# opcje koniguracyjne w pliku ~/.ssh/conig

#opcje dla pierwszego komputera

Host 192.168.0.0

Port 55

User nazwa_użytkownika

IdentityFile ~/.ssh/id_rsa_komp1

# opcje dla drugiego komputera

Host 192.168.0.1

Port 22

User uzytkownik_1

IdentityFile ~/.ssh/id_rsa_komp2

blicznego (z pliku ~/.ssh/id_rsa.pub ) do

zdalnego komputera – serwera SSH. Mo-

żemy w tym celu użyć np. polecenia scp , o

którym więcej będzie mowa w dalszej czę-

ści artykułu. W tym celu w konsoli wydaje-

my polecenie:

putera na komputer o IP 192.168.0.5. Aby

wykonać to, jak i następne polecenie mu-

simy mieć dostęp do serwera SSH. Zakła-

dam więc, że na tym etapie nadal posiada-

my możliwość logowania się przy użyciu

hasła. Logujemy się więc na serwer SSH,

gdzie wydajemy polecenie dopisania hasła

publicznego z naszego lokalnego komputera

do listy autoryzowanych kluczy.

$ ssh-keygen -f ~/.ssh/id_rsa

Po wydaniu powyższego polecenia zosta-

niemy poproszeni o podanie starego hasła

(wciskamy Enter ) i podanie nowego. Na-

stępnym kokiem jest przesłanie klucza pu-

$ scp ~/.ssh/id_rsa.pub nazwa_

użytkownika@192.168.0.5:~/

Powyższe polecenie w bezpieczny sposób

skopiuje klucz publiczny z lokalnego kom-

$ cat ~/id_rsa.pub >> ~/.ssh/

authorized_keys

Tabela 1. Opcje koniguracyjne serwera OpenSSH

Opcja koniguracyjna Opis Propozycja

Port Ustawienie portu działania serwera Port 32

Protocol Ustawienie protokołu działania serwera SSH – 1 lub 2. Protocol 2

LoginGraceTime Czas w minutach, po jakim serwer zrywa połączenie, jeśli użytkow-

nik nie zdążył się zalogować. „0” oznacza brak limitu.

LoginGraceTime 1m

PermitRootLogin Zezwolenie na bezpośrednie logowanie się na konto administratora. PermitRootLogin no

MaxAuthTries

Liczba prób zalogowania się. Po wyczerpaniu limitu zrywane jest

połączenie.

MaxAuthTries 3

RSAAuthentication Włącza/wyłącza autoryzację RSA RSAAuthentication yes

PubkeyAuthentication Włącza/wyłącza autoryzację za pomocą klucza publicznego PubkeyAuthentication no

RhostsRSAAuthentication Włącza/wyłącza autoryzacją za pomocą plików rhost i RSA RhostsRSAAuthentication no

HostBasedAuthentication

Włącza/wyłącza autoryzacją za pomocą identyikacji hosta HostBasedAuthentication no

PasswordAuthentication Włącza/wyłącza autoryzacją za pomocą hasła

PasswordAuthentication no

PermitEmptyPasswords Zezwolenie na puste hasła.

IdleTimeout

Czas oczekiwania na podanie hasła

Istotne tylko przy włączonej opcji powyżej. Pozostawić za-

haszowane.

X11Forwarding Zezwolenie na połączenie z serwerem X11

X11Forwarding yes

ClientAliveInterval Określa czas bezczynności, po upływie którego serwer wyśle do

klienta zapytanie.

ClientAliveInterval 10

ClientAliveCountMax Określa liczbę zapytań jak powyżej. Po przekroczeniu limitu nastę-

puje odłączenie klienta.

ClientAliveCountMax 3

DenyUsers

Lista użytkowników zablokowanych

DenyUsers user1, user2

AllowUsers

Lista dopuszczonych użytkowników

AllowUsers user1, user2

DenyGroups

Lista grup zablokowanych

DenyGroups grupa1, grupa2

AllowGroups

Lista grup dopuszczonych

AllowGroups grupa1, grupa2

www.lpmagazine.org

Rozwiązania

Bezpieczna powłoka – OpenSSH

Następnie usuwamy plik z kluczem i zmie-

niamy prawa dostępu do pliku authori-

zed_keys.

wany odpowiednik protokołu transportu pli-

ków ftp.

Podstawowe użycie programu scp zo-

stało przedstawione w rozdziale o tworzeniu

kluczy RSA. Składnia tego polecenia jest na-

stępująca: scp plik_źródłowy plik_doce-

lowy . W przypadku gdy chcemy skopiować

plik z serwera SSH na lokalny komputer w li-

nii poleceń wpisujemy komendę:

Polecenie sftp jest odpowiednikiem ftp,

z tym, że realizowanym przez bezpiecz-

ne – szyfrowane połączenie. Podsystem

sftp jest włączony w domyślnej konigura-

cji serwera SSH. Użycie tego polecenia ni-

czym nie różni się od nieszyfrowanego od-

powiednika. Wywołanie polecenia wygląda

następująco:

$ rm -f ~/id_rsa.pub

$ chmod 600 ~/.ssh/authorized_keys

Po wykonaniu powyższych czynności po-

winno działać logowanie się z użyciem klu-

cza. Koniguracja serwera SSH zakłada, że

w przypadku dopuszczonego logowania się

z kluczem, najpierw sprawdzane są klucze, a

dopiero później, w przypadku niepowodzenia,

zdalny użytkownik pytany jest o hasło (jeśli

ta metoda logowania nie została wcześniej za-

blokowana). Zablokują one inne możliwości

logowania się, niż z użyciem klucza RSA.

$ sftp użytkownik@192.168.0.5

$ scp użytkownik@192.168.0.5:katalog/

plik ~/

Polecenie sftp można użyć podobnie, jak scp,

tzn. do pobrania pojedynczego pliku, bez

otwierania konsoli ftp:

Powyższe polecenie skopiuje zdalny plik do

katalogu domowego ( ~ ) użytkownika na lo-

kalnym komputerze. Polecenie, wykonujące

odwrotną sytuację (wysyłanie pliku na ser-

wer) wygląda następująco:

$ sftp użytkownik@192.168.0.5:plik_do_

pobrania

Bezpieczne

przesyłanie plików – scp i sftp

Jak już wcześniej zaznaczyłem, wyższość

SSH nad Telnetem polega między innymi na

dodatkowych możliwościach, których Tel-

net nie oferuje. Jedną z takich możliwości

jest bezpieczne, bo szyfrowane przesyłanie

plików. W tym celu posłużyć mozemy się

dwoma poleceniami wchodzącymi w skład

pakietu OpenSSH: scp – do bezpośrednie-

go kopiowania plików oraz sftp – szyfro-

$ scp plik_do_wysłania

uzytkownik@192.168.0.5:katalog/

Polecenie sftp umozliwia również graiczne

łączenie się ze zdalnym serwerem, tak jak-

by to był lokalny zasób. Można w tym ce-

lu wykorzystać każdy graiczny menadżer

plików. W pasku adresu wpisujemy wtedy:

sftp://użytkownik@serwer . Jeśli połączymy

tę funkcję z logowaniem się z użyciem nie-

zabezpieczonego hasłem klucza, całość moż-

na zautomatyzować dodając do katalogu au-

tostartu środowiska graicznego skrypt z za-

prezentowanym powyżej poleceniem. Dla

Konquerora w KDE będzie wyglądało to na-

stępująco:

Polecenie scp posiada również lagi modyi-

kujące jego działanie. Tak np. laga -r odpo-

wiedzialna jest za kopiowanie całego katalo-

gu, wraz z jego zawartością.

$ scp -r użytkownik@192.168.0.0:

katalog_do_skopiowania/ ~/

Polecenia sftp

$ echo #!/bin/bash >> ~/.kde/

Autostart/sesja_sftp

$ echo konqueror sftp

użytkownik@serwer >> ~/.kde/Autostart/

sesja_sftp

$ chmod +x ~/.kde/Autostart/sesja_sftp

• cd <ścieżka> – zmiana zdalnego katalogu

• lcd <ścieżka> – zmiana lokalnego katalogu

• chgrp <grupa> <ścieżka> – zmiana grupy pliku

• chmod <tryb> <ścieżka> – zmiana uprawnień pliku

• chown <właściciel> <ścieżka> – zmiana właściciela pliku

• help – podstawowa pomoc

• get <zdalna_ścieżka> [lokalna_ścieżka] – pobieranie pliku z serwera

• lls [opcje-ls [ścieżka]] – wylistowanie lokalnego katalogu

• ln <stara_ścieżka> <nowa_ścieżka> – utworzenie linku

• lmkdir <ścieżka> – utworzenie lokalnego katalogu

• lpwd – wyswietlenie lokalnego katalogu

• ls [ścieżka] – wylistowanie zdalnego katalogu

• mkdir <ścieżka> – utworzenie zdalnego katalogu

• put <lokalna_ścieżka> [zdalna_ścieżka] – przesłanie pliku na serwer

• pwd – wyświetlenie aktualnego zdalnego katalogu

• exit – opuszczenie sftp

• quit – opuszcznie sftp

• rename <stara_ścieżka> <nowa_ścieżka> – zmiana nazwy pliku

• rmdir <ścieżka> – usunięcie zdalnego folderu

• rm <ściezka> – usunięcie zdalnego pliku

• symlink <stara_ścieżka> <nowa_ścieżka> – utworzenie zdalnego linku

• version – wyświetla wersję sftp

• !command – wykonanie polecenia

• ! – upuszcza sftp do powłoki (zdalnej)

• ? – uproszczona pomoc (to samo co help)

Rysunek 5. Program pssh – SSH dla Palm OS

styczeń 2008

2008.01_Bezpieczna powłoka – OpenSSH_[Bezpieczenstwo].pdf

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: