0xcafebabe -- per aspera ad astra

Zwykle polecenia ssh używa się do łączenia z linią poleceń na innych maszynach. Można go jednak też wykorzystać jako proxy SOCKS, współdzielenie sieciowe systemu plików, ręczny ich transfer, przy okazji zwiększając bezpieczeństwo poprzez wyłączenie wymogu podawania hasła na konto ;).

Zebrane tutaj informacje są oczywiście możliwe do znalezienia z poziomu czytnika pomocy man, ale dla ułatwienia życia (m.in. sobie) postanowiłem zebrać je w jednym miejscu, aby móc potem w szybki sposób odnaleźć informacje, jeśli zdarzy mi się je zapomnieć. Przy okazji mogę pomóc też innym :P.

Usunięcie potrzeby podawania hasła na konto

Czyli inaczej: wykorzystanie kluczy publicznych do logowania się na konto.

Krok pierwszy w celu poznania alternatywnych przypadków użycia ssh to usunięcie potrzeby wpisywania hasła konta. Plusem takiego podejścia jest to, że jest odporne na ataki Man in the Middle, odgadnięcie twojego słabego hasła, jak też i to, że mając różne hasła na różne maszyny, nie musisz ich mieć w głowie, by się na nie zalogować.

Wchodząc nieco głębiej w szczegóły, nie jest to całkowicie wyeliminowany krok autoryzacji, a jedynie zmiana z postaci podawania hasła na konto (tradycyjne logowanie), na przesyłanie publicznego klucza RSA, który najpierw należy odblokować wcześniej ustaloną frazą.

Generowanie klucza odbywa się za pomocą polecenia ssh-keygen:

Po powrocie do znaku zachęty powinieneś móc odnaleźć plik ~/.ssh/id_rsa.pub. To jest klucz publiczny, który będzie potrzebny w dalszej części posta.

Polecam wygenerować klucz bez względu na to, czy podążysz tym przewodnikiem dalej, czy nie. Niektóre usługi potrafią wykorzystać taki klucz publiczny w celu usprawnienia metod autoryzacji, np. repozytorium gitorious.org.

Podczas generowania klucza możesz zostać zapytany o tajną frazę, która będzie pełniła rolę hasła. Zwróć uwagę na to, że fraza to nie jest to samo, co hasło, więc nie powinna wyglądać w sposób podobny do „123456” czy też np. „zaq12wsx”. Fraza, to fraza, czyli np. „Mrokiem l1pcowym koszac trawe.”. :)

Klucz bez hasła oczywiście może zostać wygenerowany, ale nie jest to mądre posunięcie. Co prawda wtedy żadne logowanie nie będzie pytało o hasło do konta, pozostawiając je w tajemnicy (ponieważ nigdy nie będzie podawane ani przesyłane przez sieć), ale niepotrzebnie ułatwi korzystanie z tego klucza ewentualnym osobom trzecim.

Mając klucz publiczny, można zacząć kombinować.

Najpierw polecam sprawdzić aktualną konfigurację sshd na serwerze zdalnym. Plik konfiguracyjny powinien mieć włączoną dyrektywę PubkeyAuthentication, aby móc skorzystać z tej metody.

Jeśli występuje u ciebie „no”, lub cała linijka poprzedzona jest kratką (#), niestety nie możesz wykorzystać logowania z wykorzystaniem kluczy publicznych. Możesz to naprawić przechodząc na root'a i poprawiając plik konfiguracyjny, restartując sshd aby zaaplikować zmiany. Jeśli natomiast nie widzisz linijki w ogóle, lub widzisz błąd istnienia pliku /etc/ssh/sshd_config, oznacza to że na własną rękę musisz dowiedzieć się jaka jest konfiguracja sshd w tej kwestii ;).

Następny krok, po stworzeniu klucza prywatnego (id_rsa) i publicznego (id_rsa.pub), to zalogowanie się na zdalną maszynę – na którą chcesz logować się bez hasła konta – i stworzenie pliku ~/.ssh/authorized_keys, jeśli jeszcze nie istnieje.

Uwaga, czasami plik będzie nazywał się inaczej. Aby poprawnie odczytać oczekiwaną nazwę, odczytaj tą dyrektywę z konfiguracji sshd:

Następnie wrzuć swój plik id_rsa.pub na zdalną maszynę, np. do pliku ~/pubkey i doklej jego zawartość do pliku authorized_keys:

Po tej operacji wyloguj się i połącz przez ssh ponownie. Zamiast pytania o hasło powinieneś dostać pytanie o frazę do klucza prywatnego. Po podaniu tej frazy, zostajesz zalogowany ;). Operację doklejenia lokalnego pliku id_rsa.pub do authorized_keys na maszynie zdalnej należy powtórzyć dla każdego systemu, na który chcesz się logować przez użycie klucza publicznego.

