14.11. OpenSSH

Napisał Chern Lee.

OpenSSH to zestaw narzędzi sieciowych używanych do pracy ze zdalnymi maszynami w sposób bezpieczny. Można je traktować jako zastępstwo dla rlogin, rsh, rcp i telnet. Jako dodatkową zaletę wymienić należy fakt, że potrafią one również tunelować inne połączenia TCP/IP przez SSH. Połączenia OpenSSH są szyfrowane, co powinno zabezpieczyć transmitowane dane przed podsłuchaniem, przejęciem sesji i innymi atakami na poziomie sieci.

OpenSSH utrzymywany jest przez projekt OpenBSD i bazuje na wersji SSH 1.2.12 ze wszystkimi dostępnymi poprawkami błędów i uaktualnieniami. Narzędzie to jest zgodne zarówno z wersją 1 jak i 2 protokołu SSH.

14.11.1. Zalety stosowania OpenSSH

W przypadku stosowania telnet(1) czy rlogin(1), dane przesyłane są przez sieć w czystej, niezaszyfrowanej postaci. Umożliwia to podsłuchanie sesji w dowolnym miejscu pomiędzy nadającym a odbierającym i wyłuskanie informacji o wykorzystywanych identyfikatorach i hasłach. OpenSSH oferuje cały zestaw uwierzytelniania i szyfrowania by zapobiec takiemu obrotowi spraw.

14.11.2. Aktywacja sshd

W trakcie instalacji FreeBSD w trybie Standard dostępna jest opcja sshd, która aktywuje demona SSH. By upewnić się, że opcja ta jest aktywna należy odnaleźć w pliku rc.conf wpis postaci:

sshd_enable="YES"

Spowoduje to załadowanie demona sshd(8) przy następnym uruchomieniu systemu. Możemy również uruchomić go od razu, uruchamiając skrypt rc(8) /etc/rc.d/sshd:

/etc/rc.d/sshd start

14.11.3. Klient SSH

Narzędzie ssh(1) działa podobnie do rlogin(1).

# ssh user@example.com
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? yes
Host 'example.com' added to the list of known hosts.
user@example.com's password: *******

Logowanie będzie kontynuowane tak jakbyśmy nawiązali połączenie poleceniem rlogin lub telnet. SSH stosuje elektroniczny odcisk klucza w celu weryfikacji serwera podczas połączenia. Użytkownik proszony jest o zaakceptowanie takiego a nie innego odcisku tylko za pierwszym razem - należy wpisać yes. W przypadku kolejnych połączeń, klient weryfikuje otrzymany odcisk do zapisanego i powiadomi o ewentualnej różnicy. Elektroniczne odciski kluczy serwerów przechowywane są w pliku ~/.ssh/known_hosts, lub dla SSH v2 w pliku ~/.ssh/known_hosts2.

Domyślnie, nowsze wersje serwerów OpenSSH akceptują jedynie połączenia SSH v2. Klienci wykorzystują wersję 2, a jeśli nie będzie to możliwe dopiero wersję 1. Można również wymusić wykorzystanie wybranej wersji poprzez opcję -1 lub -2, dla odpowiednio wersji 1 lub 2. Wersja 1 dostępna jest w klientach ze względów na zgodność ze starszymi serwerami.

14.11.4. Bezpieczne kopiowanie

Polecenie scp(1) działa podobnie do rcp(1); kopiuje pliki do lub ze zdalnej maszyny, ale robi to w sposób bezpieczny.

# scp user@example.com:/COPYRIGHT COPYRIGHT
user@example.com's password: *******
COPYRIGHT            100% |*****************************|  4735       
00:00    
#

Ponieważ dla tego komputera zapisaliśmy już elektroniczny odcisk klucza, zostaje on sprawdzony podczas połączenia za pomocą narzędzia scp(1).

Argumenty przekazywane programowi scp(1) są podobne do tych znanych z programu cp(1) - plik lub pliki do skopiowania na początku, po nich miejsce docelowe. Ponieważ plik przesyłany jest przez sieć (przez SSH), należy użyć zapisu w postaci user@host:<ścieżka_do_zdalnego_pliku>.

14.11.5. Konfiguracja

Konfiguracja globalna dla systemu, zarówno dla klienta jak i demona OpenSSH znajduje się w katalogu /etc/ssh.

Plik ssh_config zawiera opcje konfiguracji klienta, podczas gdy sshd_config serwera.

Dodatkowo w pliku rc.conf można wskazać alternatywną lokalizację zarówno serwera SSH (domyślnie /usr/sbin/sshd) - opcją sshd_program, oraz opcje przekazywane mu podczas startu - opcją sshd_flags.

14.11.6. ssh-keygen

Zamiast stosować hasła, możemy wykorzystać program ssh-keygen(1) do wygenerowania kluczy DSA lub RSA i używać ich do uwierzytelnienia procesu logowania:

% ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 user@host.example.com

ssh-keygen(1) tworzy parę kluczy: prywatny i publiczny. Klucz prywatny przechowywany jest w pliku ~/.ssh/id_dsa bądź ~/.ssh/id_rsa, natomiast publiczny w ~/.ssh/id_dsa.pub bądź ~/.ssh/id_rsa.pub, odpowiednio dla kluczy DSA i RSA. Klucz publiczny należy dodatkowo dopisać do pliku ~/.ssh/authorized_keys na zdalnej maszynie tak, by można było wykorzystać uwierzytelnianie za pomocą kluczy. Analogicznie, również klucz publiczny RSA wersji 1 powinien zostać umieszczony w pliku ~/.ssh/authorized_keys.

Pozwoli to na połączenia do zdalnej maszyny na podstawie kluczy SSH, w miejsce haseł.

Jeśli dodatkowo skorzystamy z opcji ssh-keygen(1) zabezpieczenia kluczy hasłem, będziemy o nie pytani przy każdym użyciu klucza prywatnego. Rozwiązaniem problemu ciągłego wpisywania długiego hasła jest ssh-agent(1), którego użycie przybliża Sekcja 14.11.7 poniżej.

OstrzeżenieNiektóre opcje czy nazwy plików mogą różne od tutaj przedstawionych, zależnie od wersji OpenSSH zainstalowanej w naszym systemie. By uniknąć wynikających z tego tytułu problemów, powinniśmy zapoznać się z podręcznikiem systemowym ssh-keygen(1).

14.11.7. ssh-agent i ssh-add

Programy ssh-agent(1) i ssh-add(1) pozwalają wczytać do pamięci klucze SSH, aby móc później korzystać z nich bez konieczności wpisywania za każdym razem hasła.

Program ssh-agent(1) zajmuje się uwierzytelnianiem użytkownika za pomocą wczytanych kluczy prywatnych. Wykorzystywany jest on do uruchamiania innych aplikacji. Na najniższym poziomie, uruchamia interpreter powłoki, bądź na wyższym - menedżer okien.

By wykorzystać ssh-agent(1) w powłoce systemowej, musi być on wpierw uruchomiony z nazwą powłoki jako parametrem. Następnie należy dodać tożsamość, uruchamiając program ssh-add(1) i podając hasło klucza prywatnego. Po czym będziemy mogli połączyć się za pomocą ssh(1) do dowolnej maszyny z zainstalowanym właściwym kluczem publicznym. Na przykład:

% ssh-agent csh
% ssh-add
Enter passphrase for /home/user/.ssh/id_dsa:
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
%

By wykorzystać ssh-agent(1) w X11, powinniśmy umieścić odwołanie ssh-agent(1) w pliku ~/.xinitrc. Udostępni do funkcje programu ssh-agent(1) wszystkim aplikacjom uruchamianym w X11. Przykładowy plik ~/.xinitrc mógłby wyglądać następująco:

exec ssh-agent startxfce4

Spowodowałoby to uruchomienie ssh-agent(1) przy każdym starcie X11, który z kolei uruchamiałby XFCE. Po ponownym uruchomieniu X11, w celu uwzględnienia dokonanych zmian konfiguracji, wystarczy uruchomić ssh-add(1), by wczytać wszystkie nasze klucze SSH.

14.11.8. Tunelowanie SSH

OpenSSH umożliwia tworzenie tunelu, hermetyzującego inny protokół w zaszyfrowanej sesji.

Poniższe polecenie tworzy tunel ssh(1) dla programu telnet:

% ssh -2 -N -f -L 5023:localhost:23 użytkownik@foo.example.com
%

Polecenie ssh może przyjąć następujące opcje:

-2

Wymusza użycie wersji drugiej protokołu ssh (nie należy używać, jeśli łączymy się ze starszymi serwerami SSH).

-N

Wskazuje na brak polecenia, lub tylko połączenie tunelowe. Pominięta, powoduje nawiązanie przez ssh normalnej sesji.

-f

Wymusza pracę ssh w tle.

-L

Wskazuje lokalny koniec tunelu w postaci localny_port:zdalna_maszyna:zdalny_port.

użytkownik@foo.example.com

Zdalny serwer SSH.

Tunel SSH działa w ten sposób, że tworzy nasłuchujące gniazdo na wskazanym porcie localhost. Następnie cały otrzymany ruch przekazuje przez połączenie SSH do określonej zdalnej maszyny, na wskazany port.

W przykładzie, port 5023 na localhost przekazywany jest na port 23 na localhost zdalnej maszyny. Ponieważ port numer 23 to telnet, połączenie to tworzy bezpieczną sesję telnetową przez tunel SSH.

Takiego tunelowania można użyć w stosunku do dowolnych natywnie niezabezpieczonych protokołów działających z wykorzystaniem TCP, takich jak SMTP, POP3, FTP itd.

