styczeń 2004

44

dla początkujących

Praca z OpenSSH

Piotr Machej

W

dobie powszechnej dostępności Interne-
tu coraz więcej osób zdaje sobie sprawę
z czyhających w nim niebezpieczeństw.
Minęły już czasy, gdy można było swo-

bodnie korzystać z Telnetu nie martwiąc się, że ktoś pod-
słucha nasze hasło i włamie się nam na konto. Standardem
w łączeniu się ze zdalnymi komputerami jest obecnie SSH
w wersji 2 (Secure SHell, czyli bezpieczna powłoka).

W niniejszym artykule omówimy instalację, konfigura-

cję i wykorzystanie programu OpenSSH, bezpłatnej i wolnej
wersji oprogramowania obsługującego protokół SSH. Dzięki
niemu możemy logować się na zdalne maszyny i kopiować
między nimi pliki bez obawy o to, że ktoś podsłucha nasze
hasło czy przesyłane dane.

Przykład użycia

Grałem właśnie w Tux Racer, gdy na komórkę przyszedł
SMS od jednego ze znajomych. Prosił ze łzami (wirtu-
alnymi) w oczach o udostępnienie mu jakiegoś konta,
z którego mógłby wchodzić na IRC bez ograniczeń (bez
flagi restricted ).

Ponieważ bardzo go lubię, od razu (no, prawie – naj-

pierw dojechałem do mety) przełączyłem się na mój Multi
GNOME Terminal, aby zalogować się na serwer stojący
na drugim końcu Polski. Oczywiście do połączenia
wykorzystałem OpenSSH, a nie Telnet – przecież nie
pozwolę, aby ktoś mógł podsłuchać moją transmisję. Po
podaniu hasła przeprowadziłem rutynowe sprawdzenie,
czy z serwerem wszystko w porządku (a jakże, stoi bez
problemów już drugi miesiąc od ostatniego wyłączenia
prądu). Zalogowałem się na konto root, a następnie utwo-
rzyłem znajomemu konto. Wysłałem do niego wiadomość
z nazwą użytkownika i hasłem, które zmienił zaraz po
zalogowaniu. Po chwili otrzymałem od niego kolejnego
SMS-a. Powiadamiał mnie w nim, że już utworzył sobie
zgrabny tunel (korzystając z OpenSSH), biegnący przez
mój serwer do serwera IRC. W ten sposób mógł nadal
rozmawiać z użyciem swojego ulubionego mIRC-a, a rów-
nocześnie wszystkim rozmówcom wydawało się, że jest

zalogowany na moim serwerze. Oczywiście flagi restric-
ted też już nie miał.

Korzystając z okazji sprawdziłem jeszcze, co ciekawego

jest udostępnione w sieci lokalnej podłączonej do zdalnego
serwera. Gdy znalazłem (sądząc po nazwie) zestaw mango-
wych tapet, nie mogłem się powstrzymać, aby nie pobrać
ich do siebie. Oczywiście znów korzystając z szyfrowanego
kanału. A później wróciłem do przerwanego turnieju w Tux
Racer.

Instalacja serwera i klienta

Takie oprogramowanie, jak OpenSSH, znajduje się
w zasadzie w każdej współczesnej dystrybucji Linuksa.
Jeśli specjalnie nie wykluczyliśmy pakietów z instalacji, to
powinniśmy mieć je już na dysku – wtedy można przejść od
razu do rozdziału o konfiguracji. Chciałbym jednak zwrócić
uwagę na pewną sprawę. Ze względów bezpieczeństwa
należy dbać o to, aby w systemie była zainstalowana naj-
bardziej aktualna wersja OpenSSH, jak również i innych
kluczowych, narażonych na ataki programów. Spróbujmy
więc pobrać i zainstalować najnowszą wersję OpenSSH.

Numeracja wersji

Zaczynamy od uruchomienia przeglądarki interne-
towej (przykładowo Mozilla) oraz otwarcia witry-
ny http://predict.chem.uw.edu.pl/openssh/, która jest
zlokalizowanym w Polsce odpowiednikiem strony http:
//www.openssh.com/. Sprawdzamy na niej, jaki jest numer
najnowszej wersji programu (w chwili pisania artykułu jest
to numer 3.7.1). Następnie wybieramy odnośnik "Linux,

O autorze:

Autor zakończył studia zaoczne na V roku Informatyki na

Politechnice Opolskiej. Z Linuksem (i ogólnie systemami

uniksowymi) ma styczność od wielu lat. Obecnie admi-

nistruje siecią blokową złożoną z dziesięciu komputerów.

Kontakt z autorem: [e-mail].

Rysunek 1.

Na głównej stronie projektu OpenSSH możemy

sprawdzić najnowszy numer wersji

45

www.linux.com.pl

openssh

Solaris, FreeBSD, NetBSD, AIX, IRIX, HP-UX and many
more" znajdujący się po lewej stronie pod napisem "For
other OS's" (Dla innych systemów operacyjnych). Możemy
również po prostu otworzyć witrynę wpisując adres http:
//predict.chem.uw.edu.pl/openssh/portable.html. Znajduje
się na niej spis serwerów FTP, z których można pobrać
aktualne wersje oprogramowania.

