Konfigurowanie ssh (klient, serwer, tunelowanie)

Program ssh (Secure Shell) służy do logowania się na zdalne komputery (przez sieć) i zdalnego wykonywania komend. W przeciwieństwie do programów typu rsh czy telnet oferuje bezpieczną, szyfrowaną komunikację, uniemożliwia więc ewentualne podsłuchiwanie transmisji. Autoryzacja użytkownika może się odbywać na kilka sposobów. Najprostszym jest autoryzacja przy pomocy podawanego przez użytkownika hasła. Po uruchomieniu komendy

ssh login@host

program pyta się o hasło. login oznacza tu nazwę użytkownika, a host nazwę komputera, np. palacz@mail.praterm.com.pl. Często przydatne jest aby ssh nie pytał się o hasło - umożliwia to między innymi wygodne używanie ssh z programów nieinterakcyjnych (np. przez system BODAS).

Skonfigurowanie ssh wymaga kilku prostych kroków:

• W systemie muszą być zainstalowane odpowiednie pakiety, zawierające między innymi program ssh. Pakiety te ze względu na obowiązujące niegdyś amerykańskie embargo na eksport niektórych z wykorzystywanych alogrytmów nie były dołączane do starszych dystrybucji Linuksa. Może być więc konieczne doinstalowanie ich oddzielnie. W RH 7.2 postępowanie według HOWTO powoduje poprawną instalację ssh. Nazwy pakietów zaczynają się od openssh i openssl. Poniższy opis odnosi się do RH 6.2 (wszystkie pakiety znajdują się na dołączonej płytce PowerTools):

Dla klienta ssh instalujemy więc pakiety:

openssl-0.9.5a-1.i386.rpm

openssh-2.1.1p1-1.i386.rpm

openssh-clients-2.1.1p1-1.i386.rpm

dla serwera trzeba dodatkowo zainstalowac:

openssh-askpass-2.1.1p1-1.i386.rpm

openssh-askpass-gnome-2.1.1p1-1.i386.rpm

openssh-server-2.1.1p1-1.i386.rpm

openssl-devel-0.9.5a-1.i386.rpm

RH v6.1 openssl-0.9.5a-1.i386.rpm miał konflikty takie, że plik /usr/man/man3/rand.3 z pakietu openssl-0.9.5a-1 jest w konflikcie z plikiem z pakietu man-pages-1.26-5 a plik /usr/man/man1/passwd.1 z pakietu openssl-0.9.5a-1 jest w konflikcie z plikiem z pakietu passwd. W takich przypadkach należy użyc opcji --force do programu rpm, czyli:

rpm -ihv --force openssl-0.9.5a-1.i386.rpm

rpm -ihv openssh*

No chyba, że chce się zainstalować tylko wybrane pakiety (które trzeba podać).

• Na komputerze, do którego mamy zamiar się łączyć (serwerze) należy skonfigurować demona ssh (program sshd) - musi on być uruchamiany przy starcie systemu. Można to zrobić programem typu ksysv lub ręcznie. W tym drugim przypadku, jeśli system uruchamiany jest w runlevelu 5, należy jako root wykonać komendę:

ln -s /etc/rc.d/init.d/sshd /etc/rc.d/rc5.d/S55sshd

Po ponownym uruchomieniu komputera lub wykonaniu komendy

/etc/rc.d/rc5.d/S55sshd start

serwer powinien być gotowy do przyjmowania połączeń ssh. Należy się także upewnić, czy na obu komputerach plik /etc/services zawiera niewykomentowane linie

ssh 22/tcp

ssh 22/udp

• Następnie można skonfigurować ssh tak, żeby nie było konieczne podawanie hasła. Tu sprawa się niestety trochę komplikuje...

Otóż powszechnie używana implementacja ssh (obecna również w systemach RedHat), openssh, potrafi korzystać w dwóch protokołów ssh: z wersji 1-szej i z wersji 2-giej (są niekompatybilne!).

Wersja pierwsza:

Załóżmy, że np. użytkownik janosik na komputerze alpha chce się logować na komputer beta jako użytkownik ondraszek. W tym celu janosik musi uruchomić program:

ssh-keygen

a w systemie Red Hat v7.x do wywołania dodać opcję:

ssh-keygen -t rsa1

Na zadawane przez program pytania należy odpowiadać naciskając po prostu <Enter> Program wygeneruje dwa pliki - z kluczem prywatnym (~/.ssh/identity) i z kluczem publicznym (~/.ssh/identity.pub). Pierwszy z nich musi być chroniony przed odczytem przez niepowołane osoby. Zawartość drugiego (całą linię) należy skopiować na komputer beta do katalogu domowego użytkownika ondraszek, do pliku ~/.ssh/authorized_keys. Jeżeli ten ostatni plik nie istnieje, trzeba go utworzyć. Po prawidłowym utworzeniu tego pliku należy nadać mu odpowiednie prawa (powinien być tylko do odczytu). Można to zrobić komendą chmod 444 authorized_keys. Odpowiednie prawa dostępu musi też mieć katalog .ssh (chmod 700).

Wersja druga:

Zakładamy identyczną konfigurację jak opisana powyżej, czyli chcemy, żeby janosik@alpha mógł się logować bez hasła jako ondraszek@beta. Tak jak poprzednio janosik musi skorzystać z programu ssh-keygen, lecz tym razem uruchamia go z parametrem:

ssh-keygen -t rsa

Wygenerowane zostaną pliki ~/.ssh/id_rsa (klucz prywatny - odpowiednik ~/.ssh/identity z wersji pierwszej) i ~/.ssh/id_rsa.pub (klucz publiczny, odpowiednik ~/.ssh/identity.pub). Klucz publiczny dostaje ondraszek i dorzuca go do pliku ~/.ssh/authorized_keys2. Wszystkie uprawnienia do plików ustawiamy jak w przypadku wersji 1-szej.

Teraz, po wpisaniu przez użytkownika janosik na komputerze alpha polecenia

ssh ondraszek@beta

powinno nastąpić zalogowanie na komputer beta, bez pytania o hasło. Jeśli ssh nadal pyta się o hasło należy sprawdzić, czy plik konfiguracyjny demona sshd na zdalnym komputerze ( /etc/ssh/sshd_config) zawiera niezakomentowaną linię:

RSAAuthentication yes

Uwaga! W starszych RedHatach (np. v6.2) klient ssh domyślnie używał protokołu w wersji pierwszej, natomiast nowsze RH (np. v7.1) używają wersji drugiej. Można to zmienić modyfikując wartość zmiennej Protocol w pliku /etc/ssh/ssh_config: jeżeli mamy

Protocol 2,1

to znaczy, że klient ssh najpierw spróbuje się połączyć przy użyciu protokołu w wersji 2-giej (a potem, w razie niepowodzenia, wypróbuje wersję pierwszą). Zwykle należy zamienić kolejność cyferek na: 1,2. Domyślną wartością (przyjmowaną w przypadku nieustawienia żadnej wartości dla zmiennej Protocol) jest:

Protocol 1,2

Żeby wymusić wersję protokołu możemy użyć argumetu -<numer wersji> do programu klienckiego ssh, na przykład wywołanie

ssh -2 ondraszek@beta

wymusi użycie wersji drugiej protokołu ssh.

Uwaga! W starszych wersjach klienta ssh (np. w RH 6.2) nie można użyć opcji -1, z kolei program ssh-keygen nie przyjmuje wartości argumentu -t rsa (generuje klucze tylko dla wersji 1-szej). Z drugiej strony nawet na najnowszych systemach (z domyślną wersją drugą protokołu) ssh-keygen domyślnie generuje klucze dla wersji 1-szej (identity i identity.pub). Dlatego też trudno pisać przenośne skrypty wymieniające klucze ssh. Najbezpieczniejsze jest chyba stosowanie protokołu w wersji 1-szej na wszystkich maszynach i ewentulanie modyfikowanie plików konfiguracyjnych ssh na maszynach z nowszymi systemami.

