SSH reverse proxy

Spis treści

1. Zastosowania odwróconego proxy
2. Jak działa reverse proxy
3. Wymagania wstępne
4. Konfiguracja klienta – Raspberry Pi
5. Konfiguracja serwera VPS – wersja podstawowa
6. Konfiguracja serwera VPS – wersja bezpieczniejsza
7. Tworzenie tunelu
8. Konfiguracja laptopa i nawiązanie połączenia
9. Inne zastosowania tuneli SSH
10. Podsumowanie

Motywacja

Coraz więcej producentów gospodarstwa domowego oferuje urządzenia określane mianem „inteligentnych”. Typowo, urządzenia te można sterować za pomocą aplikacji mobilnej, przykładowo roboty sprzątające czy zdalnie sterowane klimatyzatory. Takie rozwiązania wymagają zapewnienia przesyłania danych na serwer oraz odbierania komend sterujących przez urządzenia.

W związku z ograniczonym przyjęciem protokołu IPv6 i wyczerpywaniem się puli adresów IPv4 zgodnie z RFC 1918, stosowana jest translacja adresów sieciowych (NAT) umożliwiająca połączenie większej ilości urządzeń do internetu przy ograniczonej liczbie dostępnych adresów IP. Dla bezpośredniego połączenia z urządzeniem za routerem, możliwe jest przekierowanie zewnętrznego portu na specyficzny port i adres wewnątrz sieci, co jednak wymaga dostępu do konfiguracji routera. W przypadku sieci komórkowych, operatorzy często nie oferują możliwości konfiguracji routera przez klienta, uniemożliwiając przekierowanie ruchu sieciowego do konkretnych urządzeń.

Dodatkowym wyzwaniem jest zapewnienie użytkownikom bez technicznej wiedzy możliwości sterowania urządzeniami domowymi. Producenci zmuszeni są zatem oferować alternatywne metody dostępu do urządzeń w sieci lokalnej.

Inne urządzenia, jak projekty bazujące na mobilnych platformach (zdalnie sterowane roboty, drony, systemy w samochodach), wykorzystują modemy LTE do komunikacji. Bez odpowiednich umów z operatorem sieci, urządzenia te nie otrzymują publicznych adresów IP, co utrudnia zdalny dostęp.

Zastosowania odwróconego proxy w zarządzaniu dostępem do urządzeń za NAT w różnych środowiskach sieciowych

Aby umożliwić połączenie z urządzeniem ukrytym za routerem, gdzie stosowana jest translacja adresów (NAT), jedną z technik jest wykorzystanie odwróconego proxy. To rozwiązanie wymaga zastosowania zewnętrznego serwera pośredniczącego z publicznym adresem IP.

Proces komunikacji z urządzeniem ukrytym przedstawia się w następujących krokach, przy czym dla uproszczenia wprowadzono określenia poszczególnych elementów systemu:

• RaspberryPi (RPi) – urządzenie znajdujące się w wewnętrznej sieci za NAT, które nie posiada publicznego adresu IP, ale jest połączone z internetem, np. przez modem LTE.
• Server VPS – zewnętrzny serwer z publicznym adresem IP, który służy jako pośrednik. Dostęp do tego serwera wymaga uprawnień administracyjnych.
• Laptop – komputer osobisty w sieci lokalnej, również bez publicznego adresu IP.

W opisanej konfiguracji bezpośrednie połączenie z RaspberryPi z laptopa jest niemożliwe. Jednak oba urządzenia – RaspberryPi i laptop – mogą komunikować się z serwerem VPS.

Odwrócone proxy jest szczególnie użyteczne w środowiskach, gdzie urządzenia są podłączone przez sieci LTE, gdzie publiczne adresy IP często nie są dostępne. Umożliwia to zdalne zarządzanie urządzeniami, takimi jak sensory, kamery czy kontrolery przemysłowe, które działają w izolowanych środowiskach sieciowych.

Jak działa reverse proxy

Działanie odwrotnego tunelowania SSH przedstawia się w kilku krokach:

1. Nawiązanie połączenia SSH: Raspberry Pi, działające jako klient, inicjuje zabezpieczone i szyfrowane połączenie SSH z serwerem VPS, zwykle przez port 22.
2. Konfiguracja przekierowania portu: Podczas nawiązywania połączenia, Raspberry Pi konfiguruje serwer VPS, aby przekierowywał ruch przychodzący na port 35000 do określonego portu lokalnego na Raspberry Pi. Realizowane jest to za pomocą opcji -R w poleceniu SSH:
   • ssh -R 35000:localhost:local_port user@vps_server Gdzie 35000 to port na serwerze VPS oczekujący na połączenia, a localhost:local_port oznacza, że ruch na ten port będzie tunelowany do local_port na Raspberry Pi.
3. Przekazywanie ruchu przez tunel: Po ustanowieniu połączenia wszystkie dane przychodzące do portu 35000 na serwerze VPS są automatycznie przekazywane do Raspberry Pi. Dane mogą być różnorodne, od żądań HTTP, przez połączenia TCP, po inne typy danych, wszystkie szyfrowane i przesyłane przez SSH.
4. Działanie tunelu: Przesyłany ruch porusza się przez otwarty tunel SSH, gdzie SSH służy jako proxy. Odbiera dane na porcie 35000 na VPS i przekazuje je do Raspberry Pi. Odpowiedzi z Raspberry Pi są przesyłane w przeciwnym kierunku przez ten sam tunel do serwera VPS, a stamtąd do pierwotnego żądającego klienta.
5. Zamknięcie tunelu: Gdy połączenie SSH zostaje zakończone, przekierowanie portów jest anulowane i tunel zostaje zamknięty. Raspberry Pi jest odpowiedzialne za utworzenie i utrzymanie tego tunelu.

Wymagania wstępne przed przystąpieniem do konfiguracji tunelu

Przed rozpoczęciem konfiguracji reverse proxy, konieczne jest spełnienie następujących warunków:

1. Dostępność publicznego serwera: Serwer musi być aktywny i dostępny z internetu. Można wykorzystać dowolny serwer VPS oferowany przez operatorów usług chmurowych. Ważne, aby serwer miał stabilne połączenie internetowe i odpowiednią konfigurację sieci.
2. Uprawnienia administracyjne: Osoba konfigurująca tunel musi posiadać uprawnienia administracyjne na zdalnym serwerze. To oznacza możliwość zarządzania ustawieniami serwera, w tym instalacją oprogramowania i modyfikacją konfiguracji firewalla.
3. Instalacja serwera SSH: Na serwerze musi być zainstalowany i uruchomiony serwer SSH (np. OpenSSH), który umożliwia zdalną administrację. Serwer SSH powinien być skonfigurowany do akceptowania połączeń z zewnątrz i odpowiednio zabezpieczony.

Należy upewnić się, że wszystkie te wymagania są spełnione przed przystąpieniem do dalszych kroków konfiguracyjnych, aby zapewnić płynność i bezpieczeństwo procesu.

Konfiguracja klienta – Raspberry Pi

Aby Raspberry Pi mogło pełnić rolę klienta tworzącego tunel, konieczne jest zainstalowanie serwera OpenSSH. Instalacja może być wykonana za pomocą następującego polecenia:

sudo apt install -y openssh-server

Instalacja ta umożliwia inicjowanie bezpiecznych połączeń SSH do Raspberry Pi.

Generowanie kluczy SSH

Następnym etapem jest wygenerowanie pary kluczy SSH, które będą służyć do nawiązywania zabezpieczonych połączeń z serwerem VPS. Proces generowania kluczy realizowany jest przy użyciu polecenia ssh-keygen:

ssh-keygen -t ed25519 -C "rpi@remote_machine.com"

W wyniku tego procesu w katalogu domowym ~/.ssh zostaną stworzone dwa pliki:

• id_ed25519 – klucz prywatny, który powinien być chroniony, gdyż umożliwia dekryptację komunikacji zaszyfrowanej przy użyciu klucza publicznego.
• id_ed25519.pub – klucz publiczny, używany do autoryzacji na serwerze VPS.

Opcjonalnie, podczas generowania klucza można dodać hasło (passphrase), które zwiększa bezpieczeństwo klucza prywatnego. Jednakże, w kontekście automatyzacji, jak automatyczne tworzenie tunelu przez systemd przy starcie systemu, dodanie hasła może skomplikować proces, gdyż każdorazowe nawiązywanie połączenia wymagałoby jego podania. W związku z tym, w przypadkach, gdzie priorytetem jest automatyzacja, zaleca się pominięcie tego kroku, co można uczynić przez naciśnięcie enter przy monicie o hasło.

Po wygenerowaniu kluczy, zawartość pliku id_ed25519.pub powinna zostać dodana do pliku authorized_keys na serwerze VPS, co umożliwi zdalne połączenia bez konieczności używania hasła.

Konfiguracja serwera VPS – wersja podstawowa

W tej sekcji przedstawiona została podstawowa konfiguracja serwera VPS niezbędna do utworzenia tunelu SSH. Dla zastosowań wymagających podwyższonego poziomu bezpieczeństwa, zaleca się przejście do sekcji „Konfiguracja serwera VPS – wersja rozszerzona”, gdzie omówiono wykorzystanie konteneryzacji jako dodatkową warstwę zabezpieczeń.

Konfiguracja firewalla

Domyślna konfiguracja serwera OpenSSH często nie obejmuje możliwości tworzenia tuneli.

W pierwszej kolejności należy odblokować port który jest wykorzystywany do tunelowanie. Aby to zrobić, można użyć narzędzia ufw (Uncomplicated Firewall), które na systemie Debian 12 instaluje się za pomocą polecenia:

sudo apt install -y ufw

Weryfikacja reguł firewalla

Sprawdzenie aktywnych reguł firewalla umożliwia polecenie:

sudo ufw status verbose

Przykładowy wynik może wyglądać następująco:

Status: active
Logging: on (low)
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip

To                         Action      From
--                         ------      ----
30022/tcp                  ALLOW IN    Anywhere
30022/tcp (v6)             ALLOW IN    Anywhere (v6)

Port 30022 jest tu przykładem niestandardowego portu SSH. W celu zwiększenia bezpieczeństwa zaleca się stosowanie niestandardowych portów.

Otwarcie portów firewalLa

Aby przygotować serwer do komunikacji przez dodatkowy port wykorzystywany jako tunel:

sudo ufw allow 44555/tcp
sudo ufw reload

Ta konfiguracja otwiera port 44555 dla połączeń TCP, co umożliwi korzystanie z niego jako punktu wejścia tunelu.

Modyfikacja konfiguracji SSHD

Domyślne ustawienia serwera SSH nie pozwalają na otwieranie tuneli. Należy zatem zmodyfikować plik /etc/ssh/sshd_config i upewnić się, że zawiera on:

• AllowTcpForwarding yes
• GatewayPorts yes
• PermitTunnel yes

Po wprowadzeniu zmian, restart serwera SSH jest konieczny:

sudo systemctl restart sshd

Stworzenie konta dla urządzenia

Konieczne jest utworzenie konta użytkownika na serwerze VPS, które będzie używane do inicjowania tunelu. W tym celu jako nazwę użytkownika wybrano rpi które pomoże jednoznacznie zidentyfikować urządzenie.

adduser --disabled-password --gecos "" rpi

Konto to będzie dostępne wyłącznie przez uwierzytelnianie kluczem SSH.

Utworzenie i konfiguracja pliku authorized_keys

W katalogu domowym nowo utworzonego użytkownika rpi, należy przygotować plik authorized_keys, który będzie zawierał klucze publiczne uprawnione do logowania:

sudo mkdir -p /home/rpi/.ssh
sudo touch /home/rpi/.ssh/authorized_keys
sudo chown rpi:rpi -R /home/rpi/.ssh

Dopisanie kluczy dla użytkownika

Do pliku authorized_keys należy dodać zawartość pliku id_ed25519.pub wygenerowanego na Raspberry Pi, co umożliwi bezhasłowe połączenia SSH.

Weryfikacja konfiguracji

Po konfiguracji kluczy, próba logowania z Raspberry Pi do serwera VPS powinna być wykonana za pomocą:

ssh rpi@adres_serwera_vps -p 30022

Prawidłowe dodanie kluczy umożliwi logowanie bez potrzeby wprowadzania hasła.

Zabezpieczenie serwera przed nieautoryzowanym dostępem

Ostatecznie, konfiguracja pliku authorized_keys na serwerze VPS powinna być dostosowana, by ograniczyć możliwości działania po zalogowaniu:

command="/bin/false",no-pty,no-X11-forwarding,permitopen="localhost:44555" ssh-ed25519 AAAAC3Nz...