Wybieramy serwer, który nam odpowiada (ja pole-

cam

ftp://sunsite.icm.edu.pl/pub/OpenBSD/OpenSSH/

portable/ ), a następnie sprawdzamy, czy znajduje się na
nim aktualna wersja OpenSSH. W chwili pisania artyku-
łu najnowszym plikiem był openssh-3.7.1p2.tar.gz. Jak
widać, numer wersji zgadza się z tym, który odczytaliśmy
na głównej stronie (3.7.1). Znajdująca się po nim literka
p oznacza, że jest to wersja przenośna, przeznaczona na
systemy inne niż OpenBSD (w tym również dla Linuksa).
Aktualny plik pobieramy na dysk.

Użytkownicy dystrybucji Aurox zamiast pobierać wyżej

wymieniony plik mogą wejść do podkatalogu rpm/RH90/
i pobrać odpowiednie pakiety rpm (dla wersji 3.7.1 są to
pliki openssh-3.7.1p2-1.i386.rpm, openssh-askpass-3.7.1p2-
1.i386.rpm,

openssh-askpass-gnome-3.7.1p2-1.i386.rpm,

openssh-clients-3.7.1p2-1.i386.rpm, openssh-server-3.7.1p2
-1.i386.rpm). Ewentualnie możemy pobrać pakiet openssh-
3.7.1p2-1.src.rpm z podkatalogu rpm/SRPMS/ i samodziel-
nie go przebudować.

Instalacja pakietów

Jeśli pobraliśmy pakiety rpm, możemy zainstalować je
w systemie. Potrzebujemy do tego uprawnień super-
użytkownika, więc zaczynamy od wydania polecenia

su

-

i podania hasła użytkownika root. Następnie przecho-

dzimy do katalogu, w którym znajdują się pobrane pakie-
ty i wydajemy polecenie:

rpm -Uvh openssh-3.7.1p2-1.i386.rpm

S

openssh-askpass-3.7.1p2-1.i386.rpm

S

openssh-askpass-gnome-3.7.1p2-1.i386.rpm

S

openssh-clients-3.7.1p2-1.i386.rpm

S

openssh-server-3.7.1p2-1.i386.rpm

Jeśli wolimy zbudować pakiety samodzielnie, w katalogu
z pakietem źródłowym (w naszym przykładzie z plikiem
openssh-3.7.1p2-1.src.rpm) wydajemy polecenie

rpmbuild

--rebuild openssh-3.7.1p2-1.src.rpm

. Jeśli nie mamy w sys-

temie programu rpmbuild, to powinniśmy zainstalować
pakiet rpm-build z drugiej płyty CD dystrybucji Aurox.
Po zakończeniu budowania pakiety zostaną umieszczone
w katalogu /usr/src/redhat/RPMS/i386/.

Użytkownicy dystrybucji opartych o inne systemy

pakietów mogą samodzielnie skompilować program (w
sposób opisany w Ramce Kompilacja) lub pobrać go
z wykorzystaniem odpowiednich dla dystrybucji systemów
zarządzania pakietami (przykładowo apt-get w Debianie).

Uruchomienie serwera

Po zainstalowaniu OpenSSH, plik serwera (sshd) powinien
znajdować się w katalogu /usr/sbin/ lub /usr/local/sbin/
– zależnie od instalacji. Jeśli mamy wątpliwości, możemy
jego lokalizację sprawdzić poleceniem

which sshd

, wywoła-

nym z konta użytkownika root.

W dystrybucji Aurox możemy go uruchomić polece-

niem

/etc/rc.d/init.d/sshd start

, a zatrzymać za pomocą

/etc/rc.d/init.d/sshd stop

. Jeśli zmieniamy konfigurację

programu, powinniśmy go zrestartować. Służy do tego
polecenie

/etc/rc.d/init.d/sshd restart

.

Zwykle chcemy, aby serwer OpenSSH uruchamiał się

przy starcie systemu. W tym celu uruchamiamy polecenie

ntsysv

i upewniamy się, że przy pozycji sshd znajduje się

gwiazdka. Jeśli nie, to zaznaczamy ją i wciskamy OK.

Kompilacja ze źródeł

W katalogu, w którym mamy plik ze źródłami programu (w
naszym przykładzie jest to plik openssh-3.7.1p2.tar.gz), wyda-
jemy polecenie

tar xvzf openssh-3.7.1p2.tar.gz

. Utworzy

ono podkatalog o nazwie openssh-3.7.1p2/ i umieści w nim
rozpakowane źródła. Wchodzimy do katalogu poleceniem

cd

openssh-3.7.1p2/

.

Teraz możemy wydać polecenie

./configure

. Domyślnie

OpenSSH instaluje się w podkatalogach katalogu /usr/local/
(dokładne ścieżki zostaną wypisane na ekranie). Jeśli chcemy
to zmienić, możemy użyć przykładowo polecenia

./configure

--prefix=/usr

.

Następnie wydajemy polecenie

make

, co spowoduje prze-

prowadzenie właściwej kompilacji. Po jej zakończeniu musimy
skorzystać z uprawnień użytkownika uprzywilejowanego.
Wydajemy polecenie

su

i podajemy hasło użytkownika root,

a następnie przeprowadzamy instalację OpenSSH poleceniem

