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:

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

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

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

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:

ssh uzytkownik@host -X

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

export DISPLAY=:0

X11Forwarding yes