ssh-agent

Od strony bezpieczeństwa być może teraz jest lepiej, ale od strony użytkowej już niekoniecznie. I tak trzeba podawać hasło przy każdym logowaniu, i prawdopodobnie jest ono dłuższe niż to, które było poprzednio. Sytuacji nie ratuje nawet fakt, że teraz wpisujesz cały czas to samo hasło, bez względu na maszynę docelową.

Można jednak zapamiętać hasło do klucza prywatnego na pewien z góry określony czas, np. czas sesji, lub ręcznie wybierać czas rozpoczęcia pamiętania i jego zakończenia. Pomocny przy tym okazuje się program ssh-agent.

Należy go uruchomić na początku swojej sesji, tzn. po zalogowaniu, czy to do linii poleceń, czy do środowiska graficznego. Jeśli pracujesz na xfce, możesz np. wykorzystać do tego graficzny program do konfiguracji programów startowych:

w GNOME i KDE na pewno są analogiczne konfiguratory, możesz też wykorzystać nieco niższe mechanizmy oferowane przez sam X.

Polecenie eval `ssh-agent` uruchamia agenta ssh, modyfikując jednocześnie kilka zmiennych środowiskowych, aby inne programy-narzędzia bez problemu mogły tego agenta zlokalizować.

Po dodaniu nowego wpisu do skryptów startowych środowiska graficznego i przelogowaniu się, upewnij się, że agent został poprawnie uruchomiony:

Jeśli wszystko dobrze działa, to należy użyć programu ssh-add, którym należy wskazać konkretny klucz publiczny do zapamiętania:

Hasło wpisuje się na początku. Od teraz każde logowanie ssh na zewnętrzną, skonfigurowaną do autoryzacji kluczem publicznym, maszynę, będzie mogło zostać wykonane bez podawania haseł.

Możesz też podejrzeć, które klucze są aktualnie zapamiętane, przy pomocy polecenia ssh-add z argumentem -l:

Więcej manipulacji kluczami, w tym zapominanie sesji, można odnaleźć w manualu :).

Proxy SOCKS

Czyli inaczej: argument -D i FoxyProxy.

sshd potrafi zamienić się w serwer proxy, w razie potrzeby. Pakiety lecące przez taki tunel ssh są oczywiście szyfrowane, co jest dość przydatne podczas znajdowania się w niezaufanej strefie, np. w publicznie dostępnej sieci, lub w pracy :). Aby skorzystać z tej funkcjonalności, musisz wiedzieć dwie rzeczy:

1. czy twój klient obsługuje proxy SOCKS 4/5,
2. jaki jest wolny port w systemie, który zostanie zajęty przez proxy.

Klient, który łączy się z serwerem sshd otwiera port na lokalnej maszynie, podany przez użytkownika. Każdy klient (www, ftp), który połączy się na ten port, będzie przy pomocy klienta ssh kontaktowany z serwerem sshd (na zewnętrznej maszynie), który to będzie trudnił się wysyłaniem i odbieraniem połączeń do hostów, z którymi chcesz kontaktować się w sposób nie uwzględniający twojego IP ;). Czy to jest przeglądarka WWW, czy klient e-mail, czy cokolwiek innego, jeśli potrafi korzystać z protokołu SOCKS i jeśli aktywność którą chcesz wykonać mieści się w granicach akceptowanych przez ten protokół, powinno działać.

Krok pierwszy to użycie funkcji tunelu ssh polecenia ssh:

Czym jest user i host, to wiadomo, jest to docelowy serwer na którym mamy konto ssh. Port jest to port na lokalnej maszynie, czyli tej, z której uruchamiasz polecenie ssh. Przykładowo:

Podane wyżej polecenie otworzy tunel ssh na porcie 8080, wykorzystując przy tym sshd z hosta 192.168.0.16. Oczywiście najpierw musisz się poprawnie zalogować i dotrzeć do momentu wyświetlenia znaku zachęty. Sesja otwarta z argumentem -D nie różni się od sesji bez -D, z wyjątkiem tego, że -D otwiera dodatkowy port na naszej maszynie. Możesz to sprawdzić poleceniem netstat:

Można to przetestować na przeglądarce WWW, np. Google Chrome. Wyprzedzając pytanie, Opera wydaje się nie supportować proxy SOCKS, a przynajmniej do wersji 10. Dalszych wersji nie widziałem i od jakiegoś czasu nie żałuję ;).