make install

.

Jeśli chcemy skorzystać z innych opcji konfiguracyjnych,

możemy się z nimi zapoznać wydając polecenie

./configure

--help

. Warto też zapoznać się z plikami README i INSTALL

umieszczonymi w katalogu ze źródłami.

Rysunek 2.

Po wykonaniu ./configure należy sprawdzić,

czy ustawienia nam odpowiadają

styczeń 2004

46

dla początkujących

W innych dystrybucjach skrypty te mogą być w innych

katalogach lub może ich w ogóle nie być. Jeśli nie wiemy,
jak poradzić sobie inaczej, to możemy uruchamiać serwer
poleceniem

/usr/sbin/sshd

, restartować go poleceniem

killall -HUP sshd

, a wyłączać poprzez

killall sshd

.

Konfiguracja serwera

Pliki konfiguracyjne OpenSSH znajdują się w katalogu
/etc/ssh/. Podstawowym plikiem jest /etc/ssh/sshd_config.
Możemy edytować go naszym ulubionym edytorem tek-
stowym (jak zwykle preferuję edytor Vim, ale każdy może
wybrać taki, jaki lubi najbardziej).

Większość opcji w tym pliku ujęta jest w komentarze (na

początku linii znajduje się znak

#

). Są to opcje posiadające

wartości domyślne. Jeśli chcemy je zmienić, należy usunąć
znak

#

z początku wybranej linii i zmienić wartość opcji.

Powstaje pytanie, które opcje zmieniać. Pomimo tego,

że serwer działa dobrze nawet na domyślnych opcjach,
warto dostosować je do własnych potrzeb. W ramce
wymieniłem wybrane opcje konfiguracyjne. Bardziej
dociekliwym Czytelnikom polecam lekturę podręcznika
systemowego (

man sshd_config

), w którym znajdą opis

pozostałych opcji.

Konfiguracja klienta

Domyślne opcje konfiguracyjne klienta są zwykle zado-
walające dla większości użytkowników. Wielu z nich
nie zdaje sobie jednak sprawy z ilości dostępnych opcji.
Głównym plikiem konfiguracyjnym jest plik /etc/ssh/
ssh_config. Zawiera on ustawienia wspólne dla wszyst-
kich użytkowników. Oprócz tego, każdy z użytkowników
może utworzyć własny plik konfiguracyjny o nazwie
~/.ssh/config oraz dodać opcje podczas wpisywania pole-
cenia w linii komend.

Kolejność pobierania danych przez OpenSSH jest nastę-

pująca:

• parametry podane w linii komend;
• opcje zawarte w pliku konfiguracyjnym użytkownika

(~/.ssh/config);

• opcje zawarte w systemowym pliku konfiguracyjnym

(/etc/ssh/ssh_config).

Dla każdej opcji pobierana jest tylko pierwsza napotka-
na wartość (pozostałe są ignorowane). Jeśli więc jakaś
opcja znajdzie się w kilku miejscach pliku ~/.ssh/config,
to zostanie jej przypisana pierwsza napotkana wartość.
A jeśli dodatkowo użytkownik ustawi opcję w linii
komend, to wszystkie jej wystąpienia w plikach konfigu-
racyjnych zostaną zignorowane.

Opcje w pliku konfiguracyjnym mogą być pogru-

powane w zależności od komputera, którego dotyczą
– różne opcje dla każdego komputera, z którym się łączy-
my. Każda taka sekcja zaczyna się od linii o treści:

Wybrane opcje konfiguracyjne serwera:

• Port – określa, na jakim porcie serwer nasłuchuje przycho-

dzących połączeń (domyślnie ustawiona na wartość 22);

• Protocol – określa, które wersje protokołu SSH są obsłu-

giwane przez serwer (domyślnie obsługiwane są obie,
więc opcja przyjmuje wartość 2,1);

• ListenAddress – wskazuje adresy, na których serwer

nasłuchuje przychodzących połączeń (domyślnie nasłuch
prowadzony jest na wszystkich dostępnych adresach);

• LoginGraceTime – wyznacza czas, po jakim serwer zrywa

połączenie, jeśli użytkownik nie zdążył się zalogować
poprawnie (domyślnie wynosi 2 minuty, a ustawienie tej
opcji na 0 wyłącza limit czasu);

• PermitRootLogin – określa, czy można logować się

bezpośrednio na konto użytkownika root. Zalecane jest
ustawienie tej opcji na no, gdyż utrudnia to zadanie
ewentualnemu włamywaczowi (najpierw musi zdobyć
konto zwykłego użytkownika). Oprócz wartości yes i no
są dostępne jeszcze without-password oraz forced-
commands-only. Wartość without-password sprawia,
że użytkownik root nie może zalogować się korzystając
z hasła systemowego (nadal jednak może użyć klucza
publicznego). Z kolei forced-commands-only pozwala
mu na zautoryzowanie się z pomocą klucza publicznego,
jednak dopuszcza tylko wykonanie komendy podanej
w wywołaniu OpenSSH.

• PubkeyAuthentication – pozwala na autoryzację z użyciem

klucza publicznego (domyślnie ustawiona na yes (tak));

• AuthorizedKeysFile – wskazuje plik w katalogu domowym

