Tutoriel Linux

Tunnel SSH: inoltra una porta senza esporre il tuo server

Débutant5 min de lecture
À retenirLinux n'est pas réservé aux experts. Le bon point de départ : une distribution accessible, une sauvegarde propre et quelques commandes comprises.

È necessario accedere a un’interfaccia web, a un database PostgreSQL o a un servizio di amministrazione che è in ascolto solo su 127.0.0.1Aprire la porta nel firewall del server sarebbe veloce, ma in tal caso il servizio diventerebbe accessibile da una rete in cui non dovrebbe trovarsi.

UN Tunnel SSH Questo porta la connessione nella tua sessione SSH. Per l’accesso occasionale, preferisco questo metodo: il servizio rimane pubblicamente chiuso e solo la macchina che apre il tunnel può usarlo. Tuttavia, è necessario scegliere il reindirizzamento corretto e verificare l’indirizzo di ascolto, soprattutto con -R.

Illustrazione di Tux al centro di un tunnel SSH sicuro tra una macchina locale e un server Linux.
Il tunnel SSH veicola una porta in una connessione crittografata senza pubblicare direttamente il servizio sulla rete.

Inoltra una porta alla tua macchina usando -L

Reindirizzamento locale -L Apre una porta sulla tua macchina e inoltra le connessioni a una destinazione accessibile dal server SSH. La sua forma generale è la seguente:

ssh -L indirizzo_locale:porta_locale:host_destinazione:porta_destinazione utente@server_ssh

Per raggiungere un’interfaccia HTTP che è in ascolto solo sulla porta 80 del server remoto:

ssh -N -T -o ExitOnForwardFailure=yes 
  -L 127.0.0.1:8080:127.0.0.1:80 
  [email protected]
  • -L crea il reindirizzamento locale;
  • 127.0.0.1:8080 è la porta aperta sul tuo computer;
  • 127.0.0.1:80 è la destinazione vista dal server SSH;
  • -N evita di avviare un comando remoto;
  • -T evita di allocare un terminale;
  • ExitOnForwardFailure=sì La sessione viene chiusa se SSH non riesce a creare il reindirizzamento richiesto.

Quest’ultima opzione conferma la creazione della porta di ascolto. Non dimostra che il servizio finale stia rispondendo. Testare sempre la destinazione dopo aver aperto il tunnel.

Fintanto che l’ordine rimane aperto, puoi testare il servizio dal tuo computer:

curl http://127.0.0.1:8080/

L’indirizzo situato a destra di -L merita la tua attenzione. Nell’esempio precedente, 127.0.0.1 Questo si riferisce al server SSH, non al tuo computer. Se la destinazione si trova su un’altra macchina nella rete privata, specifica il suo indirizzo privato:

ssh -N -T -o ExitOnForwardFailure=yes 
  -L 127.0.0.1:15432:10.20.0.15:5432 
  [email protected]

Il tuo client PostgreSQL si connette quindi a 127.0.0.1:15432Il bastione apre il collegamento effettivo a 10.20.0.15:5432La base non ha bisogno di ascoltare su internet.

Verifica che il tunnel sia effettivamente in ascolto

Sul tuo computer, controlla la porta locale con ss :

ss -ltnp | grep ':8080'
ss -ltnp | grep ':15432'

Devi vedere una sessione di ascolto su 127.0.0.1associati al processo sshSe vedi 0.0.0.0 O La porta potrebbe essere accessibile da altre interfacce sulla macchina. Chiudere il tunnel e ricrearlo, specificando esplicitamente 127.0.0.1.

La guida a porte aperte in Linux con ss Vengono forniti i dettagli relativi alla lettura degli indirizzi di ascolto. Verificare inoltre che il server SSH possa raggiungere la destinazione finale:

curl -I http://127.0.0.1:80/
nc -vz 10.20.0.15 5432

Se il tunnel viene creato ma che arricciare oppure il tuo client SQL riceve Connessione rifiutataProbabilmente SSH funziona. È la destinazione finale che non è in ascolto sull’indirizzo o sulla porta specificati.

Utilizzo di -R senza pubblicare un servizio per errore

Reindirizzamento remoto -R Fa l’opposto. Apre una porta sul server SSH e la inoltra a un servizio accessibile dalla tua macchina. Esempio: rendere un’applicazione locale sulla porta 3000 accessibile solo dal server remoto:

ssh -N -T -o ExitOnForwardFailure=yes 
  -R 127.0.0.1:9000:127.0.0.1:3000 
  [email protected]

