Inoltro SSH locale o VPN completa per uno schermo Mac?

Devi vedere lo schermo di un Mac dalla tua macchina, il Mac si trova dietro un host a cui puoi già accedere via SSH, e la domanda è se questo meriti una VPN. Di solito no. Un singolo inoltro locale trasporta una porta TCP attraverso la sessione SSH che hai già, e per uno schermo su un solo host è una disposizione più piccola e più verificabile del routing di un’intera rete.

Tre condizioni lo decidono, e ciascuna può spingerti verso la VPN gestita.

Tre condizioni lo decidono

La prima è l’ambito: un servizio su un solo host, o più host e più porte. La seconda è se ogni salto tra il bastion e la destinazione è già affidabile, perché SSH protegge solo il segmento che termina. La terza è chi deve supportare la disposizione dopo che l’hai costruita, dato che un tunnel fatto a mano tende a sopravvivere alla persona che lo ha capito. Nomina quella persona prima di iniziare, e scrivi il comando in un posto dove possa trovarlo. Un inoltro non documentato è un incidente futuro con una data di inizio rinviata.

Se le risposte sono «uno», «sì» e «io, per ora», l’inoltro è lo strumento giusto. Se una risposta cambia, un progetto di accesso remoto supportato costa meno in un anno della revisione dell’incidente che segue un tunnel non documentato.

Inoltra una porta, non la rete

Un inoltro locale apre un ascoltatore sulla tua macchina e inoltra ogni connessione attraverso il server SSH verso una destinazione che quel server può raggiungere. Per un Mac il cui servizio di condivisione schermo ascolta su TCP 5900, e un bastion che sa risolvere mac.corp.example, il comando è breve e volutamente stretto. Ogni opzione al suo interno esiste per mantenere piccola la disposizione: niente shell, nessun ascoltatore su tutte le interfacce, nessun demone. Leggilo come una dichiarazione di ambito, non come una ricetta.

ssh -N -o ExitOnForwardFailure=yes -L 127.0.0.1:15900:mac.corp.example:5900 [email protected]

Vincolare l’ascoltatore a 127.0.0.1 lo tiene fuori da ogni altra interfaccia. Non è una formalità: un inoltro vincolato a tutte le interfacce trasforma il tuo portatile in un relè aperto verso la rete aziendale per chiunque sullo stesso Wi-Fi del bar. Se la porta è già in uso, scegli un’altra porta alta e aggiorna il visualizzatore; non fermare un servizio non correlato per far combaciare l’esempio.

Anche l’account sul bastion ha bisogno del permesso di inoltrare verso quella destinazione. Alcune configurazioni SSH indurite disattivano del tutto l’inoltro delle porte, e alcune lo limitano con una direttiva permit-listen o permit-open. Leggi la politica del server prima di supporre che un canale rifiutato significhi che la password era sbagliata.

Cosa cifra SSH, e dove si ferma

La sessione SSH protegge il traffico dal tuo Mac al bastion, e l’inoltro porta il protocollo VNC dentro quella sessione senza capirlo. Una volta che la connessione lascia il bastion verso la destinazione, non è più dentro la tua sessione SSH. Qualunque protezione esista su quell’ultimo salto appartiene al protocollo di destinazione e ai controlli propri della rete privata.

Per questo un ultimo salto VNC semplice non va descritto come cifrato end-to-end solo perché il primo salto ha usato SSH. Descrivi i segmenti con onestà: forte dal client al bastion, e poi ciò che la destinazione supporta. Se il requisito è che l’intero percorso sia cifrato da un solo meccanismo, l’inoltro non lo soddisfa.

L’autenticazione sulla destinazione è di nuovo un’altra cosa. L’account SSH non concede un accesso a macOS, e il servizio di condivisione schermo chiede ancora le proprie credenziali e applica ancora la propria lista di accesso. Un ascoltatore locale che accetta una connessione non dimostra nulla su se il servizio remoto ammetterà la sessione.

Quando la VPN completa è la scelta giusta

Scegli la VPN quando il compito richiede più di una porta: le funzioni di gestione e reportistica di Apple Remote Desktop usano traffico TCP e UDP aggiuntivo che un singolo inoltro TCP non può trasportare. Un inoltro non è un’implementazione parziale dell’intero prodotto; è uno strumento diverso e più piccolo.

Sceglila quando più amministratori si collegano da luoghi mutevoli, perché un profilo gestito distribuisce rotte, credenziali e criteri senza che ogni persona inventi una riga di comando. Sceglila quando la traccia di audit deve mostrare chi si è connesso a cosa, dato che una sessione SSH per utente e un inoltro locale condiviso lasciano registrazioni molto diverse.

Sceglila, infine, quando la rete di destinazione non deve essere raggiungibile da un portatile senza il cancello proprio dell’organizzazione. Un inoltro personale aggira quel cancello per concezione, ed è esattamente per questo che appartiene a un registro delle modifiche e non a una cronologia della shell.

Fai fallire l’inoltro in modo rumoroso

Usa ExitOnForwardFailure=yes perché un binding fallito fermi la sessione invece di lasciare una shell che sembra connessa e non inoltra nulla. Tieni attiva la verifica della chiave dell’host, e preferisci una chiave o un agente a una password. Poi prova l’URL esatto che userà il visualizzatore, perché una sessione SSH funzionante e una connessione schermo funzionante sono due risultati diversi.

Per il client nativo su macOS, si raggiunge il visualizzatore tramite un URL locale: open "vnc://127.0.0.1:15900". Se la finestra si apre e l’host remoto rifiuta l’autenticazione, il tunnel va bene e il problema è sulla destinazione. Se la finestra non si apre mai, il problema è l’ascoltatore o la porta.

Ferma la sessione quando hai finito, e annota la porta, il bastion, la destinazione e la politica dell’account. Un inoltro che nessuno ha documentato è indistinguibile da una backdoor sei mesi dopo, e questo è l’argomento più forte per tenerlo piccolo, con un nome e temporaneo.