Chrome lub Firefox posiadają domyślne ustawienia proxy pozwalające na wpisanie tylko jednego serwera proxy. Posiadają też jednak przydatne rozszerzenia (Chrome: ProxySwitchy, Firefox: FoxyProxy), które pozwalają na dodanie wielu serwerów, jednocześnie udostępniają możliwość sprecyzowania, które odwiedzone strony będą korzystać z którego serwera proxy. Tak więc, po dodaniu serwerów A i B, możesz skonfigurować je tak, by np. serwis wp.pl był odwiedzany przy wykorzystaniu serwera A, natomiast onet.pl przy wykorzystaniu serwera B. Przydatny jest szczególnie plugin FoxyProxy, który posiada swój odpowiednik także w Thunderbirdzie; tak więc maile do poszczególnych osób można wysyłać przez z góry określone serwery proxy. To w przypadku gdybyś kiedykolwiek bawił się w tworzenie avatarów, czyli sztucznie wyhodowanych osobowości w necie, służących do zyskiwania różnych informacji z różnych grup „społecznych” ;).

Inna rzecz jest taka, że jeśli korzystasz z mniej rozpopularyzowanego (aby nie powiedzieć „nieznanego”, ponieważ nie byłoby to prawdą) środowiska graficznego, typu np. xfce, Chrome może nie wiedzieć, jak wykorzystać globalne ustawienia proxy. ProxySwitchy też może mieć problem z taki xfce, dlatego też wrzucę kilka shotów z wyjaśnieniem w jaki sposób skonfigurować FoxyProxy w Firefoksie.

Najpierw należy zainstalować to rozszerzenie z repozytorium rozszerzeń Firefox.

Po poprawnej instalacji, kliknij PPM na ikonę FoxyProxy w „tray area” Firefox'a dla pluginów i wybierz tryb „Proxy według wzorców i priorytetów”. Jest to najbardziej inteligentny tryb działania, w którym FoxyProxy będize na podstawie wpisanych reguł dobierał odpowiednie proxy dla danej witryny.

Kolejny krok to wejście do opcji (PPM na ikonę, Opcje). Trzeba teraz dodać nowe proxy, więc kliknij „Dodaj nowe proxy”, aby otworzyć okno dodawania nowego serwera.

W nowym oknie, w polu Serwer lub Adres IP wpisz „localhost” i podaj odpowiedni port, czyli w naszym przypadku będzie to 8080. Nie zapomnij też zahaczyć pola „Proxy SOCKS”, ponieważ z tego protokołu korzysta tunel ssh ustanowiony przez program ssh.

Następnie, na sąsiedniej zakładce „Adresy URL wzorców”, dodaj wzorce dla stron, które chcesz oglądać przez proxy. Klikając „Dodaj nowy wzorzec” pojawi się małe okienko, w którym wpisz: nazwę wzorca (cokolwiek, ta informacja jest tylko dla ciebie), oraz Wzorzec URL, którego strukturę możesz wybrać przez użycie radioboxa na dole okna – może to być zwykły wildcard (czyli znaki * i ?), lub wyrażenie regularne. Dla prostoty wybieramy wildcard (czyli Wieloznacznik) i wpisujemy pierwszą (i na razie jedyną) regułę wskazującą na serwis whatsmyip.org. Dobrą regułą może być np. „*whatsmyip*”, choć dla dłuższego użycia może okazać się nieco zbyt ogólna (w końcu reguła ta złapie nawet adresy stron, które w argumencie będą miały string „whatsmyip”).

Teraz, po zamknięciu wszystkich okien i zatwierdzeniu zmian, wejdź na stronę www.whatsmyip.org, aby zobaczyć, że podaje ona adres twojego serwera proxy, a nie twój. Dodatkowo, sprawdź wejście na inny serwis podający IP – np. whatismyip.org (zwróć uwagę na dodatkowe „i” w nazwie hosta), aby upewnić się, że host ten poda twój prawdziwy numer ip, ponieważ FoxyProxy nie posiada reguły na ten host.

Proxy zrobione przez tunel ssh ma jedną oczywistą zaletę w postaci braku nagłówków charakterystycznych dla nieanonimowych serwerów proxy, oraz to, że brak standardowo otwartego portu powszechnie ustanowionego dla publicznych serwerów proxy uniemożliwia działanie usługom sprawdzającym, czy host, który się z takimi usługami łączy, nie jest przypadkiem otwartym serwerem proxy. Przy pomocy tunelu ssh serwerem proxy jest maszyna, która technicznie nie ma uruchomionej żadnej usługi proxy, więc nikt żadnego proxy raczej nie ma szans wykryć ;).

Kopiowanie plików

Czyli inaczej: scp.

Nie trzeba mieć serwera ftp, aby móc wymieniać się plikami z innymi maszynami. Wystarczy dostęp przez ssh; transfer plików można wywołać poleceniem scp. Scp to skrót od secure copy i jest dokładnie tym, na co wskazuje nazwa – bezpiecznym sposobem przesyłania danych binarnych. Prędkość oczywiście jest nieco niższa od zwykłych metod kopiowania, ale nie o to tutaj chodzi ;).

