plik

Rozwiązania

Zabawa w SSHowanego

styczeń 2010

Rozwiązania

Zabawa w SSHowanego

www.lpmagazine.org

lin

ftw

Zabawa

w SSHowanego

W czasach gdy niemal każdy komputer podłączony jest do sieci, czy to niewielkiej domowej
lub osiedlowej, czy też do Internetu niesłychanie ważnym zagadnieniem staje się zapewnienie
bezpieczeństwa komunikacji między stacjami roboczymi. Protokół SSH, dzięki silnej ochronie
kryptograficznej, znakomicie się do tego nadaje. Artykuł ma na celu przybliżenie czytelnikowi
szerokich możliwości oferowanych przez SSH również w mniej znanych zastosowaniach takich jak
przekierowanie portów i tworzenie tuneli.

Wojciech Terlikowski

SSH zetknął się chyba każdy, kto pracował z
systemami linuksowymi. Bezpieczna powło-
ka (secure shell) towarzyszy większości ad-
ministratorów w wykonywaniu codziennych

obowiązków, jest również niezastąpiona dla wielu użyt-
kowników wszędzie tam, gdzie szybko i sprawnie trzeba
wykonać jakieś czynności na zdalnym systemie, a jedno-
cześnie mieć poczucie bezpieczeństwa jakie daje szyfro-
wany protokół.

Szyfrowany telnet

Kiedy po raz pierwszy miałem okazję korzystać z zaso-
bów Internetu, jeszcze w latach dziewięćdziesiątych ubie-
głego stulecia, do zalogowania się na zdalne serwery uży-
wałem telnetu.

Jest to proste narzędzie, pozwalające na otwarcie sesji

na innym komputerze w sieci. Połączenie do serwera tel-
netu umożliwia wykonywanie poleceń na zdalnym syste-
mie. Rozwiązanie to ma jednak wadę, która zadecydowała
o jego niemal całkowitym zaniku, przynajmniej w środowi-
skach uniksowych i uniksopodobnych, w tym w Linuksie.
Słabością, która zadecydowała o wyparciu telnetu między

innymi przez SSH jest brak szyfrowania transmisji, szcze-
gólnie dotkliwy podczas procesu uwierzytelniania.

Taka luka bezpieczeństwa pozwala na podsłuchanie se-

sji i zdobycie informacji nie tylko o tym jakie polecenia wy-
konujemy na zdalnym systemie, ale również poznanie na-
szego loginu i hasła, co może w konsekwencji prowadzić do
przejęcia kontroli nad naszym kontem. Przeprowadzenie ta-
kiego ataku nie wymaga głębokiej wiedzy ani bardzo skom-
plikowanych narzędzi. Wystarczy prosty program podsłu-
chujący ruch w sieci (sniffer) jakich wiele bezpłatnych moż-
na znaleźć w Internecie. Używanie telnetu było do zaakcep-
towania w sieciach, których użytkownicy mieli do siebie du-
żo zaufania i nie obawiali się, że ktoś będzie chciał się wła-
mać do ich komputera. Pamiętam, że jeszcze na początku
studiów do niektórych serwerów wydziałowych mieliśmy
dostęp przez telnet, ale z czasem był on zastępowany przez
SSH. Wówczas była to jeszcze nowość, ale dająca więcej
bezpieczeństwa, bo szyfrowana.

Trochę historii

Protokół SSH został opracowany w połowie lat dziewięć-
dziesiątych na Politechnice w Helsinkach przez jednego z

Rozwiązania

Zabawa w SSHowanego

styczeń 2010

Rozwiązania

Zabawa w SSHowanego

www.lpmagazine.org

pracowników naukowych – Tatu Ylönena jako
odpowiedź na atak, polegający na podsłuchaniu
i przechwyceniu haseł przesyłanych przez pro-
tokoły nieszyfrowane. Celem projektu było za-
stąpienie narzędzi takich jak telent, rlogin i rsh
przez  rozwiązania  podobne,  ale  zapewniające
wyższy  stopień  bezpieczeństwa  dzięki  ochro-
nie kryptograficznej. Po piętnastu latach może-
my powiedzieć, że niewielu linuksowym admi-
nistratorom  zdarza  się  wykorzystywać  rlogin,
czy rsh

są pewnie i tacy, którzy nie wiedzą,

że coś takiego istniało, natomiast niemal wszy-
scy znają SSH.

Kilka lat po opracowaniu pierwszej wer-

sji protokołu powstała, najpopularniejsza
obecnie, implementacja zarówno serwera jak
i klienta – OpenSSH. Projekt ten jest rozwi-
jany przez zespół OpenBSD na licencji BSD.
Wolna licencja jak również bogactwo możli-
wości jakie daje OpenSSH

pozostając w peł-

nej  zgodności  ze  specyfikacją  protokołu,  za-
pewniły  tej  implementacji  dużą  popularność.
Obecnie OpenSSH jest wykorzystywane przez
wiele systemów operacyjnych jak Sun Solaris,
Mac OS X, BSD, Novell Netware, IBM AIX,
HP  UX,  urządzenia  sieciowe  Cisco,  Juniper,
HP, Dell, Alcatel oraz niemal wszystkie dys-
trybucje Linuksa.

Niedawno ukazała się nowa wersja

OpenSSH 5.3. Chociaż nie wnosi ona znacz-
nych zmian do programu, to ma znaczenie hi-
storyczne, ponieważ została wydana dziesięć
lat po powstaniu projektu i publikacji pierw-
szej wersji produktu.

Zabawa się rozpoczyna

Jak wspomniałem, OpenSSH jest dostępne
w repozytoriach niemal każdej dystrybucji Li-
nuksa, więc zainstalowanie go nie stanowi żad-
nego problemu. SSH to program sieciowy dlate-
go do przetestowania go potrzebować będziemy
sieci komputerowej, a w najprostszym przypad-
ku dwóch komputerów. Jeden z nich posłuży za
serwer SSH, nazwijmy go bolek, drugi to kom-
puter biurkowy – lolek, na którym zainstalujemy
klienta SSH. Z tej maszyny będziemy się logo-
wać do bolka. Oba komputery pracują pod kon-
trolą dystrybucji Debian GNU/Linux dlatego by
zainstalować serwer OpenSSH należy wykonać
na

bolku

jas@bolek$ sudo aptitude install
openssh-server

natomiast na

lolku

