plik

styczeń 2004

dla początkujących

Praca z OpenSSH

Piotr Machej

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: autorzy@linux.com.pl.

Rysunek 1.

Na głównej stronie projektu OpenSSH możemy

sprawdzić najnowszy numer wersji

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

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

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

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

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

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

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

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żytkownik@adres.serwera

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

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żytkownik@adres.serwera

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

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

dla początkujących

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

sftp użytkownik@zdalny.serwer.ssh

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 uzytkownik@zdalny.serwer.ssh: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

użytkownik@adres.serwera.ssh

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

użytkownik@adres.serwera.ssh.i.poczty

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

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

użytkownik@zdalny.serwer.ssh

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