Tunneling SSH per accedere a servizi interni

Il tunneling SSH e un meccanismo potente per accedere a servizi protetti da firewall o non esposti pubblicamente, sfruttando una sessione SSH già disponibile. E spesso usato per database, dashboard interne, pannelli amministrativi e per evitare di esporre porte sensibili a Internet.

Tipi di tunnel

SSH supporta tre tipologie di port forwarding: locale (-L), remoto (-R), dinamico (-D). Il locale espone una porta del client che viene rediretta verso una destinazione raggiungibile dal server SSH. Il remoto espone una porta del server SSH che viene rediretta verso una destinazione raggiungibile dal client. Il dinamico attiva un proxy SOCKS sul client.

Local forwarding

Esempio: vuoi accedere a MySQL su un database interno raggiungibile solo dal server bastion. Da locale: ssh -L 3306:db-internal:3306 user@bastion. Poi connetti il client MySQL a localhost:3306: la connessione viene cifrata e rediretta. E il metodo più sicuro per amministrare DB senza esporli pubblicamente.

Remote forwarding

Esempio: il tuo PC dietro NAT ha un servizio (es. webhook in dev) che deve essere accessibile da Internet. Su un server pubblico esegui ssh -R 8080:localhost:3000 user@public-server: chiunque si connetta a public-server:8080 raggiunge il tuo localhost:3000. Utile per debugging o demo, attento alla sicurezza.

Dynamic forwarding (SOCKS)

Con ssh -D 1080 user@server avvii un proxy SOCKS5 sul client che instrada tutto il traffico via SSH. Configura il browser per usare localhost:1080 e navighi come se fossi sulla LAN del server SSH. Utile in viaggio o per bypassare reti restrittive (con permesso).

Procedura passo-passo

1. Verifica che AllowTcpForwarding yes in sshd_config (default si).
2. Identifica destinazione e porta target.
3. Scegli il tipo di forwarding più adatto al tuo scenario.
4. Lancia il comando SSH con -L/-R/-D.
5. Per persistenza, configura una entry in ~/.ssh/config con LocalForward o RemoteForward.
6. Considera autossh per riconnessione automatica.
7. Limita gli accessi con PermitOpen e PermitListen in sshd_config per principio del minimo privilegio.
8. Monitora le sessioni attive con ss -tnp.

Errori comuni e come risolverli

• "Channel forwarding refused": AllowTcpForwarding disabilitato lato server.
• Tunnel che si chiudono: usa autossh o ServerAliveInterval per keep-alive.
• Esposizione accidentale: -R con bind *:port espone a tutta la WAN; usa GatewayPorts con cautela.
• Performance basse: SSH cifra tutto; per traffico massivo considera VPN dedicata.

Domande frequenti

D: SSH tunnel e una VPN?
R: Solo parzialmente: SOCKS proxy non instrada IP/UDP nativamente come una VPN vera.

D: WireGuard puo sostituire i tunnel SSH?
R: Per accesso continuativo si, e più performante e stabile.

D: Posso aprire un tunnel da uno script?
R: Si con ssh -fN -L ... in background.

Approfondimento tecnico: ControlMaster e multiplexing

Aprire molte sessioni SSH allo stesso host puo essere lento: ogni connessione richiede handshake, autenticazione, eventuali due fattori. Il multiplexing SSH risolve via ControlMaster: la prima connessione apre un socket Unix locale, le successive vi si riconnettono istantaneamente. In ~/.ssh/config: ControlMaster auto, ControlPath ~/.ssh/cm-%r@%h:%p, ControlPersist 10m.

Il multiplexing e particolarmente utile per tool basati su SSH: ansible (decine di moduli per host), scp ricorsivi, rsync iterativi. Riduce tempi di playbook del 40-60 percento. Attenzione: tutti i tunnel ereditano l'autenticazione del master, considera implicazioni di sicurezza.

Scenari d'uso reali

Un dba in trasferta apre tunnel locale verso 5 database aziendali via SSH bastion: lavora come se fosse in ufficio.

Una casa software espone temporaneamente un webhook locale durante demo via tunnel remoto SSH verso un VPS pubblico.

Un operatore di rete in viaggio attiva proxy SOCKS via SSH per accedere a strumenti interni senza VPN.

Checklist operativa SSH tunneling

• PermitOpen e PermitListen per limitare le destinazioni.
• ServerAliveInterval per stabilita su connessioni lunghe.
• ControlMaster per multiplexing efficiente.
• Autossh per riconnessione automatica in scenari critici.
• Logging delle sessioni per audit.
• Disabilita ForwardAgent se non strettamente necessario.
• Monitoring porte aperte sui bastion.

Risorse e riferimenti

OpenSSH manual (ssh, ssh_config). autossh per persistenza. Per scenari moderni: Tailscale, Cloudflare Tunnel, ngrok offrono alternative high-level. Bastion as a service: Teleport, BastionZero, AWS Session Manager.

Considerazioni economiche e organizzative

Implementare correttamente quanto descritto in questo articolo su tunneling ssh per accedere a servizi interni richiede tempo, formazione e talvolta investimenti hardware o software. La buona notizia e che il ritorno e quasi sempre positivo: meno incidenti, meno tempo speso in troubleshooting reattivo, maggiore predicibilita dei servizi. Stima sempre il costo del downtime per il tuo business: anche poche ore l'anno di indisponibilita possono giustificare investimenti che a prima vista sembrano sovradimensionati.

Sul piano organizzativo, la documentazione e il fattore decisivo. Un sistema brillantemente configurato ma non documentato e una bomba a orologeria: il giorno in cui il sysadmin originale lascia l'azienda, ogni intervento diventa archeologia. Mantieni runbook aggiornati, versionali in git, fai pratica di lettura nei momenti di calma e non solo durante gli incidenti.

Glossario rapido dei termini chiave

RTO (Recovery Time Objective): tempo massimo entro cui un servizio deve tornare operativo dopo un'incidente. RPO (Recovery Point Objective): perdita massima accettabile di dati misurata nel tempo (es. 1 ora di transazioni). SLA (Service Level Agreement): contratto formale che definisce livelli di servizio e penali. SLO/SLI (Service Level Objective/Indicator): metriche interne di qualità usate per misurare e mantenere lo SLA. MTBF/MTTR: tempo medio tra guasti e tempo medio di ripristino, indicatori di affidabilità. Idempotenza: proprietà di un'operazione che, applicata più volte, produce lo stesso risultato della singola applicazione (fondamentale per automazione).

Hai bisogno di aiuto?

Se hai dubbi sulla gestione server, il team di G Tech Group puo aiutarti. Contattaci tramite il modulo di contatto.