Sul server remoto, un processo locale può ora effettuare la chiamata:

curl http://127.0.0.1:9000/

Per impostazione predefinita, sshd associa questa porta remota all’interfaccia di loopback. Non sostituire 127.0.0.1 di 0.0.0.0 O * senza aver deciso chi dovrebbe essere in grado di accedere al servizio. Il parametro del server Porte gateway Consente l’ascolto su altre interfacce. Una semplice dimostrazione locale può quindi trasformarsi in un servizio esposto alla rete.

Evita anche l’opzione -G con un reindirizzamento locale se non si desidera che altre macchine si connettano alla porta inoltrata. Per mantenere il tuo ingombro minimo, associa i tuoi tunnel a 127.0.0.1 su entrambi i lati.

Controllo delle restrizioni del server SSH

Se SSH risponde amministrativamente vietato Se il reindirizzamento viene rifiutato, consultare la configurazione corrente del server:

sudo /usr/sbin/sshd -T | grep -E '^(allowtcpforwarding|gatewayports|permitopen|permitlisten)'

Consenti l'inoltro TCP È possibile consentire reindirizzamenti locali, reindirizzamenti remoti, entrambi o nessuno dei due. PermessoAperto E PermessoAscolta Queste restrizioni vengono utilizzate per limitare le destinazioni e le porte consentite. Su un server condiviso, queste restrizioni sono preferibili alla concessione di autorizzazioni globali a tutti gli account.

Prima di qualsiasi modifica di /etc/ssh/sshd_config o un file sotto /etc/ssh/sshd_config.d/Mantieni aperta la sessione corrente e verifica la sintassi:

sudo /usr/sbin/sshd -t

Riavvia SSH solo dopo un ritorno riuscito senza errori. La procedura completa è spiegata nell’articolo su riavvio del servizio SSH su UbuntuSe stai ancora utilizzando una password per questo account, inizia da configurare una chiave SSH.

Salva un tunnel ricorrente in ~/.ssh/config

Per un database utilizzato regolarmente, evitare di copiare un comando lungo. Aggiungere un host dedicato in ~/.ssh/config :

Host tunnel-db
    Nome host bastion.example.net
    Utenteamministratore
    LocalForward 127.0.0.1:15432 10.20.0.15:5432
    ExitOnForwardFailure sì
    ServerAliveInterval 30
    ServerAliveCountMax 3

Proteggi il file, quindi apri il tunnel verso il primo piano:

chmod 600 ~/.ssh/config
ssh -N -T tunnel-db

Consiglio di mantenere la prima esecuzione in primo piano. Vedrai immediatamente eventuali errori di chiave, porta locale o reindirizzamento e CTRL+C chiudi correttamente il tunnel. Se poi lo avvii in background con -FIdentifica il processo corretto prima di interromperlo:

pgrep -af 'ssh.*15432'
uccidi il PID

Evitare uccidi -9 Per riflesso. Un segnale normale è solitamente sufficiente per chiudere la sessione e liberare la porta.

Diagnosi di un tunnel che non passa

  • Indirizzo già in uso Un altro processo è l’utilizzo della porta locale. Controllalo con ss -ltnp oppure scegli un’altra porta.
  • Connessione rifiutata Il servizio di destinazione non è in ascolto oppure l’indirizzo di destinazione non è corretto dal punto di vista del server SSH.
  • Vietato amministrativamente La configurazione SSH blocca il reindirizzamento o limita la destinazione richiesta.
  • Tempo scaduto Il server SSH non riesce a raggiungere la destinazione a causa di problemi di routing o di un firewall intermedio.
  • Tunnel in caduta : verificare la stabilità della connessione e utilizzare Intervallo di vita del server piuttosto che un ciclo che riavvia SSH senza alcuna diagnosi.

Per ottenere dettagli sulla negoziazione e sui reindirizzamenti, aggiungi temporaneamente -v :

ssh -v -N -T -L 127.0.0.1:8080:127.0.0.1:80 [email protected]

Un tunnel SSH protegge il trasporto, ma non corregge i diritti di accesso al servizio di destinazione. Mantieni l’ascolto sull’interfaccia di loopback locale, utilizza un account SSH con privilegi limitati, controlla le chiavi autorizzate e chiudi la sessione non appena l’accesso non è più necessario.

La sintassi di -L, -R, -N E -G sono dettagliate nel Documentazione ufficiale del client OpenSSHI controlli Consenti l'inoltro TCP, Porte gateway, PermessoAperto E PermessoAscolta sono descritti in sshd_config(5).

sudo apt update && sudo apt upgrade