instalujemy klienta pole-

ceniem:

jan@lolek$ sudo aptitude install
openssh-client

Podczas instalacji serwera warto zwrócić uwa-
gę na moment przedstawiony na Rysunku 2

Metody generowania kluczy i kryptografia

asymetryczna mogą być temetem osobnego arty-
kułu, tu skupię się na kwestiach najistotniejszych
dla użytkownika. Przede wszystkim, klucz pry-
watny jest tajny i może być znany tylko właści-
cielowi, w tym wypadku serwerowi SSH. Klucz
publiczny jest jawny, ale stanowi parę do prywat-
nego i dlatego oba muszą być wygenerowane ra-
zem. W związku z tym klucze nie mogą być do-
starczane z pakietem oprogramowania, jak na
przykład plik z domyślną konfiguracją, ale trze-
ba je wygenerować każdorazowo podczas insta-
lacji programu. Ponowna instalacja OpenSSH,
związana np. ze zmianą dystrybucji, spowoduje,
że powstanie nowa para kluczy. Spowoduje to,
że odciski palca (fingerprints) serwera zapamię-
tane przez klientów staną się niekatulane i będzie
je trzeba zaktualizować.

Po pomyślnie zakończonej instala-

cji przystępujemy do konfiguracji serwera

OpenSSH.  Będziemy  modyfikować  prosty,
tekstowy  plik  z  konfiguracją:  /etc/ssh/sshd_
config. Bezpieczeństwo wymaga, aby serwer
używał protokołu w wersji drugiej (SSH-2).
Zapewnia to wpis Protocol 2. W pierwotnej
specyfikacji  wykryto  poważne  luki  bezpie-
czeństwa,  dlatego  została  zastąpiona  przez
SSH-2. Wersja druga nie tylko jest bezpiecz-
niejsza  od  SSH-1,  ale  dodaje  do  protoko-
łu  nowe  możliwości.    Wspierają  ją  wszyst-
kie  współczesne  klienty  SSH.  Obie  wersje
nie są ze sobą kompatybilne i czasami trzeba
w  kliencie  wymusić  użycie  SSH-1  jeśli  bę-
dziemy chcieli połączyć się z serwerem, któ-
ry  nie  wspiera  SSH-2.  Na  szczęście  takich
serwerów jest coraz mniej.

Drugą opcją konfiguracyjną, którą zmieni-

myna serwerze jest wyłączenie możliwości lo-
gowania na konto roota. W tym celu wystarczy
wpis

PermitRootLogin no

. W dalszym ciągu

możemy wykonywać czynności administra-
cyjne logując się przez SSH na konto zwykłe-

Rysunek 1.

Popularność różnych implementacji ssh od czasu pojawienia się OpenSSH. Wyraźnie widać,

że OpenSSH z ponad 80% udziałem jest zdecydowanie najczęściej używaną implementacją. Źródło: [3]

Rysunek 2.

Instalacja serwera OpenSSH. Widoczny moment generowania kluczy kryptograficznych

styczeń 2010

Rozwiązania

Zabawa w SSHowanego

www.lpmagazine.org

Rozwiązania

Zabawa w SSHowanego

go użytkownika, a następnie uzyskując upraw-
nienia roota poprzez skorzystanie z polecenia

su -

lub odpowiednio skonfigurowanego pa-

kietu sudo. Takie ograniczenie wydaje się nie-
potrzebnym utrudnieniem dla użytkowników
sieci lokalnych, ale jest bezwzględnie zaleca-
ne jeżeli serwer ma być dostępny z Interne-
tu. Potwierdzają to moje własne doświadcze-
nia. Zdarzyło mi się, że w kilka minut po pod-
łączeniu nowego serwera do Internetu znala-
złem w dzienniku systemowym ślady dziesią-
tek nieudanych prób zalogowania przez SSH
na konto roota podejmowanych przez kompu-
tery z całego świata. Gdybym nie zablokował

tej możliwości, przypuszczalnie musiałbym
odłączyć komputer od Sieci i zacząć usuwać
skutki włamania.

Po takich zmianach ustawień należy zre-

startować usługę ssh:

jas@bolek$ sudo /etc/init.d/ssh
restart

Domyślna konfiguracja klienta jest wystarcza-
jąca, ale w razie potrzeby można ją zmienić
modyfikując plik /etc/ssh/ssh_config na kom-
puterze lolek. Podobnie jak na serwerze jest to
prosty plik tekstowy.

Teraz możemy połączyć się przez lolka

z serwerem SSH bolek. Robimy to wydając
polecenie:

jan@lolek$ ssh jas@bolek

lub:

jan@lolek$ ssh bolek -l jas

gdzie

bolek

jest serwerem, na który się loguje-

my, natomiast

jas

to identyfikator użytkowni-

ka na tym serwerze. Zamiast nazwy komputera
(hostname) można podać jego adres IP lub peł-
ną nazwę domenową np. bolek.example.com,
co jest konieczne gdy komputer znajduje się
w Internecie w zupełnie innej domenie niż na-
sza. Jeśli na obu systemach używamy tego sa-
mego loginu można go nie podawać przy na-
wiązaniu połączenia, wtedy SSH zaloguje nas
na konto o takiej samej nazwie jak lokalne.

Jeśli pierwszy raz łączymy się do serwe-

ra, SSH wyświetli odcisk palca (patrz rys. 3)
i zapyta czy na pewno na tej maszynie chce-
my otworzyć sesję. Po potwierdzeniu tożsa-
mości serwera zostaniemy zapytani o hasło na
komputerze

bolek

, a jego odcisk palca zosta-

nie zapisany w pliku ~/.ssh/known_hosts. Od
tej pory, jeśli serwer zmieni odcisk zostanie-
my  o  tym  poinformowani  przy  próbie  logo-
wania (patrz Rysunek 3). Sytuacja taka nastę-
puje gdy serwer został zastąpiony nową ma-
szyną, lub gdy nastąpiła reinstalacja systemu,
w  tym  pakietu  OpenSSH.  Zazwyczaj  admi-
nistratorzy  powiadomią  nas  wcześniej  o  ta-
kim zdarzeniu. Jeśli mamy pewność, że odcisk
faktycznie się zmienił i łączymy się z właści-
wym komputerem należy usunąć linijkę z pli-
ku ~/.ssh/known_hosts o numerze podanym w
komunikacie. W naszym przypadku jest to li-
nia numer 7. Przy kolejnej próbie logowania
zostaniemy  poproszeni  o  akceptację  odcisku
palca nowego klucza.

Po poprawnym zalogowaniu możemy

pracować na serwerze bolek, wydając pole-
cenia jakbyśmy mieli otwartą lokalną konso-
lę. Sesję kończymy komendą

exit

lub skró-

tem klawiszowym [Ctrl+D] tak samo jak
w przypadku pracy lokalnej.

Czy używanie ssh jest równie wygodne

jak praca lokalna? A co z aplikacjami graficz-
nymi? Spróbujmy uruchomić grę Kmahjongg.

Niestety, próba zakończy się wyświetle-

niem komunikatu błędu cannot connect to X se-
rver, co oznacza , że serwer X nie znalazł odpo-
wiedniego miejsca do wyświetlenia graficznego
okienka gry. Nie wyświetli go w tekstowej kon-
soli, w której działa ssh, może jednak wykorzy-
stać do tego graficzny pulpit komputera

lolek

Rysunek 3.

Połączenie do SSH po zmianie odcisku palca. Po usunięciu wpisu z ~/.ssh/known_hosts znów

jesteśmy proszeni o potwierdzenie tożsamości serwera

Rysunek 4.

Przykład zastosowania ssh do tunelowania X11. Gra Kmahjongg uruchomiona na zdalnym

serwerze

styczeń 2010

Rozwiązania

Zabawa w SSHowanego

www.lpmagazine.org

Rozwiązania

Zabawa w SSHowanego

Taki efekt można osiągnąć przez odpowiednią
konfigurację X11, tak by programy uruchamia-
ne na bolku były wyświetlane na ekranie lolka.
Można również wykorzystać do tego SSH. Pro-
tokół ten, daje możliwość przekierowania X11
(X11 forwarding), z której skorzystamy. Wy-
starczy rozpocząć nową sesję SSH dodając
przy uruchamianiu przełącznik

-X

jan@lolek$ ssh -X bolek -l jas

Operacja  taka  ustawia  przekierowanie  X11
na  klienta  SSH  i  sprawia,  że  programy  gra-
ficzne  działające  na  bolku  będą  wyświetla-
ły  swe  okna  na  lolku.  Starujemy  ponownie

kmahjongg

jas@bolek$ kmahjongg &

Dodanie znaku

, powoduje uruchomienie

gry w tle, tak by nie blokować dostępu do
konsoli na

bolku

. Po chwili na ekranie kom-

putera

lolek

pojawi się się okienko Kmah-

jongg. Inną opcją, pozwalającą na przekiero-
wanie X11 jest

-Y

, tak zwane zaufane prze-

kierowanie X (trusted X forwarding). Jest
ono mniej bezpieczne, ponieważ nie spełnia
wszystkich standardów bezpieczeństwa na-

kładanych  przez  protokół  X,  czasem  użycie
tej opcji może okazać się konieczne. Jeśli za-
chodzi potrzeba uruchomienia wielu progra-
mów graficznych na zdalnym komputerze, to
wartym rozważenia rozwiązaniem jest VLC.
Za jego pomocą można udostępnić cały gra-
ficzny pulpit klientowi usługi. W wielu przy-
padkach  może  to  okazać  się  wygodniejsze
i  bardziej  efektywne  od  zastosowania  prze-
kierowania X. SSH jest wciąż bardzo popu-
larną i często jedyną tego typu usługą dostęp-
ną na serwerze.

Nie tylko zdalna sesja

Poznaliśmy  już  możliwości  protokołu  SSH
związane  z  pracą  na  zdalnym  systemie,  ale
co zrobić gdy chcemy przenieść pliki z jedne-
go komputera na drugi? W przypadku plików
tekstowych  można  je  skopiować  do  schow-
ka  i  wkleić  do  edytora  otwartego  na  zdal-
nym  komputerze.  Może  to  być  nawet  wy-
godne  dopóki  nie  pojawi  się  konieczność
kopiowania  dużych  plików,  lub  zbiorów  bi-
narnych. Rodzina protokołów RSH miała w
tym  celu  RCP,  którego  używało  się  podob-
nie jak zwykłego kopiowania plików polece-
niem

cp.

Ponadto istnieje protokół FTP, słu-

żący do transferowania plików między kom-
puterami w sieci, jednak żaden z nich nie szy-
fruje transmisji. Na szczęście w rodzinie pro-
tokołów SSH znalazły się ich odpowiedniki:
SCP – bezpieczne kopiowanie (secure copy)
i SFTP – bezpieczny protokół transferu pli-
ków (secure file transfer protocol). Tego dru-
giego nie należy mylić z FTPS – rozszerze-
niem FTP. Zarówno SCP jak i SFTP są szy-
frowane i zapewniają takie samo bezpieczeń-
stwo  transmisji  jak  SSH.  Oba  są  dostarcza-
ne  z  OpenSSH,  więc  żeby  z  nich  korzystać
nie  musimy  niczego  instalować  dodatkowo.

Polecenia

scp

używamy podobnie jak zwy-

kłego

jan@lolek$ scp jas.jpeg jas@bolek:
/tmp/

Jak widać na przykładzie różnicą jest człon

ja-

s@bolek:

wskazujący, że kopiowanie ma odby-

wać się do katalogu na serwerze bolek z upraw-
nieniami użytkownika

jas

. Należy zwrócić

uwagę na dwukropek (

) rozdzielający część

sieciową od ścieżki w systemie plików. Je-
śli chcemy skopiować plik w przeciwną stronę
z serwera bolek na komputer

lolek

, robimy to

poleceniem:

jan@lolek$ scp jas@bolek:/tmp/
obraz.png ./obrazek.png

Spowoduje to skopiowanie pliku /tmp/
obraz.png do bieżącego katalogu i nadanie mu
nazwy obraz.png. Jedną z bardziej użytecz-
nych opcji używanych z

scp

jest

-r

. Pozwala

ona na rekurencyjne skopiowanie całego kata-
logu wraz z zawartością. Polecenie:

jan@lolek$ scp -r jas@bolek:/etc/ ./

skopiuje całą zawartość katalogu /etc na ser-
werze bolek do bieżącego katalogu. Składnia

scp

dopuszcza również użycie znaków spe-

cjalnych powłoki np.:

jan@lolek$ scp jas@bolek:~/zdjecia/
*.jpeg ~/

skopiuje wszystkie pliki o rozszerzeniu jpeg
(*.jpeg) z katalogu zdjecia do katalogu domo-
wego lokalnego użytkownika. Symbole wystę-
pujące w ścieżkach serwera są interpretowane

Rysunek 5.

Okno programu gftp z otwartą sesją SSH

Listing 1.

Przykładowy skrypt zmieniający konfi-

gurację wielu serwerów za pomocą SSH

for

SERVER in bolek reksio uszatek

koralgol

ssh jas@

$SERVER

'echo

nameserver 10.12.15.254 > /etc/
resolv.conf'

done

Listing 2.

Generowanie kluczy kryptograficz-

nych wykorzystywanych do autoryzacji w SSH

jan@lolek

ssh-keygen

Generating public/private rsa key
pair.
Enter file in which to save the key
(/home/jan/.ssh/id_rsa):
Created directory

'/home/jan/

.ssh'

Enter passphrase (empty

for

passphrase):
Enter same passphrase again:
Your identification has been saved
in /home/jan/.ssh/id_rsa.
Your public key has been saved in
/home/jan/.ssh/id_rsa.pub.
The key fingerprint is:
2d:4f:15:7b:60:51:66:ac:5b:90:32:
58:83:a1:b4:28 jas@lolek

styczeń 2010

Rozwiązania

Zabawa w SSHowanego

www.lpmagazine.org

Rozwiązania

Zabawa w SSHowanego

przez jego powłokę nie przez

scp

. W wyniku

czego skrypt, korzystający z takich symboli bę-
dzie działał różnie z różnymi maszynami w za-
leżności od tego jaki system pracuje po stronie
serwera i jakiej powłoki używa. Takiego uza-
leżnienia od platformy nie ma drugi z wymie-
nionych protokołów służących do kopiowania
plików. SFTP, bo o nim mowa, pozwala na in-
teraktywną pracę na zdalnym systemie plików
podobnie jak FTP. Logujemy się poleceniem:

jan@lolek$ sftp jas@bolek

a następnie za pomocą poleceń takich jak

get

put

możemy kopiować pliki z i na serwer. Jeśli

ktoś preferuje pracę w środowisku graficznym
to może skorzystać z jednej z wielu graficznych
nakładek na SFTP takich jak

gftp

czy

WinSCP

Użycie SSH w skryptach

W pracy administratora (i nie tylko) bardzo li-
czy się umiejętność automatyzacji zadań. Je-

śli uda się napisać skrypt, który wykona za nas
chociaż część żmudnej pracy to zaoszczędzo-
ny czas możemy poświęcić na przyjemniejsze
zajęcia, na przykład czytanie ostatniego nume-
ru Linux+. Przypuśćmy, że administrujemy
siecią, w której właśnie zmienił się adres ser-
wera DNS. Nowy adres to 10.12.15.254. Mu-
simy teraz zmienić konfigurację wszystkich
serwerów w sieci, modyfikując zawartość pli-
ku /etc/resolv.conf. Jeśli są to trzy serwery to
można zalogować się na każdy z nich osobno i
ręcznie wykonać polecenie:

echo 'nameserver 10.12.15.254' >
/etc/resolv.conf

Kiedy będzie ich kilkadziesiąt to zadanie takie
staje się żmudne i czasochłonne. Ponadto nie
trudno tu o pomyłkę. Z pomocą w takiej sy-
tuacji przychodzi nam SSH. Pozwala ono na
wykonanie polecenia w trybie wsadowym, bez
otwierania interaktywnej sesji, a po zakończe-

niu powraca do powłoki klienta, z której zosta-
ło wywołane.

jan@lolek$ ssh jas@bolek 'echo
nameserver 10.12.15.254 > /etc/
resolv.conf'

Takie polecenie powoduje wywołanie komendy

echo

na serwerze

bolek

z przekierowaniem wyj-

ścia do pliku /etc/resolv.conf na tymże serwerze,
a następnie powrót do powłoki na

lolku

. W re-

zultacie zawartość pliku /etc/resolv.conf zostanie
zmieniona na

nameserver 10.12.15.254

, czy-

li to co chcieliśmy osiągnąć. Teraz wystarczy wy-
wołać skrypt dla każdego z naszych serwerów i
rekonfiguracja gotowa.

Bardzo wygodne, prawda? Jednak skrypt

nie  działa  tak  sprawnie  jak  byśmy  sobie  tego
życzyli,  ponieważ  przy  logowaniu  do  każde-
go  z  serwerów  trzeba  podawać  hasło.  I  na  to
jest  rada.  Uwierzytelnienie  przez  podanie  ha-
sła  nie  jest  jedyną  możliwością  w  SSH.  Ist-
nieje  wariant  logowania  przez  klucz  publicz-
ny  (public  key)  oraz  za  pomocą  GSSAPI. To
ostatnie  pozwala  na  zarządzanie  autoryzacją
w  SSH  za  pośrednictwem  zewnętrznych  me-
chanizmów,  takich  jak  Kerberos.  Skupmy  się
na metodzie klucza publicznego, ponieważ jest
prosta i nie wymaga od nas używania dodatko-
wego oprogramowania. Najpierw musimy mieć
parę kluczy, która będzie identyfikować nasze-
go klienta, czyli użytkownika

jan

na kompute-

rze

lolek

, logującego się na konto jaś na kom-

puter

bolek

. Do generowania kluczy użyjemy

programu

ssh-keygen

dostarczanego razem

z OpenSSH. Hasło (paraphrase) do klucza po-
zostawiamy puste.

Następnie kopiujemy wygenerowany

klucz publiczny do pliku .ssh/authorized_keys
w katalogu domowym użytkownika, na które-
go będziemy się logować na serwerze

bolek

jan@lolek$ ssh jas@bolek 'mkdir ~/
.ssh/'
jan@lolek$ scp ~/.ssh/id_rsa.pub
jas@bolek:~/.ssh/authorized_keys

Przy wykonywaniu polecenia

scp

po raz ostat-

ni podajemy hasło. Następne logowanie do

bolka

będzie możliwe już bez hasła. Dzię-

ki temu możemy wykonać skrypt sprawniej,
gdyż nie będzie wymagał od nas ingerencji
i podawania haseł.

Bardzo pomocne przy administrowaniu

