Generator komend tunelu SSH
Generuj komendy SSH tunnel: Local Port Forwarding, Remote Port Forwarding, Dynamic (SOCKS proxy). Kopiuj gotowe komendy.
-
1Wprowadź dane
Wpisz treść, wklej tekst lub załaduj plik z dysku. -
2Kliknij przycisk
Narzędzie natychmiast przetworzy Twoje dane w przeglądarce. -
3Pobierz wynik
Skopiuj gotowy tekst lub zapisz plik na urządzeniu.
return "Wynik gotowy w 0.1s";
}
Typ tunelu
Przekierowanie lokalne: port na Twoim komputerze → host:port w sieci serwera SSH
Port lokalny
adres nasłuchu na Twojej maszynie: 127.0.0.1
Port docelowy
dla SOCKS (-D) port docelowy nie istnieje
Jak tego użyć
- Przekierowanie lokalne: połącz się z 127.0.0.1:15432 na swoim komputerze, aby dotrzeć do 10.0.0.15:5432 w sieci serwera SSH.
Jak przetestować
Test nasłuchu: ss -lnt | grep 15432Test połączenia: nc -vz 127.0.0.1 15432
Domyślny 127.0.0.1 (lub localhost) nasłuchuje tylko na Twojej maszynie — tunel widzi wyłącznie lokalny użytkownik. Wpis 0.0.0.0 albo adres karty sieciowej otwiera port dla całej sieci: przy -L i -D od razu (plus firewall), a przy -R dodatkowo zależy od ustawienia GatewayPorts w sshd serwera. Zostawiaj bind na localhost, chyba że świadomie udostępniasz tunel innym hostom.
Fragmenty -L/-R/-D pochodzą z tego samego silnika, który buduje wynik narzędzia (na danych domyślnych: bastion.example.com, port lokalny 15432, baza 10.0.0.15:5432).
| Tryb | Składnia (z silnika) | Do czego służy |
|---|---|---|
| Przekierowanie lokalne (-L) | -L 127.0.0.1:15432:10.0.0.15:5432 | port na Twoim komputerze (adres nasłuchu:port lokalny) dociera do host:port w sieci serwera SSH — np. baza słuchająca tylko na localhost serwera |
| Przekierowanie zdalne (-R) | -R 127.0.0.1:5432:127.0.0.1:15432 | port po stronie serwera (adres nasłuchu na serwerze:port) wraca do host:port Twojej maszyny — np. webhook z internetu do lokalnego środowiska |
| Dynamiczny proxy SOCKS (-D) | -D 127.0.0.1:15432 | proxy SOCKS5 na adresie nasłuchu:port — ruch przeglądarki/aplikacji wychodzi z serwera SSH |
| Flagi wspólne | -N, -f, -p, -i, -J, -C, -o … | -N bez zdalnego polecenia, -f w tle, -p port SSH ≠ 22, -i plik klucza, -J host pośredni, -C kompresja, -o ExitOnForwardFailure=yes, -o ServerAliveInterval/CountMax (keepalive) |
| Przykład (z silnika) | ssh -i '~/.ssh/id_ed25519' -o ExitOnForwardFailure=yes -o ServerAliveInterval=60 -o ServerAliveCountMax=3 -N -f -L 127.0.0.1:15432:10.0.0.15:5432 '[email protected]' | kompletne polecenie dla domyślnych danych — cel w apostrofach przez escapeshellarg, klucz i opcje przed przekierowaniem |
Kolejność w poleceniu jest stała: ssh [-v] [-p port] [-i klucz] [-J jump] [-C] [-o …] -N [-f] PRZEKIEROWANIE cel — port SSH trafia do -p tylko, gdy różni się od 22, a dodatkowe argumenty z formularza doklejane są na końcu.
Warto wiedzieć — tunele SSH w praktyce
Który tryb wybrać?
-L, gdy chcesz się dostać do usługi siedzącej za serwerem (baza, panel administracyjny na localhost serwera). -R, gdy to serwer ma dotrzeć do Twojej maszyny (demo dla klienta, webhook do lokalnego deva). -D, gdy chcesz przekierować ruch wielu aplikacji naraz przez proxy SOCKS5.
Utrzymanie połączenia
Keepalive (ServerAliveInterval + ServerAliveCountMax) zapobiega rozłączaniu tuneli przez NAT i firewalle, a ExitOnForwardFailure=yes sprawia, że przy zajętych portach proces zakończy się błędem zamiast „udawać” działający tunel. Flaga -N bez zdalnego polecenia ogranicza ryzyko — tunel nie daje shella.
Testuj warstwami
Najpierw nasłuch (ss -lnt | grep PORT), potem połączenie TCP (nc -vz), na końcu prawdziwa aplikacja — dla SOCKS najlepiej curl --proxy socks5h://, bo przyrostek h wymusza rozwiązywanie DNS przez tunel. Polecenia testowe dla bieżącego trybu generuje sekcja „Jak przetestować”.
Klucze zamiast haseł
Długotrwałe tunele prowadź na kluczu (-i, najlepiej ed25519) bez hasła w poleceniu — historia shella nie powinna pamiętać sekretów. Dla tuneli w tle (-f) sprawdź proces ps aux | grep ssh i zamykaj go świadomie, zamiast zostawiać otwarte przekierowania na serwerze.
Oceń to narzędzie:
Powiązane narzędzia
Inne narzędzia, które mogą Ci się przydaćGenerator komend tunelu SSH — buduj polecenia SSH tunneling
Generator komend tunelu SSH pomaga tworzyć prawidłowe polecenia SSH do tunelowania portów — local forwarding, remote forwarding i dynamic (SOCKS proxy). Wybierz typ tunelu i uzupełnij parametry — gotowa komenda pojawi się natychmiast.
Czym jest tunelowanie SSH?
Tunelowanie SSH (SSH port forwarding) to technika przekazywania ruchu sieciowego przez zaszyfrowane połączenie SSH. Umożliwia: dostęp do usług niedostępnych z zewnątrz (za firewallem), bezpieczne połączenie z niezaszyfrowanymi protokołami (HTTP, FTP, Telnet), tworzenie SOCKS proxy do anonimowego przeglądania, dostęp zdalny do baz danych i wewnętrznych systemów.
Typy tuneli SSH
Local forwarding (-L) — przekazuje port lokalny na zdalny host przez serwer SSH. Składnia: ssh -L local_port:remote_host:remote_port user@ssh_server. Przykład: ssh -L 8080:internal-db:3306 [email protected] — port 8080 lokalnie dostaje się do MySQL na internal-db przez jumpserver. Remote forwarding (-R) — przekazuje port na serwerze SSH do Twojej maszyny lokalnej. Przykład: ssh -R 8080:localhost:80 [email protected] — udostępnia Twój lokalny serwer na porcie 80 przez server.com:8080. Przydatne do demonstracji i webhooka testowania. Dynamic forwarding (-D) — tworzy lokalny SOCKS proxy. ssh -D 1080 [email protected] — skonfiguruj przeglądarkę z SOCKS5 proxy 127.0.0.1:1080, cały ruch idzie przez SSH.
Przydatne flagi SSH do tunelowania
-N — nie wykonuje komendy zdalnej (tylko tunel, bez powłoki). -f — uruchamia SSH w tle. -C — kompresja danych (przydatna dla wolnych połączeń). -v — verbose (debug). -i key_file — konkretny klucz prywatny. -o ServerAliveInterval=60 — keepalive, żeby tunel nie wygasał. Typowe użycie w tle: ssh -fNL 5432:db:5432 user@bastion.
Autossh — automatyczne przywracanie tunelu
Autossh monitoruje połączenie SSH i automatycznie je przywraca po zerwaniu — niezbędne dla stałych tuneli produkcyjnych. Przykład: autossh -M 20000 -f -N -L 5432:db:5432 user@bastion. Port 20000 to port monitorujący autossh. Autossh możesz zarządzać przez systemd service dla trwałości po restarcie.
Najczęściej zadawane pytania
Jak dostać się do bazy danych MySQL za firewallem przez SSH?
Utwórz local forward: ssh -fNL 3306:db-server:3306 [email protected]. Następnie połącz się lokalnie: mysql -h 127.0.0.1 -P 3306 -u dbuser -p. Twój klient MySQL połączy się przez tunel SSH, jakby baza była lokalna. Pamiętaj o -h 127.0.0.1 zamiast localhost (localhost może używać socket zamiast TCP).
Jak udostępnić lokalny serwer developerski przez internet?
Remote forwarding: ssh -R 8080:localhost:3000 [email protected]. Ktokolwiek odwiedzi public-server.com:8080, zobaczy Twój lokalny serwer na porcie 3000. Wymaga GatewayPorts yes w sshd_config na serwerze. Alternatywnie użyj narzędzi jak ngrok lub Cloudflare Tunnel — prostsze w konfiguracji.
Jaka jest różnica między tunelem SSH a VPN?
Tunel SSH: działa per-port, bezpołączeniowy konfiguracyjnie, wymaga tylko dostępu SSH, szyfruje tylko tunelowany ruch. VPN: kieruje cały ruch sieciowy, działa na poziomie systemu, wymaga klienta VPN i serwera, bardziej odpowiedni dla pełnego dostępu do sieci firmowej. Dla dostępu do konkretnych usług za firewallem — SSH tunnel. Dla pełnego "bycia w sieci firmowej" — VPN.
Jak utrzymać tunel SSH żywym (zapobiec rozłączeniu)?
Dodaj do ~/.ssh/config: Host *\n ServerAliveInterval 60\n ServerAliveCountMax 3. Lub w komendzie: -o ServerAliveInterval=60 -o ServerAliveCountMax=3. Te opcje wysyłają keepalive co 60 sekund i zamykają połączenie po 3 nieodebranych keepalive. Dla krytycznych tuneli użyj autossh lub systemd socket activation.
Czy tunelowanie SSH jest bezpieczne?
Tak — SSH używa silnego szyfrowania (AES-256, ChaCha20) i uwierzytelniania kluczem publicznym. Tunel jest tak bezpieczny jak Twój klucz prywatny. Używaj zawsze uwierzytelniania kluczem (nie hasłem), trzymaj klucz prywatny bezpiecznie (szyfrowany passphrase), regularnie rotuj klucze, ogranicz dostęp SSH przez AllowUsers i from= w authorized_keys.