2004.01_Praca z OpenSSH_[Administracja].pdf

dla początkujących

Praca z OpenSSH

Piotr Machej

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 Open SSH , 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 Open SSH ), 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

Rysunek 1. Na głównej stronie projektu OpenSSH możemy

sprawdzić najnowszy numer wersji

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.

styczeń 2004

W dobie powszechnej dostępności Interne-

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

Rysunek 2. Po wykonaniu ./configure należy sprawdzić,

czy ustawienia nam odpowiadają

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

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-

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

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.

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 .

www.linux.com.pl

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 .

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

Rysunek 3. PuTTY jest bardzo wygodnym klientem SSH pod

Windows – pozwala nawet korzystać z klucza prywatnego

Wybrane opcje konfiguracyjne serwera:

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.

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

Koniguracja 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:

styczeń 2004

openssh

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 .

Rysunek 4. WinSCP na pierwszy rzut oka bardzo przypomina

program Total Commander

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

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

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 .

Praca z OpenSSH

OpenSSH najczęściej wykorzystujemy do bezpiecznego

logowania się na konta na zdalnych serwerach. W takim

przypadku wywołanie programu jest proste:

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

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:

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

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

www.linux.com.pl

dla początkujących

ssh gerard@192.168.0.35 netstat -nat

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:

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 Open SSH 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

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.

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.

styczeń 2004

Plik z chomika:

Inne pliki z tego folderu:

Inne foldery tego chomika: