ssh
Raggiungere servizi privati in sicurezza con un tunnel SSH
Usa un tunnel SSH per accedere a un servizio privato senza esporlo a internet pubblico.
Per raggiungere un database engine, una dashboard di monitoraggio o un pannello di gestione sul tuo server, non è necessario esporre le relative porte di rete sul web pubblico.
In breve: Un tunnel SSH (Local Port Forwarding) consente di accedere in modo sicuro a un servizio remoto privato incanalando il traffico all'interno di una connessione SSH cifrata. Questa tecnica permette di mantenere PostgreSQL, Redis, un'interfaccia di amministrazione o un contenitore Docker non accessibili da Internet, rendendoli comunque raggiungibili dal proprio client come se fossero eseguiti in locale. Il servizio rimane segregato; il tunnel SSH agisce da canale cifrato temporaneo tra il computer locale e l'infrastruttura remota.
Che cos'è un tunnel SSH?
Un tunnel SSH sfrutta il meccanismo di port forwarding integrato nel protocollo Secure Shell (SSH) per incanalare il traffico di un servizio arbitrario all'interno di un flusso di comunicazione cifrato.
In un'architettura di rete standard, le porte pubbliche come la 80 (HTTP) e la 443 (HTTPS) sono configurate per accettare connessioni da qualsiasi host esterno. Al contrario, i servizi interni di amministrazione o i database engine devono rimanere confinati all'interfaccia di loopback (127.0.0.1) o a reti private.
Configurando un tunnel SSH locale, il client SSH mappa un socket locale (es. localhost:15432) e reindirizza in modo trasparente e cifrato i pacchetti verso la porta di destinazione del server remoto (es. 127.0.0.1:5432). In questo modo, l'applicazione remota riceve le chiamate direttamente dall'interfaccia locale dell'host, mantenendo la propria porta del tutto nascosta a Internet.
L'adozione dei tunnel SSH consente di accedere alle risorse di rete interne senza dover esporre porte aggiuntive o modificare le policy del firewall di rete.
Quando utilizzare un tunnel SSH?
I tunnel SSH sono indicati in tutte le circostanze in cui un servizio di rete debba essere fruibile esclusivamente dagli amministratori di sistema o dagli sviluppatori, rimanendo del tutto inaccessibile agli host esterni.
I casi d'uso principali includono:
- Interfaccia e client per Database: Connessione tramite tool desktop (es. DBeaver, PGAdmin, DataGrip) a database engine come PostgreSQL, MySQL o MariaDB senza dover esporre le porte
5432o3306su IP pubblico. - Dashboard e strumenti di amministrazione: Fruizione di pannelli di monitoraggio, interfacce di queuing, dashboard di metriche o console di ricerca interne sprovviste di meccanismi complessi di autenticazione integrata.
- Ambienti di containerizzazione (Docker): Esposizione dei servizi erogati dai container esclusivamente sull'interfaccia locale dell'host (
127.0.0.1). Per una panoramica dettagliata sull'architettura dei container, consulta la nostra guida a Docker su server.
Come regola di sicurezza generale: se un servizio non è destinato a servire traffico pubblico, non deve essere esposto direttamente in rete, ma raggiunto esclusivamente tramite tunnel cifrato o VPN.
Analisi comparativa della sicurezza: Port Forwarding vs Esposizione Diretta
L'esposizione diretta di una porta di rete aumenta la superficie d'attacco del server, esponendo il servizio a scansioni automatizzate, attacchi di forza bruta e tentativi di exploit di vulnerabilità zero-day.
L'incanalamento del traffico all'interno di un tunnel SSH applica un livello di autenticazione e cifratura rigoroso a monte del servizio stesso, richiedendo il possesso delle chiavi SSH autorizzate prima di poter stabilire la connessione.
| Approccio | Visibilità in Rete | Ambiti di Applicazione Ideali |
|---|---|---|
| Porta Pubblica Esposta | Il socket di rete risponde direttamente alle scansioni esterne | Web server pubblici, API gateway aperte, servizi destinati all'utenza finale |
| Tunnel SSH (Port Forwarding) | Servizio nascosto; è visibile esclusivamente la porta SSH | Database, pannelli di controllo interni, ambienti di staging, interfacce gestionali |
L'efficacia di questa architettura presuppone l'adozione delle best practice di Hardening SSH e l'uso di un firewall di rete per il filtraggio del traffico. Se non hai ancora definito le regole perimetrali, fa' riferimento alla guida su come configurare un firewall sul tuo server.
Problemi frequenti e misconfigurazioni dei tunnel SSH
Durante l'impostazione di un tunnel SSH possono verificarsi errori di configurazione o conflitti di rete:
- Mancata distinzione delle porte locali e remote: Confusione tra il socket locale configurato sul client e l'host/porta di destinazione definiti lato server.
- Binding del servizio su interfacce pubbliche: Se un database o un servizio esegue il binding sull'indirizzo
0.0.0.0anziché su127.0.0.1, il servizio risulterà comunque accessibile dall'esterno, vanificando la segregazione offerta dal tunnel. - Conflitti di porta sul client locale: Se la porta locale scelta sul client (es.
5432) è già occupata da un processo locale, la creazione del tunnel fallirà. Occorre specificare una porta locale differente (es.15432). - Persistenza indebita del tunnel: Mantenere attivi tunnel SSH indefinitamente senza tracciamento può generare falle di sicurezza nell'architettura di rete locale.
Se la problematica riguarda l'irraggiungibilità di un'applicazione web pubblica, la diagnosi deve orientarsi sul livello di routing e configurazione del web server. Consulta la nostra guida completa su perché il mio sito non si carica per la risoluzione dei problemi web.
FAQ
È possibile utilizzare un tunnel SSH per connettersi a un database remoto? Sì. Riconfigurando il gestore di database per la connessione tramite porta locale reindirizzata via SSH, l'applicazione client comunicherà con l'istanza remota di PostgreSQL, MySQL o MariaDB in piena sicurezza.
Un tunnel SSH richiede la presenza di un FQDN o nome di dominio? No. Il tunnel SSH viene instradato verso l'indirizzo IP pubblico dell'host o verso l'hostname definito nel file di configurazione SSH locale (~/.ssh/config).
Qual è la differenza tra un tunnel SSH e una connessione VPN? Una VPN (Virtual Private Network) opera a livello di rete (Layer 3) estendendo la connettività per l'intero stack di rete del client, mentre un tunnel SSH opera a livello applicativo (Layer 7) inoltrando unicamente i flussi di dati inviati a uno specifico socket.
È corretto mantenere un tunnel SSH indefinitamente attivo? È preferibile aprire il tunnel SSH all'occorrenza e chiuderlo al termine dell'attività amministrativa. In alternativa, per connessioni persistenti si consiglia l'impiego di daemon dedicati (es. autossh) o di soluzioni VPN/Overlay Network.
La soluzione intermedia
Server Manager consente di gestire l'esposizione dei servizi applicativi riducendo la necessità di configurare manualmente porte di rete pubbliche. L'architettura permette di definire il livello di visibilità di ciascun servizio, isolando i database e le interfacce interne direttamente a livello di configurazione.
L'adozione di un pannello di gestione centralizzato previene le errate configurazioni di binding sugli indirizzi IP pubblici, fornendo chiarezza sulle porte esposte e garantendo la tracciabilità dei servizi nel tempo.
La segregazione delle risorse interne si considera configurata correttamente quando i servizi non pubblici eseguono il binding unicamente sulle interfacce locali (127.0.0.1), il firewall di rete blocca qualsiasi tentativo di connessione diretta alle porte riservate e l'accesso amministrativo avviene esclusivamente attraverso canali cifrati SSH o reti private.