użytkownika, który zawiera klucze publiczne osób mogą-
cych logować się na konto;

• PasswordAuthentication – pozwala na autoryzację z uży-

ciem hasła systemowego (domyślnie ustawiona na yes
(tak));

• PermitEmptyPasswords – tę opcję lepiej pozostawić usta-

wioną na no, dzięki czemu nie będzie możliwe logowanie
się na konta z pustymi hasłami;

• Subsystem sftp – konfiguruje dodatkową usługę bezpiecz-

nego transferu plików (SFTP).

Rysunek 3.

PuTTY jest bardzo wygodnym klientem SSH pod

Windows – pozwala nawet korzystać z klucza prywatnego

47

www.linux.com.pl

openssh

Host nazwa.serwera

Należy wiedzieć, że nazwa_serwera powinna być dokład-
nie tą nazwą, którą wpisujemy w linii poleceń podczas uru-
chamiania OpenSSH. Wynika to z tego, że nazwa ta nie jest
konwertowana do postaci kanonicznej przed porównaniem
z wartością opcji Host. Jeśli zależy nam, aby jakieś opcje
dotyczyły wszystkich serwerów, to umieszczamy je w sekcji

Host *

. Sekcja ta powinna znajdować się na samym końcu

pliku (ze względu na to, że pobierane są tylko pierwsze
wystąpienia opcji).

Praca z OpenSSH

OpenSSH najczęściej wykorzystujemy do bezpiecznego
logowania się na konta na zdalnych serwerach. W takim
przypadku wywołanie programu jest proste:

ssh uż[e-mail]

Ewentualnie możemy skorzystać z postaci:

ssh -l użytkownik adres.serwera

Jeśli na zdalnym serwerze mamy taką samą nazwę użyt-
kownika, jak na lokalnym, możemy używać skróconej pos-
taci:

ssh adres.serwera

Jeśli ze zdalnym komputerem łączymy się po raz pierwszy,
pojawi się napis podobny do poniższego:

The authenticity of host '192.168.0.24 (192.168.0.24)'
can't be established.
RSA key fingerprint is 78:49:c7:a5:de:6b:6c:41:e6:
45:22:bd:87:b0:a4:c1.
Are you sure you want to continue connecting (yes/no)?

Dla każdego komputera, z którym się łączymy, OpenSSH
przechowuje w pliku ~/.ssh/known_hosts tzw. odcisk
palca (fingerprint). Podczas każdego połączenia wartość
ta jest sprawdzana, co pozwala wykryć potencjalne ataki
DNS spoofing. Jeśli jesteśmy pewni, że łączymy się do wła-
ściwego komputera, to wpisujemy yes i wciskamy [Enter].
Warto zaznaczyć, że przy tym pytaniu nie wystarczy
wpisać y – musi to być całe słowo yes.

Po połączeniu zostaniemy zapytani o hasło. Jeśli

podamy je prawidłowo, zostaniemy zalogowani na zdalnym
serwerze. Od tej chwili możemy pracować tak, jakbyśmy
siedzieli przed ekranem zdalnego komputera (oczywiście
pomijając ewentualne opóźnienia).

Wykonywanie poleceń

Czasem na zdalnym komputerze chcemy wykonać tylko
jedno polecenie, przykładowo wyświetlić spis nawiąza-
nych połączeń. Nie musimy wtedy uzyskiwać dostępu do
linii poleceń – wystarczy, jeśli zapoznamy się z wynikiem
działania polecenia. W tym celu do opisanych wcześniej
sposobów wywołania OpenSSH powinniśmy dopisać
polecenie, które chcemy wykonać na zdalnym kompu-
terze, np.:

Klienci pod Windows

Wielu użytkowników nadal pracuje w systemach z rodziny Win-
dows. Nawet użytkownicy Linuksa nieraz sięgają po „okienka”.
Nie są oni pozbawieni możliwości korzystania z SSH. Jeśli chcą
połączyć się z jakimś zdalnym serwerem lub skopiować z niego
plik, mogą skorzystać z jednego z klientów SSH pod Windows.
Wybór jest dosyć szeroki, ale większość programów jest płatna
(zwykle udostępnione są jako shareware lub trial). Chlubnymi
wyjątkami są programy PuTTY oraz WinSCP.

PuTTY

Jest to bardzo wygodny i funkcjonalny program. Istotne jest
również to, że program ten jest w pełni darmowy, a jego kod
jest publicznie dostępny. Jak od razu zauważymy, jest to właści-
wie zestaw kilku programów. Z punktu widzenia przeciętnego
użytkownika, najbardziej przydatne będą programy putty.exe,
pscp.exe i psftp.exe. Pierwszy z nich służy do logowania się na
zdalne maszyny z użyciem między innymi protokołu SSH (sta-
nowi niejako odpowiednik programu OpenSSH opisywanego
w artykule). Drugi i trzeci to kolejno odpowiedniki opisywanych
programów SCP i SFTP. Najlepiej po prostu pobrać instalator
całości (plik putty-0.53b-installer.exe – może być inny numer
wersji), dzięki czemu będziemy mieli zainstalowane wszystkie
pliki z wyjątkiem puttytel.exe (klient pozwalający tylko na połą-
czenia z telnetem).

WinSCP

Tekstowe interfejsy programów SCP i PSCP mogą zrazić użyt-
kowników przyzwyczajonych do posługiwania się myszką. Dla
nich wybawieniem będzie WinSCP. Program ten, z wyglądu
podobny do Total Commandera, pozwala na sprawne kopiowa-
nie plików pomiędzy lokalnym i zdalnym komputerem. Obsługu-
je zarówno SCP, jak i SFTP.

Rysunek 4.

WinSCP na pierwszy rzut oka bardzo przypomina

program Total Commander

styczeń 2004

48

dla początkujących

ssh gerard@192.168.0.35 netstat -nat

Wynik polecenia możemy zapisać w lokalnym pliku:

ssh 192.168.0.5 who > spis.txt

Oczywiście przy każdym z tych poleceń musimy podać
hasło. Jeśli wykonywanie polecenia trwa dłużej, a nie
chcemy mieć zajętej dodatkowej konsoli, możemy spowo-
dować, że OpenSSH natychmiast po pobraniu hasła zosta-
nie przeniesione w tło. Służy do tego parametr -f, który
można wykorzystać w następujący sposób:

ssh -f -L gerard 192.168.4.75 sleep 20

Klucze czy hasła? Oto jest pytanie

Logując się na zdalny serwer z pomocą OpenSSH mamy
pewien komfort psychiczny. Oto bowiem nasza transmisja
jest szyfrowana. Jesteśmy bezpieczni. Zaraz, czy na pewno?
A jeśli ktoś zobaczy, jak wpisujemy hasło? Tak, wtedy on

również może zalogować się na zdalnym serwerze (o ile
zna jego adres) wykorzystując naszą nazwę użytkownika
i poznane hasło. Czy można się przed tym jakoś zabezpie-
czyć? W pewnym stopniu tak.

OpenSSH pozwala na wykorzystanie do logowania się

pary kluczy RSA lub DSA. Jeden z kluczy (zwany publicz-
nym) przechowywany jest na serwerze, na który chcemy
się logować. Natomiast drugi, zabezpieczony hasłem
(zwany kluczem prywatnym) powinniśmy przechowywać
na swoim koncie i absolutnie nie udostępniać go innym
użytkownikom.

Jakie są zalety takiego rozwiązania? Jak już wiemy,

w przypadku stosowania hasła systemowego, wystarczy,
gdy ktoś je odgadnie, podsłucha lub w inny sposób się
z nim zapozna. To daje mu pełny dostęp do naszego konta
na zdalnym serwerze. A co, jeśli pozna hasło chroniące
klucz prywatny? Nic. Bez samego klucza prywatnego hasło
nic mu nie da. Podobnie, gdy uda mu się zdobyć klucz
prywatny, musiałby jeszcze dodatkowo poznać chroniące
go hasło. Jak więc widać, jest to dodatkowa bariera dla
ewentualnego włamywacza.

Klucze RSA dają jeszcze jedną możliwość. Nie musimy

ustawiać hasła chroniącego klucz prywatny. W takim przy-
padku na zdalny komputer logujemy się wydając jedno
polecenie (

ssh uż[e-mail]

) i nie musimy

nawet podawać żadnego hasła. Jest to wygodne, lecz
możliwości tej należy używać ostrożnie – jeśli ktoś uzyska
dostęp do naszego klucza prywatnego, to wszystkie zdalne
systemy, na których umieściliśmy nasz klucz publiczny,
będą stały dla niego otworem.

Stwórzmy teraz nasze klucze RSA. Wydajemy pole-

cenie:

ssh-keygen -t rsa

Jako typ klucza możemy podać rsa1 (klucz RSA dla starszej
wersji SSH), rsa (klucz RSA dla SSH w wersji 2.) oraz dsa
(klucz DSA dla SSH w wersji 2.).

Zostajemy zapytani o nazwę pliku, w którym ma

zostać zapisany klucz prywatny (domyślnie jest to plik
~/.ssh/id_rsa), a następnie o chroniące go hasło. Hasło
to powinno być trudne do odgadnięcia. Najlepiej, jeśli
będzie miało co najmniej 10 znaków (w tym litery duże
i małe oraz cyfry). Musi jednak równocześnie być łatwe
do zapamiętania, gdyż zapomnianego hasła nie da się
odzyskać – w takim przypadku musimy generować
klucze od nowa. Możemy nie ustawiać hasła, jednak nie
jest to zalecane. Po powtórnym wpisaniu hasła klucze
są generowane i zapisywane na dysku. Klucz prywatny
domyślnie znajduje się w pliku ~/.ssh/id_rsa, natomiast
klucz publiczny w pliku ~/.ssh/id_rsa.pub.

Jeśli kiedyś stwierdzimy, że chcemy zmienić hasło

chroniące nasz klucz prywatny, możemy to zrobić wyda-
jąc polecenie

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

. Bedziemy

musieli podać dotychczasowe hasło oraz (dwukrotnie)
nowe hasło.

Wybrane opcje OpenSSH:

• -1 – wymusza pracę w wersji 1. protokołu SSH;
• -2 – wymusza pracę w wersji 2. protokołu SSH;
• -C – włącza kompresję danych (opłacalne jedynie na

modemach i innych wolnych łączach);