W razie wystąpienia problemów z autoryzacją RSA trzeba uruchomić ssh w trybie verbose (ssh -v). Program wyświetli wtedy błędy, co znacznie ułatwia rozpoznanie problemu.

Należy także pamiętać, że każdy użytkownik, na konto którego chcemy się logować przez ssh, musi mieć niepuste hasło!

Plikiem konfiguracyjnym dla klienta ssh jest /etc/ssh/ssh_config. Oprócz wspomnianej wyżej wersji protokołu możemy ustawić globalnie kilka innych parametrów, są to np.:

• IdentityFile - miejsce ścieżka do pliku (identity) i jego nazwa. Domyślnie ~/.ssh/identity (dla wersji 1-szej).
• StrictHostKeyChecking - ustawienie, czy klient ssh może automatycznie dodawać hosty do pliku ~/.ssh/known_host. Przyjmuje jedną z trzech wartości: 'yes', 'no' lub 'ask' (wartość domyślna). Jeżeli ustawimy na 'no' to wpisy będą dodawane automatycznie, 'yes' oznacza, że będziemy musieli wpisy dodawać ręcznie (tego nie należy używać!), natomiast 'ask' oznacza, że ssh sam będzie dodawał wpisy po potwierdzeniu użytkownika.

Często jest potrzeba do dostania się maszyny 'schowanej' za bramką opartą na wynalazku firmy M$ - Internet Connection Shareing. Nie jest to możliwe bezpośredni, ale i na to są metody. Do takich celów powstał skrypt ssh_tunel.sh - korzysta on z opcji tunelowania (enkapsulacji) połączeń w zwykłym połączeniu ssh. Jego wykorzystanie jest proste. Wywołujemy komende (oczywiście na root'a)

crontab -e

następnie dodajemy następującą linię do tego pliku:

*/10 * * * * /sciezka/do/skryptu/ssh_tunel.sh zdalnyuser@zdalnamaszyna port

Gdzie zdalnyuser@zdalnamaszyna to ustawione wcześniej z autoryzacją bezhasłową konto na zdalnej maszynie, z której chcemy mieć udostępnione połączenie zwrotne do serwera (np. może to być byto@praterm.com.pl dla serwera SZARPa w Bytowie). Port jest to zaś numer portu za pośrednictwem którego będziemy się łączyć do serwera. Następnie już (po max. 10 min kiedy polecenie zostanie po raz pierwszy uruchomione), będzie można na <zdalnamaszyna> łączyć się do serwera z SZARPem:

ssh user@localhost -p <port>

UWAGA!!! kiedy łączymym kilka maszyn tunelami do jednej maszyny powinniśmy zadbać o unikalność numeru portu.

Programów ssh można użyć w celu zdalnego uruchamiania programów iksowych, np. pracujemy na systemie XWindows w jednym mieście (na Linuksie czy na Windowsie) i chcielibyśmy uruchomić program w innym mieście tak, żeby okienko wyświetlało się u nas lokalnie. W tym przypadku wykorzystamy program ssh z parametrem -X:

• Uruchamiamy konsolę (najlepiej iksową - automatycznie zostanie ustawiona zmienna DISPLAY).
• Logujemy się zdalnie przy użyciu ssh (z parametrem -X):

ssh uzytkownik@host -X

• Na zdalym hoście uruchamiamy pożądaną aplikację. Okienko aplikacji powinno się nam wyświetlić lokalnie.

Uwaga! Jeżeli okienko się nie wyświatla, może oznaczać że:

• Lokalnie nie została ustawiona zmienna środowiskowa DISPLAY. Można to zrobić ręczenie, wywołując:

export DISPLAY=:0

• Zdalny serwer ssh nie wspiera tzw. X11 Forwarding. Należy sprawdzić w pliku /etc/ssh/sshd_config czy włączona jest następująca opcja:

X11Forwarding yes