komputerem,  są  potoki  (pipes).  Dzięki  nim
możemy  łączyć  możliwości  wielu  niedużych
programów  jak  na  przykład  cat,  grep  czy  wc
w skomplikowane narzędzia. W SSH również
nie mogło zabraknąć obsługi potoków. Załóż-

Rysunek 7.

Konfiguracja Firefoksa do użycia serwera pośredniczącego

Rysunek 6.

Zastosowanie odwrotnego tunelu SSH do połączenia do serwera znajdującego się za zapo-

rą ogniową

��

styczeń 2010

Rozwiązania

Zabawa w SSHowanego

www.lpmagazine.org

Rozwiązania

Zabawa w SSHowanego

my, że uruchamiamy program i chcemy, by
wszystkie jego krytyczne komunikaty (zaczy-
nające się od

ERROR:

) były zapisywane na zdal-

nym serwerze. Rejestrowanie zdarzeń z kry-
tycznych usług na innych komputerach jest do-
brą praktyką bezpieczeństwa. Bardziej zaawan-
sowane konfiguracje można osiągnąć za pomo-
cą demona syslog. W tym momencie wystarczy
nam proste użycie SSH.

jan@lolek$ ./skrypt.sh | grep
'^ERROR:' | ssh jas@bolek 'cat >>
/var/log/skrypt.log'

Przy użyciu potoków łączymy funkcjonalności
programu grep

który wybiera tylko interesują-

ce nas komunikaty ssh, zapewniającego trans-
fer logów na inny serwer i cat

zapisującego je

do pliku logów.

Kopię zapasową serwisu www można wy-

konać poleceniem:

jan@lolek$ tar -czf - /var/www/* |
ssh jas@bolek 'cat > ~/backup/backup_
www.tar.gz'

Alternatywnym rozwiązaniem jest spakowanie
plików lokalnie, a następnie przesłanie paczki
za pomocą SCP. Wersja z użyciem potoku jest
jednak bardziej elegancka i oszczędza nam za-
mieszania z tymczasowym plikiem archiwum.
Istnieje  również  opcja  OpenSSH,  pozwalają-
ca  na  kompresję  przesyłanego  strumienia  da-
nych.  Włącza  się  ją  za  pomocą  przełącznika

-C

. W czasach rozpowszechnienia sieci szero-

kopasmowych nie jest to często używana opcja,
ale niekiedy może usprawnić pracę. Zwłaszcza
wtedy, gdy trzeba będzie przesyłać dobrze kom-
presujące się dane, np. pliki tekstowe, przez sieć
o niedużej przepustowości.

Wchodzimy w tunel

Tunele  sieciowe  są  potężnym  i  bardzo  wygod-
nym narzędziem, dzięki któremu można zabez-
pieczyć transmisję protokołów nieszyfrowanych
oraz ominąć niektóre ograniczenia wprowadzo-
ne przez zapory ogniowe. W SSH tunele realizo-
wane są za pomocą przekierowania portów (port
forwarding). Rozważmy prostą sytuację, w której
dzięki tunelowaniu, uzyskamy bezpieczny dostęp
do nieszyfrowanej usługi pocztowej. Na serwe-
rze wydziałowym mamy konto pocztowe i kon-
to powłoki dostępne przez SSH. Niestety admi-
nistrator udostępnił pocztę tylko przez nieszyfro-
wane protokoły POP3 i SMTP. Jeśli nie chcemy,
aby nasze dane były przesyłane niezabezpieczo-
nym kanałem możemy posłużyć się SSH. Naj-
prostszym  rozwiązaniem  jest  zalogowanie  się
do  powłoki  serwera  i  obsługa  poczty  przez  je-

den  z  zainstalowanym  tam  klientów  konsolo-
wych. Na dłuższą metę okaże się to niezbyt wy-
godne. Uciążliwa będzie na przykład obsługa za-
łączników, wymagająca przesyłania plików mię-
dzy serwerem a komputerem domowym. Do za-
stosowania wygodniejszego rozwiązania, wyko-
rzystującego  przekierowanie  portów  SSH,  po-
trzebna nam będzie podstawowa wiedza na te-
mat  konfiguracji  protokołów  pocztowych.  Wy-
starczy wiedzieć, na którym porcie słucha tune-
lowana usługa. Najprostszym źródłem informa-
cji na ten temat jest plik /etc/services. Można do-
wiedzieć się z niego, że protokołowi POP3 odpo-
wiada port 110, zaś SMTP – 25. W przykładach
z tunelami połączenia SSH będą nawiązywane w
obie strony – również do naszego komputera do-
mowego, więc przyda się zainstalowanie na nim
serwera OpenSSH.

Polecenie pozwalające na zabezpiecze-

nie transmisji SMTP będzie wyglądało na-
stępująco:

jan@lolek$ ssh jas@poczta.naszauczeln
ia.edu.pl -L 8025:localhost:25

Składnia komendy jest trochę skomplikowana.
Pierwsza część

ssh

jas@poczta.naszauczel-

nia.edu.pl jest już znana. Opcja

-L

oznacza, że

SSH będzie nasłuchiwać na lokalnym porcie o
numerze 8025 i to jest jeden koniec tunelu. Dru-
gi podawany jest po dwukropku w postaci host:
port, w naszym przypadku

localhost:25

. Na-

leży zaznaczyć, że zamiast 8025 można wy-
brać którykolwiek z wolnych portów, jednak do
użycia numerów 1024 i mniejszych trzeba mieć
uprawnienia roota. Kolejną ważną i powodują-
cą prawdopodobnie najwięcej nieporozumień
rzeczą jest nazwa hosta na drugim końcu tune-
lu. Jest ona podawana względem komputera, na

który się logujemy, czyli w tym przypadku local-
host oznacza

poczta.naszauczelnia.edu.pl

W ten sposób zestawiliśmy szyfrowany tunel
z lokalnego portu 8025 do portu 25 na wydzia-
łowym serwerze poczty. Skoro nauczyliśmy się
już tunelowania możemy przekierować drugi
port – ten do odbierania poczty.

jan@lolek$ jas@poczta.naszauczelnia.
edu.pl -L 8025:localhost:25 -L 8100:
localhost:110

Teraz  wystarczy  skonfigurować  ulubionego
klienta poczty i wskazać mu localhost:8025 ja-
ko serwer SMTP do wysyłania poczty, zaś lo-
calhost:8110 do jej odbierania. Dzięki temu mo-
żemy  jednocześnie  cieszyć  się  komfortowym
korzystaniem  z  poczty  i  bezpieczeństwem  ja-
kie daje ochrona kryptograficzna kanału. War-
to przy tym pamiętać, że tunel działa tak dłu-
go jak długo otwarta jest sesja SSH, po zakoń-
czeniu połączenia do localhost:8025 i localhost:
8110 przestaną działać.

Gdy już poznaliśmy podstawy tuneli za-

łóżmy  bardziej  skomplikowaną  sytuację.  We-
wnątrz  sieci  akademickiej  znajduje  się  ser-
wer,  na  którym  wykonujemy  projekt  serwisu
WWW. Mamy dostęp do niego zarówno przez
SSH na standardowym porcie 22 jak i HTTP na
porcie 80, ale tylko z komputerów w sieci wy-
działowej. Co zrobić gdy chcemy popracować
nad projektem siedząc w domu? Możemy za-
logować  się  przez  SSH  na  serwer  pocztowy,
z którego mamy bezpośredni dostęp do kompu-
tera projektowego. Nie jest to jednak zbyt wy-
godne, ponieważ na obu tych serwerach mamy
do dyspozycji wyłącznie przeglądarki tekstowe,
które nie wspierają nowoczesnych technologii
WWW takich jak Java Script czy CSS. Najwy-

Listing 3.

Plik konfiguracyjny tsocks.conf

local

= 192.168.0.0/255.255.255.0

local

= 10.0.0.0/255.0.0.0

server

= 127.0.0.1

server_type

= 5

server_port

= 8080

Listing 4.

Instalacja pakietu tsocks na serwerze w DMZ

jan@firmowy

wget http://ftp.icm.edu.pl/pub/Linux/debian/pool/main/t/

tsocks/tsocks_1.8beta5-9.1_amd64.deb
jan@firmowy

scp tsocks_1.8beta5-9.1_amd64.deb jan@serwerfirmowy:~/

jan@firmowy

ssh jan@serwerfirmowy

jan@serwerfirmowy

su -

jan@serwerfirmowy#

~jan

jan@serwerfirmowy#dpkg -i tsocks_1.8beta5-9.1_amd64.deb

styczeń 2010

Rozwiązania

Zabawa w SSHowanego

www.lpmagazine.org

Rozwiązania

Zabawa w SSHowanego

godniej byłoby użyć lokalnego Firefoksa z Fi-
rebugiem i innymi dodatkami, ale bezpośrednio
na adres serwera projektowego się nie połączy-
my. W takiej sytuacji możemy zestawić tunel
SSH za pomocą polecenia:

jan@lolek$ ssh jas@poczta.naszaucze
lnia.edu.pl -L 9080:projekty:80 -L
9022:projekty:22

Teraz, po wpisaniu adresu

http://localhost:

9080/janek/

przeglądarka wyświetli projekt

strony, nad którym można dalej bez przeszkód
popracować. Dostęp do powłoki serwera pro-
jektowego uzyskujemy przez SSH:

jan@lolek$ ssh localhost -l janek -p
9022

gdzie janek to nazwa naszego użytkownika
na serwerze projektowym, a opcja -p pozwala
otworzyć połączenie na porcie innym niż stan-
dardowy 22, w tym wypadku na 9022.

Czasem zabezpieczenia sieci wydziałowej

są bardziej rygorystyczne i nie pozwalają na
logowanie się na serwer projektowy z serwe-
ra pocztowego. Wtedy, by móc pracować nad
projektem z domu, potrzebny będzie komputer
domowy z serwerem SSH osiągalny z sieci In-
ternet. W czasie pobytu na uczelni musimy do-
stać się do komputera projektowego i otworzyć
z niego sesję SSH na serwerze domowym za
pomocą polecenia.

janek@projekty$ ssh -R 9022:
localhost:22 jan@lolek.mojadomena.pl

Opcja -R oznacza, że zestawiony zostanie tu-
nel odwrotny z

lolka

na serwer projektowy.

Po powrocie do domu można wykorzystać ten
tunel by zalogować się bezpośrednio do kom-
putera projektowego wywołując komendę:

jan@lolek$ ssh localhost -l janek -p
9022

oraz zestawienia drugiego tunelu po por-
tu HTTP.

jan@lolek$ ssh localhost -l janek -p
9022 -L 9080:localhost:80

Znów składnia polecenia staje się nieco skom-
plikowana. Czytelnika może zaniepokoić uży-
cie localhost. Część

ssh localhost -l ja-

nek -P 9022

jest już znana i wbrew pozo-

rom powoduje zalogowanie na serwer projek-
towy mimo, iż używamy adresu

localhost

co sugerowałoby raczej lokalny komputer. Tu-
nel odwrotny łączy port 9022 hosta lokalnego
i port SSH maszyny projektowej, dlatego te-
raz połączenie do localhost:9022 otwiera se-
sję na zdalnym komputerze. Druga część po-
lecenia również jest nam znana: otwiera tunel
z portu 9080 lokalnego komputera na port 80
komputera z którym się łączymy. Tu

local-

host

oznacza serwer projektowy. Podobnego

polecenia użyliśmy przy zabezpieczaniu pro-
tokołów pocztowych.

Bardzo często nasz komputer domowy

nie ma stałego adresu IP i nie można mu wte-
dy przypisać nazwy DNS. W takiej sytuacji na-
leży  skorzystać  z  usługi  dynamicznego  DNS
oferowanego np. przez serwis dyndns.org. Po-
lega ona na przypisaniu komputerowi o zmien-
nym adresie IP stałej nazwy DNS. Dzięki temu
można nawiązać z nim połączenie SSH nawet
jeśli nie wiemy jaki aktualnie ma adres. Sytu-
acja jest bardziej skomplikowana, gdy ani ser-
wer  projektowy  ani  nasz  komputer  domowy
nie są osiągalne z Internetu. Możliwe jest wte-
dy użycie publicznie dostępnego serwera SSH,
np.  jednego  z  serwisów  oferujących  bezpłat-
ne konta na maszynach uniksowych i linukso-
wych [7]. Warto zwrócić uwagę na to czy regu-
lamin serwera nie zabrania używania go w ce-
lu  zestawiania  tuneli  i  proxy. W  wielu  serwi-
sach jest to zabronione, bo powoduje wzmożo-
ny ruch sieciowy.

Skoro wiemy już wiele na temat uzyski-

wania dostępu do zabezpieczonej sieci za po-

mocą przekierowania portów SSH warto roz-
ważyć kilka przypadków jak z podobnie za-
bezpieczonej sieci się wydostać.

Wiele sieci firmowych blokuje dostęp do

niektórych usług, np. wybranych serwerów
WWW, pozostawiając tylko te uznane za nie-
zbędne. Niestety, może to skutecznie utrudnić
pracę i warto poznać sposób na obejście takiego
ograniczenia. Z pomocą przyjdzie serwer SSH
dostępny w Internecie. Najlepiej gdyby była to
maszyna, na której mamy uprawnienia roota,
aby w razie potrzeby móc skonfigurować SSH.
Załóżmy, że administrator sieci firmowej zablo-
kował nasze ulubione serwisy WWW, ale po-
zostawił możliwość logowania się na serwery
SSH. Możemy użyć jednego z takich serwerów
jako pośrednika sieciowego (proxy) i przy je-
go pomocy uzyskać dostęp do zablokowanych
usług. Polecenie:

jan@firmowy$ jas@bolek.mojadomena.pl
-D 8080

otwiera  sesję  na  komputerze  domowym,
a opcja -D sprawia, że będzie on działał jako
serwer  pośredniczący  (proxy)  typu  SOCKS
dynamicznie  tworząc  tunele  do  wybieranych
przez nas adresów. Jeszcze tylko musimy od-
powiednio  skonfigurować  przeglądarkę  usta-
wiając proxy typu SOCKS i podając localhost
jako adres serwera i port 8080 – taki sam jaki
został określony przy wywołaniu SSH. Takie
ustawienia pozwalają na połączenie się z ser-
wisami, które zostały oficjalnie zablokowane
przez administratora sieci, dzięki tunelowaniu
komunikacji przez komputer domowy.

W wielu sieciach ograniczenia nakładane na

ruch sieciowy są większe. Administratorzy unie-
możliwiają połączenia przez SSH blokując port
22 na zaporze ogniowej (firewall). Pozostaje je-
dynie możliwość używania portów 80 (HTTP),
443 (HTTPS) i 8080 (alternatywne HTTP). Na-
leży wtedy serwer SSH skonfigurować tak, aby
pracował na jednym z trzech dozwolonych por-
tów np. na 443. W tym celu dodajemy wpis

Port 443

do pliku konfiguracyjnego demona

OpenSSH /etc/ssh/sshd_config. Po zmianie trze-
ba pamiętać o restarcie usługi

można nawiązać

połączenie z komputera firmowego wpisując:

jan@firmowy$ jas@bolek.mojadomena.pl
-D 8080 -p 443

Nie zmieniając konfiguracji przeglądarki znów
mamy dostęp do zablokowanych serwisów.

Nie jest to jednak rozwiązanie w pełni sa-

tysfakcjonujące. Co prawda Firefox wspiera
obsługę proxy typu SOCKS, ale wiele progra-
mów tego nie potrafi. W takiej sytuacji pomoc-

•   http://jakilinux.org/aplikacje/sztuczki-z-ssh/ – Artykuł o sztuczkach z SSH cz.1
•   http://jakilinux.org/aplikacje/sztuczki-z-ssh-2-tunele/ – Część druga artykułu.
•   http://www.openssh.com/ – strona projektu OpenSSH
•   http://winscp.net/ – WinSCP, klient SCP i SFTP dla systemów Windows
•   http://www.chiark.greenend.org.uk/~sgtatham/putty/ – Putty, klient SSH dla

systemów Windows

•   http://gftp.seul.org/ – GFTP, graficzny klient m.in. SFTP.
•   http://www.red-pill.eu/freeunix.shtml – lista darmowych kont SSH
•   http://fuse.sourceforge.net/sshfs.html – SSHFS
•   http://roumenpetrov.info/openssh/ – Rozszerzenie X.509 dla OpenSSH.

W Sieci

styczeń 2010

Rozwiązania

Zabawa w SSHowanego

www.lpmagazine.org

Rozwiązania

Zabawa w SSHowanego

nym może okazać się program tsocks. Pozwa-
la on korzystać z proxy SOCKS programom,
które nie wspierają konfiguracji z takim ty-
pem pośrednika. Dla aplikacji taki sposób po-
łączenia jest przezroczysty, tak jakby łączył się
z siecią bezpośrednio. Instalujemy tscocks na
komputerze firmowym poprzez

jan@firmowy$ sudo aptitude install
tsocks

a następnie konfigurujemy w pliku /etc/
tsocks.conf jak na Listingu 3.

Parametr

local

określa, jakie adresy ma-

ją być traktowane jako lokalne. Oznacza to, że
proxy nie będzie stosowane do połączenia z ni-
mi. Parametr

server

zawiera adres serwera po-

średniczącego. W tym wypadku jest to lokalny
komputer firmowy czyli localhost (127.0.0.1).
Parametr

server-port

wskazuje, na którym

porcie nasłuchuje pośrednik, jest to ten sam
port co przy opcji

-D

polecenia

ssh

. Ostatni

z parametrów

server_type

to typ proxy, wpi-

sujemy tu 4 lub 5. Po zapisaniu konfiguracji
możemy korzystać z dobrodziejstw jakie ofe-
ruje program. Polecenie:

jan@firmowy$ tsocks audacious

powoduje, że tscocks uruchamia odtwarzacz mu-
zyki Audacious. Wszystkie żądania sieciowe,
z wyjątkiem tych do adresów zdefiniowanych
w parametrze local, tak uruchomionego odtwa-
rzacza będą obsługiwane przez tsocks i przesyła-
ne przez proxy zbudowane w oparciu o SSH.

Ucieczka

ze strefy zdemilitaryzowanej

Mamy  już  wystarczająco  dużo  doświadcze-
nia  z  SSH,  aby  przystąpić  do  bardziej  za-
awansowanego zadania. Pozwoli ono wyko-
rzystać  i  utrwalić  zdobytą  do  tej  pory  wie-
dzę.  Przypuśćmy,  że  administrujemy  firmo-
wym serwerem WWW. Systemem operacyj-
nym komputera jest Debian i mamy do niego
dostęp przez SSH. Nikt nie będzie nam blo-
kował dostępu do serwera, ale jak się często
zdarza maszyna została umieszczona w stre-
fie zdemilitaryzowanej (DMZ). DMZ to pod-
sieć, do której jest dostęp z sieci firmowej jak
i z Internetu, ale komputery w niej się znaj-
dujące nie mogą nawiązywać połączeń na ze-
wnątrz  strefy.  Jest  to  powszechna  praktyka
bezpieczeństwa.  Jeśli  intruz  przejąłby  kon-
trolę nad serwerem znajdującym się w takiej
strefie  to  nie  może  się  z  niego  połączyć  do
komputerów pracowników firmy ani do Inter-
netu, w celu np. rozsyłania SPAMu lub atako-
wania innych maszyn.

Zabezpieczenia potrafią jednak być bardzo

uciążliwe nie tylko dla włamywaczy, ale i dla
użytkowników. Przyjmijmy, że na naszym ser-
werze obok istniejącej już witryny w PHP trzeba
uruchomić drugą stronę napisaną w Perlu. Za-
zwyczaj wymaga to zainstalowania wielu bi-
bliotek Perla, a ich ręczne instalacja zajęłaby pół
dnia. Kilka godzin pracy polegającej na szuka-
niu modułów w repozytoriach, lub CPAN, po-
bieraniu ich, a następnie kopiowaniu na serwer
i instalowaniu jeden po drugim to perspektywa,
która może zniechęcić. Na szczęście SSH po-
zwala nam zaoszczędzić tego wysiłku. Na ser-
werze WWW jest już zainstalowane OpenSSH,
ale braknie pakietu tsocks. Pobierzemy go ręcz-
nie z jednego z serwerów lustrzanych Debiana,
skopiujemy i zainstalujemy.

Jak widać na powyższym przykładzie du-

żo pracy jest z instalacją ręczną nawet jedne-
go pakietu.

Po instalacji konfiguracja tsocks będzie

wyglądała tak samo jak na Listingu 3. Trze-
ba jeszcze tylko zestawić tunel odwrotny i uru-
chomić serwer pośredniczący. Zaczniemy od
ponownego zalogowania się na serwer WWW

jan@firmowy$ ssh jan@serwerfirmowy -R
8022:localhost:22

Teraz połączenia na port 8022 serwera bę-
dą przekierowywane do komputera firmowe-
go. Polecenie:

jan@serwerfirmowy$ ssh jan@localhost
-p 8022 -D 8080

wydane z serwera WWW połączy nas do kom-
putera lokalnego. Dodatkowo ustawi proxy na
porcie 8080 za pośrednictwem którego będzie
można łączyć się z Internetem, tunelując ruch
przez komputer lokalny. Kolejnym krokiem
jest otwarcie drugiej sesji SSH i wykonanie ja-
ko root polecenia:

jan@serwerfirmowy# tsocks aptitude

a  następnie  wybranie  i  zainstalowanie  nie-
zbędnych  pakietów  oprogramowania.  Po  za-
kończonej  pracy  zamykamy  wszystkie  sesje
SSH a tym samym tunele. Ponieważ tsocks zo-
stało już zainstalowane i skonfigurowane, na-
stępnym  razem  w  podobnej  sytuacji  będzie
można rozpocząć od zestawiania tuneli.

Trudno jest przecenić wartość SSH. Jest

ono czymś więcej niż tylko szyfrowanym na-
stępcą telnetu i rlogin. Pozwala na zdalne wy-
konywanie poleceń podobnie jak RSH, szy-
frując kanał transmisji. Umożliwia kopiowa-
nie plików przez SCP jako bezpieczna alterna-

tywa dla RCP. Zastępuje FTP przez bezpieczny
protokół SFTP. Dzięki SSH możemy przekiero-
wać porty, tworzyć tunele i przekierowywać se-
sje X11 między różnymi komputerami w sieci.
Zastosowanie autoryzacji przez klucze pozwa-
la na proste stosowanie SSH w skryptach, nie
wymagających interakcji użytkownika. Może-
my również utworzyć pośrednika sieciowego,
który zostanie wykorzystany przez przeglądar-
kę WWW lub inne programy.

Rozwiązania bazujące na SSH

W tym rozdziale przedstawionych zostanie kilka
rozszerzeń i rozwiązań bazujących na SSH.

Bardzo wygodnym narzędziem dla wielu

użytkowników może okazać się SSHFS (SSH
File  System).  Pozwala  on  na  zamontowanie
fragmentu  systemu  plików  zdalnego  serwera
na lokalnej maszynie i używanie go jako do-
datkowy  dysk.  Rozwiązanie  to  wykorzystuje
połączenie SSH i FUSE, czyli system plików
w przestrzeni użytkownika.

Innym ciekawym rozwiązaniem wykorzy-

stującym SSH jest protokół FISH. Został on
opracowany na potrzeby programu mc (Mid-
night Commander) do kopiowania plików za
pomocą zdalnych wywołań powłoki. Wspie-
ra nie tylko SSH, ale również RSH. W prak-
tyce jednak wykorzystuje ten pierwszy. Proto-
kół, poza Midnight Commanderem, jest uży-
wany m.in. w popularnym menedżerze plików
KDE – Konquerorze.

W artykule została przedstawiona moż-

liwość  autoryzacji  w  SSH  za  pomocą  klucza
kryptograficznego, ale warto również wiedzieć,
że zostało opracowane rozwiązanie pozwalają-
ce na logowanie za pomocą certyfikatów X509.
Certyfikaty, czyli bardziej zaawansowana wer-
sja kluczy, oprócz samego materiału kryptogra-
ficznego  zawierają  informację  o  właścicielu
certyfikatu i ścieżce certyfikacji – organizacjach
odpowiedzialnych  za  jego  wystawienie.  Roz-
szerzenie jest rozwijane niezależnie od głównej
gałęzi projektu OpenSSH.

To jednak nie wszystko.Wachlarz pomy-

słów na wykorzystanie SSH jest bardzo szeroki
i zależy od inwencji i potrzeb użytkowników.

Autor  jest  z  wykształcenia  inżynierem
elektroniki,  Linuksem  interesuje  się  od
ośmiu  lat.  Na  co  dzień  używa  go  tak  w
pracy, jak i w domu a jego ulubione dystry-
bucje to Gentoo i Debian.
Kontakt z autorem:
w.terlikowski@terlikowski.eu.org

O autorze