Te ustawienia zapewniają, że połączenie przez SSH służy wyłącznie do otwarcia tunelu, bez możliwości interaktywnego logowania.

Po zapisaniu tych zmian, należy przetestować konfigurację, sprawdzając, czy próba zalogowania się do systemu kończy się od razu zamknięciem połączenia:

PTY allocation request failed on channel 0
Connection to vps-address.ovh.net closed.

Tak skonfigurowany serwer VPS jest gotowy do bezpiecznego tworzenia tuneli SSH, a dalsze szczegóły tworzenia tunelu znajdują się w kolejnej sekcji artykułu.

Konfiguracja serwera VPS – dodatkowa warstwa bezpieczeństwa: Podman

Uruchomienie każdej usługi na serwerze może obniżyć poziom bezpieczeństwa poprzez narażenie na ataki, które mogą wykorzystywać niezgłoszone lub nienaprawione błędy w oprogramowaniu. Dlatego warto rozważyć zastosowanie konteneryzacji, co dodaje kolejną warstwę zabezpieczeń. Konteneryzacja umożliwia izolację procesów, dzięki czemu nawet w przypadku kompromitacji konta używanego do tunelowania, atakujący znajdzie się w ograniczonym środowisku „wirtualnej maszyny”, nie mając dostępu do systemowych plików serwera.

Konfiguracja firewalla

Przed rozpoczęciem konfiguracji kontenera należy odpowiednio przygotować firewall, aby otworzyć porty niezbędne do połączenia z kontenerem i do tunelowania:

sudo ufw allow 50332/tcp
sudo ufw allow 50333/tcp
sudo ufw reload

Po wykonaniu polecenia, warto zweryfikować, czy porty zostały prawidłowo otwarte:

sudo ufw status verbose

Oczekiwany wynik powinien wskazywać, że porty 50332 i 50333 są otwarte dla połączeń przychodzących.

Instalacja Podmana

Jeśli na systemie nie jest zainstalowane narzędzie do konteneryzacji, można je zainstalować:

sudo apt install -y podman

Po zakończeniu instalacji można przystąpić do tworzenia obrazu.

Budowanie kontenera z obrazu Debian

Ze względu na zachowanie porządku w systemie, w katalogu domowym można stworzyć podkatalog zawierający konfigurację kontenerów co w przyszłości, w przypadku wykorzystania większej ich ilości ułatwi zarządzanie. W przypadku kontenera przeznaczonego do tunelowania przyjęto następującą strukturę katalogów w katalogu domowym:

.
└── podman
    └── reverse_proxy_rpi
        ├── Dockerfile
        └── ssh_files
            └── authorized_keys

W celu zbudowania prawidłowego kontenera umożliwiającego świadczenie usług tunelowania plik Dockerfile może przyjąć następującą formę:

FROM debian:stable
RUN apt update && \
	apt -y install openssh-server && \
	echo "PermitTunnel yes\n\
	GatewayPorts yes\n\
	AllowTcpForwarding yes\n\
	PubkeyAuthentication yes\n\
	PasswordAuthentication no\n" >> /etc/ssh/sshd_config && \
	adduser --disabled-password --gecos "" rpi && \
	sed -i 's/^rpi:!*/rpi:/' /etc/shadow && \
	mkdir -p /home/rpi/.ssh && \
	chown -R rpi:rpi /home/rpi/.ssh && chmod 700 /home/rpi/.ssh && \
	ssh-keygen -A && \
	mkdir /run/sshd
	
EXPOSE 22
EXPOSE 50333
CMD ["/usr/sbin/sshd", "-D"]

Konfiguracja ta ustawia wszystkie wymagane parametry dla serwera openssh, tworzy użytkownika, generuje klucze, otwiera wymagane porty oraz wskazuje usługę sshd jako aplikację która ma działać w ramach kontenera.

Budowanie obrazu

W celu zbudowania obrazu na podstawie stworzonego pliku Dockerfile należy wykonać polecenie:

podman build -t rpi-ssh-proxy .