• -f – przenosi OpenSSH w tło tuż przed wykonaniem pole-

cenia;

• -F plik_konfiguracyjny – wskazuje alternatywny plik kon-

figuracyjny użytkownika (zamiast domyślnego ~/.ssh/
config);

• -i nazwa_pliku – wskazuje, który plik z kluczem prywatnym

ma być wykorzystany do autoryzacji;

• -l nazwa_użytkownika – podaje nazwę użytkownika, na

którego konto chcemy się zalogować;

• -L port:host:port_hosta – pozwala na przekierowanie

połączeń z lokalnego komputera poprzez szyfrowany tunel
do zdalnego komputera, a następnie do komputera host
(więcej na ten temat w rozdziale Tworzenie tuneli);

• -N – powoduje, że zdalna komenda nie jest wykonywana

(opcja ta użyteczna jest właściwie tylko przy tworzeniu
tuneli i działa jedynie w wersji 2. protokołu SSH);

• -R port:host:port_hosta – pozwala na przekierowanie

połączeń ze zdalnego komputera poprzez szyfrowany
tunel do lokalnego komputera, a następnie do komputera
host;

• -o opcje – pozwala podać dodatkowe opcje (w postaci

używanej w pliku konfiguracyjnym), dla których nie ma
osobnych przełączników;

• -p port – numer portu na zdalnym komputerze, z którym

chcemy się połączyć;

• -q – blokuje drukowanie wszelkich ostrzeżeń i komunika-

tów diagnostycznych;

• -v – drukuje dodatkowe komunikaty (przydatne podczas

rozwiązywania problemów);

• -V – wyświetla numer wersji programu.

49

www.linux.com.pl

openssh

No dobrze, mamy nasze klucze, ale co teraz z nimi

zrobić? Otóż klucz prywatny (~/.ssh/id_rsa) pozostawiamy
w spokoju. Pod żadnym pozorem nie udostępniamy go
nikomu. Natomiast klucz publiczny (~/.ssh/id_rsa.pub) prze-
syłamy na zdalny komputer. Możemy tego dokonać dowol-
ną metodą – poprzez SCP, pocztą czy przez wystawienie na
stronie WWW. Załóżmy, że użyliśmy SCP:

scp ~/.ssh/id_rsa.pub gerard@192.168.0.5:~/

Teraz logujemy się na zdalny komputer (

ssh

gerard@192.168.0.5

). Musimy umieścić klucz publiczny

w pliku .ssh/authorized_keys (lub innym, jeśli zmienialiśmy
wartość opcji AuthorizedKeysFile w pliku /etc/ssh/sshd_
config). Plik ten przechowuje klucze publiczne wszystkich
użytkowników, którzy mogą się logować na nasze konto
bez podawania hasła systemowego. Dokonujemy tego
poleceniem

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

.

Jeśli plik wcześniej nie istniał, to zostanie utworzony.
Powinniśmy wtedy zmienić prawa dostępu do niego pole-
ceniem

chmod 600 ~/.ssh/authorized_keys

. Plik id_rsa.pub

możemy już usunąć ze zdalnego serwera –

rm ~/id_rsa.pub

.

Pozostawiamy go jednak w naszym katalogu ~/.ssh/ wraz
z kluczem prywatnym.

Teraz podczas logowania się na zdalny komputer

zamiast hasła systemowego będziemy podawać hasło chro-
niące klucz prywatny. Nie jest ono przesyłane siecią, więc
jest bezpieczniejsze od hasła systemowego.

Kluczy prywatnych możemy mieć więcej i wykorzy-

stywać je zależnie od potrzeb. Podczas wywoływania
programu OpenSSH (jak również SCP) możemy wskazać
potrzebny nam plik z kluczem prywatnym korzystając
z opcji -i. Przykładowe wywołanie programu mogłoby

mieć postać:

ssh -l gerard -i ~/.ssh/id_rsa 192.168.0.5

Przypomnę tylko, że aby logowanie się z użyciem kluczy
było możliwe, to w konfiguracji serwera (plik /etc/ssh/sshd_
config) musi być ustawiona opcja

PubkeyAuthentication

yes

(domyślnie ma właśnie taką wartość).

Bezpieczne przesyłanie plików,

czyli SCP

OpenSSH nie tylko pozwala nam na bezpieczną pracę
w linii poleceń na zdalnym komputerze. Oprócz tego,
mamy do dyspozycji program SCP, dzięki któremu możemy
kopiować pliki z i na zdalny komputer (a nawet pomię-
dzy dwoma zdalnymi komputerami) z wykorzystaniem tej
samej autoryzacji, którą oferuje OpenSSH. Oczywiście SCP
zapewnia również takie samo bezpieczeństwo komunikacji,
jak OpenSSH.

Podstawowe wywołanie programu SCP jest bardzo

proste:

scp plik_źródłowy plik_docelowy

. Zarówno

plik_źródłowy, jak i plik_docelowy, mogą być podawane
w jednej z postaci:

• nazwa_pliku (np. plik.txt);
• host:nazwa_pliku (np. 192.168.0.1:/home/gerard/plik

.txt);

• użytkownik@host:nazwa_pliku

(np. gerard@192.168.0.1:/home/gerard/plik.txt).