Przykład 14-1. Zastosowanie SSH do stworzenia bezpiecznego tunelu dla SMTP

% ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
user@mailserver.example.com's password: *****
% telnet localhost 5025
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTP

Możemy użyć takiej konstrukcji w połączeniu z ssh-keygen(1) i dodatkowymi kontami użytkowników by stworzyć całkowicie bezproblemowe środowisko tunelowania SSH. W miejsce wpisywanych haseł można użyć kluczy, a tunele może tworzyć osobny użytkownik.

14.11.8.1. Praktyczne przykłady tunelu SSH

14.11.8.1.1. Bezpieczny dostęp do serwera POP3

W firmie znajduje się serwer SSH, akceptujący połączenia z zewnątrz. W tej samej sieci biurowej znajduje się serwer pocztowy POP3. Sieć, lub trasa przez sieć pomiędzy domem a biurem może być, a może nie być kompletnie bezpieczna. Z uwagi na tą niepewność, powinniśmy zabezpieczyć sprawdzanie stanu naszej skrzynki pocztowej. Rozwiązaniem jest stworzenie tunelu SSH pomiędzy naszym komputerem a serwerem SSH w biurze, a następnie w tunelu nawiązać połączenie do serwera pocztowego.

% ssh -2 -N -f -L 2110:mail.example.com:110 user@ssh-server.example.com
user@ssh-server.example.com's password: ******

Gdy tunel jest zestawiony, możemy skonfigurować naszego klienta pocztowego, by łączył się nie z serwerem, a z localhost na porcie 2110. Połączenie zostanie przekazane bezpiecznie przez tunel do hosta mail.example.com.

14.11.8.1.2. Przechodzenie przez drakońskie zapory ogniowe

Niektórzy administratorzy wymuszają granicznie drakońskie reguły filtrowania - filtrując nie tylko ruch przychodzący, ale również wychodzący. Być może otrzymaliśmy pozwolenie tylko na wykonywanie połączeń wychodzących na porty 22 i 80 - dla połączeń SSH i z serwerami WWW.

Możemy osiągnąć inne usługi (być może nie związane z wykonywaną pracą), takie jak np. serwer Ogg Vorbis do strumieniowego przesyłania muzyki. Jeśli serwer ten nadaje na innym porcie niż dozwolony 22 czy 80, nie będziemy w stanie się z nim połączyć.

Rozwiązaniem jest nawiązanie połączenia SSH do maszyny na zewnątrz naszej sieci firmowej i użycie jej do tunelowania ruchu z serwera Ogg Vorbis.

% ssh -2 -N -f -L 8888:music.example.com:8000 user@unfirewalled-system.example.org
user@unfirewalled-system.example.org's password: *******

Naszego klienta obsługującego muzykę musimy skonfigurować, aby łączył się z localhost na porcie 8888 - ruch na ten port zostanie przekazany do music.example.com na port 8000, przechodząc pomyślnie przez zaporę ogniową.

14.11.9. Opcja AllowUsers

Z reguły dobrym pomysłem jest ograniczenie liczby użytkowników, którzy będą mogli logować się do naszego systemu, jak również ograniczenie adresów, z których będą się logować. W takiej sytuacji pomocną jest opcja AllowUsers. Przykładowo, by pozwolić na logowanie się tylko użytkownikowi root z adresu 192.168.1.32, właściwy byłby wpis w pliku /etc/ssh/sshd_config postaci:

AllowUsers root@192.168.1.32

By pozwolić użytkownikowi admin na logowanie się z dowolnej maszyny w sieci, wystarczy podać samą nazwę użytkownika:

AllowUsers admin

Gdy chcemy pozwolić logować się kilku użytkownikom, powinniśmy umieścić ich w jednej linii:

AllowUsers root@192.168.1.32 admin

Notatka: Przy użyciu opcji AllowUsers istotnym jest wypisanie każdego użytkownika, który ma mieć możliwość logowania się na naszą maszynę. Użytkownicy nie wymienieni nie będą mieli możliwości zalogowania się poprzez SSH.

Za każdym razem gdy dokonamy zmian w pliku /etc/ssh/sshd_config musimy poinformować demona sshd(8), by ponownie wczytał plik konfiguracyjny:

# /etc/rc.d/sshd reload

14.11.10. Dodatkowa lektura

OpenSSH

ssh(1) scp(1) ssh-keygen(1) ssh-agent(1) ssh-add(1) ssh_config(5)

sshd(8) sftp-server(8) sshd_config(5)

Ten i inne dokumenty można pobrać z ftp://ftp.FreeBSD.org/pub/FreeBSD/doc/.

W przypadku pytań o FreeBSD prosimy przeczytać dostępną dokumentację przed kontaktem z <questions@FreeBSD.org>.
W sprawie zapytań o tę dokumentację prosimy o kontakt z <doc@FreeBSD.org>.