• podman build – jest to komenda inicjująca proces budowania obrazu kontenera.
• -t rpi-ssh-proxy – opcja -t, znana również jako --tag, umożliwia nadanie etykiety (tagu) budowanemu obrazowi. W tym kontekście, obraz jest oznaczony jako rpi-ssh-proxy, co ułatwia jego identyfikację oraz zarządzanie wersjami.
• . – symbol ten wskazuje na katalog, w którym znajduje się Dockerfile. Kropka reprezentuje bieżący katalog roboczy, z którego podman pobiera plik definicji do budowy obrazu.

Przygotowanie katalogu z kluczami dla serwera openssh

Aby umożliwić łatwą modyfikację konfiguracji urządzeń korzystających z tunelu, zalecane jest wykorzystanie zewnętrznego pliku authorized_keys, który będzie przechowywał listę autoryzowanych kluczy SSH. Plik ten powinien znajdować się w katalogu ssh_files, który zostanie podmontowany do wewnątrz kontenera. Takie rozwiązanie pozwala na zmiany konfiguracyjne bez konieczności restartowania usług. Procedura przygotowania wymaganego katalogu i pliku prezentuje się następująco:

mkdir -p ~/podman/reverse_proxy_rpi/ssh_files
touch ~/podman/reverse_proxy_rpi/ssh_files/authorized_keys

Tworzenie tego katalogu i pliku authorized_keys zapewnia, że klucze SSH mogą być łatwo zarządzane i aktualizowane, co jest kluczowe w utrzymaniu bezpieczeństwa połączeń SSH.

Dystrybucja kluczy

Do pliku authorized_keys, który znajduje się w katalogu ssh_files wewnątrz kontenera, powinien zostać dopisany klucz publiczny wygenerowany na RaspberryPi. Klucz ten jest niezbędny do nawiązania zabezpieczonego połączenia SSH z kontenerem przez serwer VPS. Proces ten umożliwia konfigurację tunelu.

Uruchomienie kontenera

Po zakończeniu konfiguracji należy uruchomić kontener. W tym celu można wykorzystać następujące polecenie:

podman run -d --name rpi-ssh-proxy -v /home/debian/podman/reverse_proxy_rpi/ssh_files:/home/rpi/.ssh:Z -p 50333:50333 -p 50332:22 rpi-ssh-proxy

• podman run -d – oznacza, że kontener ma zostać uruchomiony w trybie demona.
• --name rpi-ssh-proxy – nazwa dla tworzonego kontenera,
• -v /home/debian/podman/reverse_proxy_rpi/ssh_files:/home/rpi/.ssh:Z – powoduje „podmontowanie” katalogu /home/debian/podman/reverse_proxy_rpi/ssh_files wewnątrz kontenera jako /home/rpi/.ssh.
• -p 50333:50333 przekierowuje port VPSa na kontener. Port ten jest wykorzystywany do tunelowania połączenia.
• -p 50332:22 przekierowuje port 50332 VPSa, na port 22 w kontenerze. Port ten jest używany do zdalnej konfiguracji serwera SSH, w tym przypadku do ustanowienia tunelu. Poprzez ten port, serwer SSH działający w kontenerze na VPS m.in. jest instruowany na jakim porcie powinien zostać otwarty tunel.
• rpi-ssh-proxy na końcu oznacza nazwę obrazu, który jest używany do stworzenia kontenera.

Autostart kontenera

Podman integruje się z systemd poprzez generowanie jednostek systemd, które mogą zarządzać cyklem życia kontenerów i usług. Proces ten polega na wygenerowaniu pliku .service dla kontenera, który później może być kontrolowany przez systemd.

1. Generowanie pliku usługi systemd dla kontenera: W pierwszej kolejności należy uruchomić kontener (polecenie zostało opisane w poprzedniej sekcji), a następnie wykonać polecenie podman generate systemd, aby stworzyć plik usługi systemd dla tego kontenera. Na przykład:

podman generate systemd --name rpi-ssh-proxy --files --new

Polecenie tworzy plik .service, który można następnie umieścić w odpowiednim katalogu systemd.

2. Włączenie usługi systemd: Po umieszczeniu pliku usługi w katalogu /etc/systemd/system/, należy włączyć usługę, aby startowała automatycznie przy uruchamianiu systemu:

sudo systemctl enable rpi-ssh-proxy.service

3. Uruchamianie usługi: Usługę można również od razu uruchomić za pomocą:

sudo systemctl start rpi-ssh-proxy.service

Tworzenie tunelu