W drugim przypadku jako nazwa użytkownika na zdalnej
maszynie domyślnie jest przyjmowana nazwa użytkowni-
ka, który wydał polecenie

scp

. Jeśli więc chcemy skopio-

wać jakiś plik ze zdalnego serwera, możemy skorzystać
z polecenia

scp gerard @192.168.0.5:/etc/passwd .

. Zosta-

niemy wtedy zapytani o hasło użytkownika gerard,
a po jego poprawnym podaniu do bieżącego katalogu na
naszym lokalnym komputerze zostanie skopiowany plik
/etc/passwd z komputera o adresie 192.168.0.5.

W wywołaniu programu SCP możemy podać kilka

dodatkowych opcji, np. może przydać się opcja -r,
odpowiadająca za rekursywne pobieranie podkatalogów.
Polecenie

scp -r ~/drzewo/ gerard @192.168.0.5:las/

spo-

woduje, że podkatalog drzewo/ znajdujący się w naszym
katalogu domowym zostanie skopiowany wraz z całą
zawartością do podkatalogu las/ znajdującego się w kata-
logu domowym użytkownika gerard na komputerze
o adresie 192.168.0.5.

Niektóre pozostałe opcje są wymienione w ramce

Wybrane opcje SCP.

FTP też może być bezpieczne

Kopiowanie plików z użyciem SCP jest bezpieczne, ale
często niezbyt wygodne. Wielu użytkowników jest przy-
zwyczajonych do korzystania z FTP, które jednak przesyła
hasła i dane niezabezpieczonym kanałem. W pakiecie

Wybrane opcje SCP:

• -a – włącza wyświetlanie statystyk dla każdego pliku;
• -A – wyłącza wyświetlanie statystyk dla każdego pliku;
• -B – włącza tryb wsadowy (nie pyta o hasła i frazy kodują-

ce);

• -C – włącza kompresję;
• -i nazwa_pliku – wskazuje, który plik z kluczem prywatnym

ma być wykorzystany do autoryzacji;

• -l liczba – ogranicza szybkość przesyłania danych do

liczba kilobitów na sekundę;

• -o opcje – pozwala przekazać dodatkowe opcje do progra-

mu OpenSSH;

• -p – chroni czasy modyfikacji, dostępu i prawa oryginalne-

go pliku;

• -q – wyłącza wyświetlanie statystyk;
• -Q – włącza wyświetlanie statystyk;
• -r – kopiuje rekursywnie całe katalogi;
• -S ścieżka_dostępu – wskazuje umiejscowienie programu

OpenSSH;

• -v – drukuje dodatkowe komunikaty (przydatne podczas

rozwiązywania problemów).

styczeń 2004

50

dla początkujących

OpenSSH mamy do dyspozycji bezpieczny odpowiednik
FTP. Jest to program SFTP. W najprostszej postaci urucha-
miamy go poleceniem:

sftp uż[e-mail]

Po podaniu hasła mamy do dyspozycji interfejs zbliżony
do tego znanego z FTP. Po wpisaniu

help

uzyskujemy spis

dostępnych komend. Nie różnią się one w zasadzie od
komend znanych z powłoki.

SFTP możemy również wykorzystać w sposób podobny

jak SCP do pobrania jednego lub kilku plików (bez wcho-
dzenia w tryb interaktywny):

sftp [e-mail]:nazwa_pliku

Istotne dla działania SFTP jest, aby w konfiguracji zdalnego
serwera OpenSSH (w pliku /etc/sshd_config) znajdowała się
linia o treści:

Subsystem sftp /usr/libexec/openssh/sftp-server

W domyślnej konfiguracji linia ta jest obecna.

Tworzenie tuneli

Na początku artykułu (w rozdziale Sposób użycia) wspo-
mniałem, że znajomy zrobił sobie tunel ze swojego kom-
putera do mojego serwera, dzięki czemu mógł swobodnie
korzystać z IRC-a. Teraz nadszedł czas, aby wyjaśnić
dokładniej, na czym to polega, i jak można zrobić to
samemu.

Program OpenSSH pozwala na wykorzystanie opcji

-L port_lokalny:host:port_hosta. Powoduje ona, że pomię-
dzy portem port_lokalny na naszym komputerze a zdal-
nym komputerem zostanie utworzony szyfrowany tunel.
W przypadku połączenia się z portem port_lokalny pakie-
ty będą wędrować przez ten tunel, a następnie z kompu-

tera zdalnego będą przesyłane (już nie szyfrowane) do
komputera host na port port_hosta.

Zabezpieczenie poczty

No dobrze, ale co nam to daje? Wiele usług nadal nie jest
szyfrowanych. Wyobraźmy sobie sytuację, gdy pracujemy
w dużej firmie. Firma ta posiada własny serwer SSH oraz
serwer poczty znajdujące się w jednej sieci lokalnej (oba
są dostępne z Internetu). Jeśli chcemy sprawdzić pocztę
firmową z komputera domowego, przy standardowej kon-
figuracji łączylibyśmy się programem pocztowym prosto
na port 110 (POP3) serwera pocztowego. W takim przy-
padku narażamy się na to, że ktoś podsłucha naszą trans-
misję i zdobędzie nasze hasło lub jakieś tajemnice firmy.
Lepiej będzie, gdy korzystając z OpenSSH utworzymy
zabezpieczony tunel od naszego komputera do serwera
SSH firmy i wykorzystamy go do komunikacji z serwerem
poczty. Dzięki temu transmisja będzie niezabezpieczona
tylko na odcinku od serwera SSH do serwera poczty,
a przecież oba znajdują się w sieci firmowej, co znacznie
zmniejsza ryzyko podsłuchu.

Spróbujmy zbudować taki tunel. Odpowiednim do tego

poleceniem będzie:

ssh -N -f -L 11234:adres.serwera.poczty:110

S

uż[e-mail]

Teraz zostaniemy zapytani o hasło na konto użytkownik
na serwerze adres.serwera.ssh. Po jego podaniu program
OpenSSH zostanie przeniesiony w tło (dzięki opcji -f ).
Gdybyśmy nie dodali opcji -N, to oprócz stworzenia tunelu
zalogowalibyśmy się na zdalnym serwerze SSH. Tunel
istniałby wtedy tylko do czasu naszego wylogowania się.
Ponieważ zależy nam przede wszystkim na tunelu, więc
używamy opcji -N.

Pozostaje nam skonfigurować program pocztowy tak,

aby nie łączył się z komputerem adres.serwera.poczty na
porcie 110, lecz z komputerem localhost (a więc naszym
własnym) na porcie 11234.

Powyższa metoda sprawdza się jeszcze lepiej, gdy serwer

SSH i serwer poczty są uruchomione na jednym komputerze.
Wówczas wywołanie programu przyjmuje postać:

ssh -N -f -L 11234:localhost:110

S

uż[e-mail]

Nie powinien nas zmylić napis localhost w opcji -L. Odnosi
się on do zdalnego serwera SSH, a nie do naszego komputera
lokalnego. W powyższym przypadku tunel zapewnia nam
szyfrowanie transmisji przez całą drogę, gdyż na ostatnim
etapie transmisja odbywa się w obrębie jednego komputera.

Gdy nie wolno IRCować

Do czego mogą się nam jeszcze przydać tunele? Przypuść-
my, że nasz komputer znajduje się w sieci lokalnej oddzie-

Rysunek 5.

Przez tunel możemy przesłać praktycznie wszystko,

wliczając w to strony WWW czy muzykę z radia internetowego

51

www.linux.com.pl

openssh

lonej od Internetu zaporą ogniową (firewall). Administrator
tej zapory z pewnych względów (przykładowo z polecenia
szefa) zablokował część portów i pozostawił tylko wybrane.
Na szczęście połączenia przez SSH są dozwolone (no bo
przecież jakoś trzeba pracować).

Jeśli w czasie przerwy w pracy zamiast jeść drugie śnia-

danie wolimy porozmawiać na IRC-u ze znajomą, musimy
sobie jakoś poradzić. Pomogą nam oczywiście tunele.
Warunkiem jest, że mamy konto na zdalnym komputerze
(umieszczonym poza naszą siecią lokalną), udostępniają-
cym serwer SSH.

Polecenie tworzące tunel już znamy:

ssh -N -f -L 6669:poznan.irc.pl:6667

S

uż[e-mail]

Po podaniu hasła możemy uruchomić sobie IRC-a i połą-
czyć się z portem 6669 serwera localhost. Nasze połączenie
zostanie przekazane zabezpieczonym tunelem do zdalnego
serwera SSH, a stamtąd przekierowane na port 6667 serwe-
ra poznan.irc.pl. Z punktu widzenia serwera poznan.irc.pl
(a więc i innych uczestników rozmowy na IRC-u) będzie
się wydawało, że nasz program Irc jest uruchomiony na
komputerze zdalny.serwer.ssh.

Zakończenie

Bezpieczeństwo w Sieci jest obecnie sprawą kluczową.
Nawet w takim oprogramowaniu jak OpenSSH zdarzają
się dziury, więc należy pamiętać o częstej aktualizacji
najważniejszych pakietów oraz obserwowaniu ogłoszeń
o krytycznych błędach. Należy też zdawać sobie sprawę,
że nawet najlepsze oprogramowanie może nas nie uchro-
nić przed atakami, gdyż zwykle najsłabszym ogniwem
jest człowiek. Jeśli ustawimy łatwe do odgadnięcia hasło,
to nikt go nie będzie musiał podsłuchiwać – po prostu je
wpisze.

W Sieci:

• Strona domowa OpenSSH:

http://www.openssh.org/

• Polski serwer lustrzany powyższej strony:

http://predict.chem.uw.edu.pl/openssh/

• Pliki rpm na polskim serwerze FTP:

ftp://sunsite.icm.edu.pl/pub/OpenBSD/OpenSSH/

portable/rpm/RH90

• Źródłowe pakiety rpm na polskim serwerze FTP:

ftp://sunsite.icm.edu.pl/pub/OpenBSD/OpenSSH/

portable/rpm/SRPMS

• Strona domowa PuTTY:

http://www.chiark.greenend.org.uk/~sgtatham/putty/

• Strona domowa WinSCP:

http://winscp.sourceforge.net/eng/

• Trochę teorii kryptografii:

http://www.bezpieczenstwoit.pl/Kryptografia.html