Jest to metoda dość przydatna, gdy posiadasz dostęp ssh do swojego hostingu, jednak usługodawca monitoruje ruch wyjściowy http i ftp, zmuszając cię do ograniczeń typu kilka GB miesięcznie (za naprawdę tani hosting). Czasami jednak usługodawca nie monitoruje ruchu ssh, więc dlaczego by nie wykorzystać tej luki prawnej i nie pościągać kilku plików przez scp?

To chyba jest też dobre miejsce na to, aby dodać, że oczywiście nie wspieram piractwa, naginania reguł, ani żadnych rzeczy które nie mieszczą się w granicy dobrego smaku z punktu widzenia administratora systemu, a jedynie przekazuję informacje o tej metodzie w celu uświadomienia administratorów o konieczności monitorowania ruchu ssh ;). Tak więc, jeśli jesteś użytkownikiem systemu, zachęcam do skontaktowania się z usługodawcą i o poinformowaniu go o znalezionej luce. Przy okazji kup też dywanik Allaha i odmów na nim kilka modlitw, ponieważ będzie to też dobra szansa na to, by stracić konto ssh...

Składnia wywołania scp jest bardzo podobna do samego ssh i działa w sumie na takiej samej zasadzie.

Można sprawdzić, czy plik został przesłany prawidłowo (bsdv to maszyna pod IP 192.168.0.16):

Właściwie to tyle. Jeśli chodzi o przesłanie jednego pliku, scp spisuje się całkiem nieźle. Jeśli jednak chodzi o nieco bardziej zaawansowaną manipulację na plikach z zewnętrznego hosta, z pomocą przychodzi montowanie zdalnego katalogu do lokalnego system plików przez protokół ssh, o czym mówi kolejny rozdział.

System plików

Czyli: sshfs.

Zdalne montowanie systemu plików najbardziej popularne jest przy wykorzystaniu protokołów CIFS/SMB, czyli standardowego Windowsowego udostępniania plików przy pomocy Samby, oraz czysto-unixowego NFS (czyli Network File System, nie Need For Speed). W innych sytuacjach, np. po wykupieniu hostingu z ssh od jakiegoś taniego usługodawcy, raczej mało możliwe jest nakłonienie administratorów do skonfigurowania tych protokołów, natomiast samemu, bez uprawnień root, zrobić się tego nie da. Istnieje jednak możliwość montowania systemu plików przez protokół ssh, i o tym w tym rozdziale.

„fuse” to jest framework udostępniający API do łatwego tworzenia swoich wirtualnych systemów plików. Zawiera bindingi do wielu skryptowych języków programowania, np. perl. Istnieje wiele projektów korzystających z tego frameworka, np. MP3FS, który rzeczywiste pliki .flac przedstawia jako pliki .mp3, konwertując je na rzeczywisty format .mp3 podczas odczytu pliku .flac, lub też BloggerFS, który wykorzystując API Bloggera robi z notek system plików - dzięki temu można je manipulować poleceniami typu ls, cat, vim.

Projekt, który przyda się naszym celom, nazywa się sshfs i jest to system plików frameworka fuse, który tworzy system plików na podstawie danych odebranych przez ssh.

sshfs powinien znajdować się w repozytoriach Ubuntu lub Linux Mint, więc nie powinno przysporzyć to problemów. Inne dystrybucje na pewno mają swoje rozwiązania w tej materii ;).

Po instalacji można wypróbować montowanie katalogu np. takim poleceniem (syntaktycznie zbliżonym do scp):

Polecenie to zamontuje zdalną ścieżkę /home/aprime z maszyny 192.168.0.16, logując się do zdalnego systemu przez ssh jako użytkownik aprime, do lokalnego katalogu test. Jeśli nie zrobiłeś bezhasłowego logowania, zostaniesz zapytany o hasło (tylko raz, na początku), w przeciwnym wypadku logowanie powinno zostać zakończone pomyślnie bez potrzeby podawania hasła.

Plik /etc/mtab twierdzi, że katalog test jest zamontowany poprawnie:

tak więc można kopiować pliki między dwoma maszynami w tak prosty sposób, jak przez korzystanie z polecenia cp, lub też przez zwyczajne kopiowanie z katalogu do katalogu przez twoje ulubione środowisko graficzne.

fuse oczywiście potrafi o wiele więcej, polecam zerknąć na stronę przykładowych systemów plików. Niektóre z nich spowodują zmianę sposobu myślenia o systemie plików i otworzą nową drogę w wyobraźni, która – jak się zapewne okaże – zawsze tam była, jednak na jej początku znajdowały się przejścia zabite deskami, z przybitym skrawkiem papieru wymalowanym od początku do końca czarnym węglem układającym się w logo Windows ;).