Inicjacja tunelu SSH jest kluczowym elementem procesu zapewniającym zdalny dostęp do systemu. Uruchamianie tunelowania jest zadaniem klienta, którego głównym celem jest umożliwienie bezpiecznego logowania przez zewnętrznych użytkowników. W tym kontekście, zaleca się wykorzystanie narzędzia autossh. Autossh, będąc rozszerzeniem standardowego klienta SSH, automatycznie odnawia połączenia, co jest istotne w sytuacjach, gdy istnieje ryzyko niestabilności sieci lub przypadkowego przerwania sesji.

Program autossh poprzez ciągłe monitorowanie i odnawianie połączeń znacząco zwiększa niezawodność i stabilność zdalnej sesji administracyjnej. Jego zastosowanie jest szczególnie rekomendowane w środowiskach wymagających wysokiej dostępności, co stanowi kluczowy czynnik w efektywnym i bezpiecznym zarządzaniu infrastrukturą informatyczną.

Implementacja autossh jest więc nie tylko wskazana, ale często niezbędna do zapewnienia ciągłości operacyjnej systemów i usług informatycznych, minimalizując ryzyko przerw w dostępie spowodowanych problemami z połączeniem sieciowym, takimi jak utrata zasięgu LTE.

Żeby zainstalować narzędzie, należy wykonać polecenie:

sudo apt install -y autossh

Po zakończeniu instalacji, można przystąpić do uruchomienia tunelu:

autossh -f -N -R 50333:localhost:22 rpi@vps-address.ovh.net -p 50332 -o ServerAliveInterval=60 -o ServerAliveCountMax=10 -M 0

Poniżej znajduje się opis poszczególnych parametrów:

• -f — uruchomienie autossh w tle.
• -N — informuje autossh, aby nie wykonywał żadnych poleceń po zalogowaniu, tylko utrzymywał tunel.
• -R 50333:localhost:22 — konfiguruje tunel zdalny, przekierowujący ruch z portu 50333 na zdalnym serwerze na port 22 lokalnego hosta (SSH).
• rpi@vps-address.ovh.net — nazwa użytkownika i adres serwera, na którym ma zostać ustanowiony tunel.
• -p 50332 — port zdalnego serwera, na którym nasłuchuje SSH.
• -o ServerAliveInterval=60 — opcja autossh wysyła sygnał przez tunel co 60 sekund, aby upewnić się, że połączenie jest aktywne.
• `-o ServerAliveCountMax=10 — maksymalna ilość prób utrzymania połączenia przed rozłączeniem.
• -M 0 — dezaktywuje domyślny monitoring portów autossh i korzysta wyłącznie z mechanizmów SSH do sprawdzania żywotności połączenia.

Konfiguracja automatycznego ustanawiania tunelu

Aby zapewnić automatyczne zestawienie tunelu np. w przypadku restartu można stworzyć plik konfiguracyjny wykorzystywany przez systemd:

[Unit]
Description=AutoSSH tunnel service for Remote Port Forwarding
After=network.target

[Service]
User=rpi ExecStart=/usr/bin/autossh -f -N -R 50333:localhost:22 rpi@vps-address.ovh.net -p 50332 -o ServerAliveInterval=60 -o ServerAliveCountMax=10 -M 0
Restart=always
RestartSec=30

[Install]
WantedBy=multi-user.target

W pliku tym wykorzystano m.in. opcje: Restart=always oraz RestartSec=30. Powoduje to, że w przypadku rozłączenia, serwis jest automatycznie uruchamiany ponownie po 30 sekundach od jego zakończenia. Dzięki temu, w przypadku awarii sieci połączenie jest przywracane automatycznie po przywróceniu dostępu do internetu.

Konfiguracja laptopa

Klient który uzyskuje dostęp do zdalnego urządzenia nie wymaga specjalnej konfiguracji. Wymagane jest natomiast wygenerowanie pary kluczy, oraz przekazanie ich do docelowego urządzenia – w tym przypadku do RaspberryPi.

Żeby wygenerować klucze można wykorzystać program ssh-keygen. Przykład użycia można znaleźć w sekcji Generowanie Kluczy SSH.

Ostatnim krokiem jest dodanie klucza do pliku authorized_keys znajdującego się na docelowym urządzeniu oraz połączenie się z nim za pośrednictwem serwera VPS.

Jeżeli na RaspberryPi plik ~/.ssh/authorized_keys nie istnieje, należy go utworzyć oraz wpisać do niego zawartość klucza publicznego wygenerowanego na laptopie.

W celu nawiązania połączenia ze zdalnym urządzeniem, używamy polecenia:

ssh raspberry@vps-address.ovh.net -p 50333

Warto zwrócić uwagę, że podczas logowania wykorzystywana jest nazwa użytkownika na urządzeniu za firewallem (raspberry), jako adres użyto domenę VPSa (vps-address.ovh.net). Poprzez wybór portu 50333 połączenie do VPSa zostanie przekierowane przez utworzony tunel do RaspberryPi.

Użytkownik logujący przez tunel, nie musi posiadać konta na serwerze VPS, natomiast musi je posiadać na docelowym urządzeniu – do którego połączenie tunelowe prowadzi. Dotyczy to połączenia z wykorzystaniem protokołu SSH.

Inne zastosowania tuneli SSH

Tunel SSH nie ogranicza się wyłącznie do bezpiecznego zdalnego logowania przez port SSH (22). Może również być skonfigurowany do przekierowywania ruchu na inne porty, co rozszerza jego zastosowanie na różne usługi sieciowe. Przykładem jest przekierowanie na port 80, które umożliwia dostęp do serwera WWW hostowanego na maszynie bez publicznego adresu IP.

Komunikacja pomiędzy serwerem VPS a docelowym klientem jest zaszyfrowana przy użyciu kluczy SSH, zapewniając bezpieczeństwo danych przesyłanych przez tunel, niezależnie od typu przekierowywanego ruchu.

Przykład: Dostęp do serwera WWW przez tunel SSH

Aby uzyskać dostęp do serwera WWW przez tunel SSH, można skonfigurować tunel przekierowujący ruch z portu na VPS-ie na port serwera WWW (zwykle port 80) na urządzeniu docelowym. Oto przykładowe polecenie używające autossh, które zapewnia stabilność połączenia dzięki automatycznemu ponownemu łączeniu:

autossh -f -N -R 50333:localhost:80 rpi@vps-address.ovh.net -p 50332 -o ServerAliveInterval=60 -o ServerAliveCountMax=10 -M 0

W tym przypadku port 50333 na serwerze VPS jest używany do przekierowania ruchu na lokalny port 80 urządzenia Raspberry Pi. Dzięki temu użytkownicy mogą uzyskać dostęp do serwera WWW za pośrednictwem adresu i portu VPS, jak gdyby był to serwer publicznie dostępny.

Podsumowanie

Tunelowanie SSH to bezpieczna i elastyczna technika, która umożliwia zdalny dostęp do różnorodnych usług sieciowych na urządzeniach znajdujących się za NATem lub w innych ograniczonych środowiskach sieciowych. Jest to nie tylko narzędzie umożliwiające zdalne logowanie i administrację poprzez SSH, ale również technika, która może służyć do bezpiecznego tunelowania innych protokołów takich jak MQTT, WWW, SMTP, FTP, i wiele innych.

Zastosowanie tunelu SSH oferuje kilka istotnych korzyści:

• Bezpieczeństwo: Wszystkie dane przesyłane przez tunel SSH są zaszyfrowane, co chroni przed atakami typu „man-in-the-middle” i innymi zagrożeniami związanymi z przesyłaniem danych przez internet.
• Przezroczystość: Dla aplikacji korzystających z przekierowanego ruchu tunel SSH jest transparentny, co oznacza, że mogą one działać bez żadnych zmian w konfiguracji czy kodzie.
• Wszechstronność: SSH pozwala na przekierowanie niemal każdego rodzaju ruchu TCP i może być konfigurowane do obsługi wielu różnych scenariuszy, co czyni go niezwykle przydatnym w złożonych środowiskach IT.

Przykłady zastosowań tunelu SSH ilustrują, jak może on pomagać w utrzymaniu ciągłości działania i bezpieczeństwa operacji, nawet gdy bezpośredni dostęp do urządzenia jest ograniczony lub niemożliwy. Wdrażanie tunelowania SSH w infrastrukturze informatycznej nie tylko zwiększa możliwości zdalnego dostępu i zarządzania, ale także podnosi ogólny poziom bezpieczeństwa stosowanych rozwiązań.