VNC vs SSH: la scelta del giusto protocollo di accesso remoto per un’amministrazione sicura del sistema

Se chiedi a un gruppo di amministratori di sistema se preferiscono SSH o VNC, otterrai sicuramente delle opinioni contrastanti. Alcuni giurano sulla precisione della riga di comando, mentre altri non rinunceranno mai alla comodità di avere una sessione completa di Remote Desktop. Il dibattito tra VNC e SSH è vecchio quanto l’amministrazione di sistema, perché ogni protocollo offre qualcosa che l’altro non può offrire.

L’accesso remoto è, ovviamente, alla base delle moderne operazioni IT. Gli amministratori raramente siedono davanti a rack di server e gestiscono gli host da console KVM. Devono collegarsi in rete per risolvere i problemi, distribuire e monitorare i sistemi remoti. Questo compito significa in genere eseguire comandi in una shell testuale (SSH) o controllare l’intero ambiente desktop di un altro server (VNC). Come per la maggior parte delle cose nell’IT, l’approccio migliore dipende dalla situazione, dal carico di lavoro e dal sistema operativo in uso sul computer host.

Questo articolo non risolverà il dibattito tra VNC e SSH, ma spiegherà le differenze tra i due metodi e perché entrambi sono ancora più necessari che mai. Vedrai come ogni metodo supporta il flusso di lavoro aziendale, quali misure di sicurezza si applicano e dove i fattori di performance possono influenzare l’adozione. Verrà inoltre evidenziato come l’adattamento più avanzato del protocollo VNC, RealVNC Connect, fornisca un software di accesso remoto sicuro out-of-the-box per le aziende.

Come funziona VNC: accesso Remote Desktop

Virtual Network Computing (VNC) è una delle prime e più diffuse tecnologie di Remote Desktop. Il principio di funzionamento è abbastanza semplice: un server VNC cattura l’output dello schermo di un computer, lo comprime in pacchetti di dati e invia queste informazioni a un client attraverso la rete. Il client riceve i pacchetti e visualizza l’ambiente grafico, creando l’esperienza di essere seduti direttamente di fronte al sistema remoto.

Il protocollo Remote Framebuffer (FRB) è lo standard alla base di VNC. RFB è responsabile della trasmissione delle informazioni sui pixel, della codifica degli aggiornamenti grafici e dell’interpretazione dei movimenti del mouse, dei clic e degli input da tastiera dell’utente client. Quando un utente muove il mouse o digita sulla tastiera, queste azioni vengono inoltrate al server VNC, che le esegue sul computer di destinazione.

Poiché stiamo parlando di una sessione interattiva bidirezionale di un desktop completo, l’efficienza della codifica è importante. Le prime implementazioni di VNC trasmettevano dati pixel grezzi e richiedevano un’elevata larghezza di banda. Le versioni moderne utilizzano algoritmi di compressione per ridurre il traffico e mantenere un’immagine ad alta risoluzione sul lato client. Alcune implementazioni di VNC possono addirittura sfruttare la tua GPU per gestire applicazioni pesanti e display ad alta risoluzione.

VNC è più comunemente utilizzato sui server e sui desktop di Windows, ma poiché funziona a livello di framebuffer, è multipiattaforma per design. Un server VNC in esecuzione su Linux e MacOS può essere raggiunto da quasi tutti i client che supportano il protocollo. Questa flessibilità permette ai team IT di connettersi a una varietà di sistemi senza affidarsi a soluzioni specifiche per ogni piattaforma, come ad esempio RDP di Microsoft.

Per le organizzazioni che utilizzano VNC ma richiedono sicurezza Enterprise, VNC Connect offre un’autenticazione protetta e un supporto multipiattaforma che va ben oltre le opzioni VNC open-source standard.

Come funziona SSH: Accesso sicuro alla riga di comando

Secure Shell Host (SSH) offre un accesso criptato alla riga di comando di sistemi remoti con un overhead estremamente ridotto (anche su una connessione dial-up a 56k) e una forte integrità della sessione. Gli amministratori utilizzano SSH per aprire un terminale su un server di destinazione, autenticarsi ed eseguire comandi come se fossero seduti di fronte ad esso. Il protocollo separa le preoccupazioni in un livello di trasporto, un livello di autenticazione e un livello di connessione per mantenere una comunicazione affidabile, anche su reti non affidabili.

La fase del livello di trasporto negozia gli algoritmi e stabilisce la riservatezza. Gli stack SSH moderni tendono a favorire lo scambio di chiavi Curve25519, le chiavi host Ed25519 e i cifrari AEAD come chacha20 o AES-GCM. I vecchi gruppi RSA e Diffie-Hellman classici sono ancora in circolazione, anche se gli amministratori moderni preferiscono opzioni più recenti per la sicurezza.

Una volta che il canale è protetto, l’autenticazione dell’utente avviene tramite chiavi pubbliche, certificati di breve durata o password a basso costo. La connessione viene poi avviata con l’assegnazione di canali virtuali per le shell, le richieste di esecuzione o il port forwarding.

Un tipico flusso di lavoro che utilizza SSH è il seguente:

1. Il client utilizza un terminale o un emulatore di terminale come Putty, dove stabilisce la connessione tramite il comando CLI SSH user@host:port oppure inserendo il nome dell’host o l’IP del server di destinazione (come nel caso di applicazioni come Putty).
2. Il server fornisce una shell come bash, zsh o fish.
3. Gli operatori eseguono le utility di sistema, leggono i log con journalctl o tail, modificano la configurazione e registrano i risultati per modificare i record.

Su Linux, il sistema operativo più associato a SSH, questo approccio può essere utilizzato da migliaia di nodi perché le operazioni testuali sono intrinsecamente veloci e scriptabili.

Per coloro che temono l’amministrazione solo tramite CLI, non preoccuparti. Con l’inoltro di X11, le funzionalità di SSH possono andare oltre un semplice terminale. Anche se gli utenti potrebbero rimanere delusi nel sapere che non è possibile inoltrare un intero desktop, X11 su SSH consente di visualizzare sul computer locale una singola applicazione remota del computer host.

Il tunneling SSH può essere utilizzato anche per incapsulare in modo sicuro il traffico di altre applicazioni (tra cui VNC) e gli amministratori possono utilizzare SCP per trasferire file in modo bidirezionale tra host e client.

VNC vs SSH: quali sono le differenze principali nell’accesso remoto?

Poiché SSH funziona universalmente con quasi tutti i sistemi operativi (sì, anche Windows) e VNC è multipiattaforma, la scelta tra i due si riduce al modo in cui gli amministratori preferiscono interagire con un sistema remoto. VNC offre un’esperienza desktop completa in cui il client riceve un’immagine speculare del desktop dell’host. SSH offre un’interfaccia a riga di comando di solo testo che è efficiente, ma richiede una buona competenza per il suo utilizzo.

La principale linea di demarcazione tra i due sistemi è rappresentata dalle prestazioni. Un host VNC trasmette continui aggiornamenti dello schermo attraverso la rete, il che richiede molta più larghezza di banda. SSH trasmette solo testo e segnali di controllo, il che mantiene la latenza estremamente bassa, anche su connessioni lente come quelle satellitari e cellulari.

La sicurezza è un altro grande fattore di divisione. SSH è crittografato fin dall’inizio e si avvale di standard crittografici comprovati. Le prime soluzioni VNC, e anche alcune moderne open-source, non sono affatto crittografate o richiedono un po’ di configurazione per far funzionare la crittografia. Alcuni utenti hanno addirittura realizzato un tunnel per le loro connessioni VNC attraverso SSH, dimostrando così quanto SSH sia sicuro e versatile.

Le moderne implementazioni di VNC di livello aziendale come RealVNC Connect forniscono crittografia della sessione, autenticazione moderna e supporto per la conformità verificata attraverso verifiche indipendenti.

Ecco le principali differenze tra VNC e SSH in sintesi:

Ad oggi, entrambi i protocolli rimangono centrali nelle strategie di accesso remoto e la maggior parte degli amministratori li utilizza fianco a fianco per gestire efficacemente ogni tipo di server remoto. VNC viene scelto quando gli amministratori hanno bisogno di un controllo interattivo completo che vada oltre le funzioni di base, come le applicazioni GUI, l’assistenza agli utenti e la risoluzione di problemi in più fasi. SSH è preferibile per attività precise e scriptabili come modifiche alla configurazione, gestione dei pacchetti, revisione dei log, trasferimenti di file e automazione.

Considerazioni sulla sicurezza: Proteggere i sistemi remoti

Sfortunatamente, l’accesso remoto comporta dei rischi, soprattutto per i server rivolti al pubblico. Per questo motivo, l’amministrazione remota delle soluzioni di accesso richiede una forte attenzione alla sicurezza. Sia SSH che VNC sono soggetti a minacce se non vengono implementati senza protezioni, ma le migliori pratiche e le funzionalità aziendali possono colmare la maggior parte delle lacune.

Rischi e mitigazioni per la sicurezza di SSH

Con SSH, la comunicazione criptata ha la priorità. Tuttavia, i server esposti sono spesso bersaglio di attacchi. I problemi e le risposte più comuni sono:

• I malintenzionati utilizzano scanner come Nmap per rilevare le porte SSH aperte (TCP:22). Gli amministratori possono configurare il server SSH in modo che ascolti su una porta diversa o che richieda l’accesso locale tramite una VPN.
• I login basati su password sono vulnerabili agli attacchi brute-force. È meglio utilizzare chiavi SSH, protette da passphrase, e disabilitare completamente l’autenticazione tramite password.
• Il login di root tramite SSH è particolarmente vulnerabile se le credenziali vengono rubate. I team di solito disabilitano completamente il login SSH di root e favoriscono l’escalation dei privilegi con sudo o un account amministratore separato.
• Gli attacchi con script di forza bruta possono sovraccaricare i server e creare molto rumore. Strumenti come fail2ban monitorano i log SSH e bloccano gli indirizzi IP incriminati dopo diversi fallimenti.
• Gli attacchi Man-in-the-middle sono mitigati dalla verifica delle impronte digitali delle chiavi dell’host prima di stabilire la fiducia. Questa funzionalità è un componente fondamentale del moderno SSH.

Rischi e mitigazioni della sicurezza di VNC

Le versioni precedenti di VNC presentavano alcuni problemi di sicurezza perché il protocollo di base non prevedeva la crittografia. Le versioni moderne offrono la crittografia e possono essere rese più sicure da:

• Abilitare la crittografia nelle applicazioni VNC che la supportano. In caso contrario, i dati e persino le password vengono inviati in chiaro. Se la crittografia non è disponibile, il tunneling del traffico VNC attraverso l’inoltro SSH fornisce un trasporto crittografato.
• La semplice autenticazione tramite password può essere indovinata o rubata. Le piattaforme come RealVNC Connect offrono standard di autenticazione moderni e possono essere integrato con l’SSO aziendale.
• Proprio come SSH, la porta nativa di VNC (TCP:5900+N) espone il servizio agli scanner. Spostare la porta di ascolto o nasconderla dietro NAT e firewall riduce il rischio.
• I rischi di dirottamento di sessione vengono affrontati anche attraverso la crittografia dei dati in transito con i moderni standard di crittografia.

I programmi di conformità come PCI-DSS e ISO 27001 richiedono alle organizzazioni di dimostrare che i loro sistemi remoti sono sicuri. Esaminare Guida all’autenticazione sicura di OWASP è consigliabile prima di implementare qualsiasi strumento di accesso remoto.

RealVNC Connect: L’approccio moderno alla sicurezza di VNC

Per le aziende che richiedono la standardizzazione di VNC, I controlli di sicurezza di RealVNC Connect? rispondono a tutti i rischi comuni e alle esigenze di conformità:

• Crittografia completa della sessione e autenticazione moderna (MFA, SSO) per comunicazioni sicure con autorizzazioni granulari e richieste di approvazione da parte del cliente.
• Certificata ISO 27001:2022 e Cyber Essentials, supporta GDPR, CCPA, HIPAA, PCI-DSS e EU NIS2.
• Per impostazione predefinita, non è prevista la registrazione della sessione e non è possibile accedere ai dati della sessione. Le funzioni di privacy del sistema remoto includono la Modalità Privacy, il blocco dello schermo e il blocco degli input.
• Infrastruttura di proprietà di RealVNC per l’intermediazione, con un SOC attivo 24 ore su 24 e 7 giorni su 7, firma del codice su tutti i file binari, audit regolari white-box e test di penetrazione indipendenti.
• Gestione centralizzata, distribuzione via MSI e Group Policy, protezione brute-force, log dettagliati e audit trail accessibili nel portale o tramite l’API dedicata.

Requisiti di prestazioni e risorse

Il protocollo che scegli per fornire l’accesso remoto ha un effetto diretto sulle prestazioni, sull’utilizzo delle risorse e sull’esperienza dell’utente finale. Il modo in cui ciascuna tecnologia gestisce il traffico di rete e il carico del sistema spiega perché gli amministratori spesso si affidano a entrambe, ma in contesti diversi.

Fattori e messa a punto delle prestazioni SSH

SSH è famoso per funzionare bene anche nelle condizioni di rete più difficili. Poiché solo il testo e i dati di controllo si muovono attraverso il collegamento, il protocollo non ha bisogno di molta larghezza di banda. Non c’è bisogno di dire che SSH non ha bisogno di molte regolazioni delle prestazioni, ma le pratiche tipiche includono:

• I segnali keep-alive e sign-of-life inviati durante la sessione possono mantenere stabile una connessione aperta nel caso in cui l’host non riceva traffico attivo per un certo periodo di tempo.
• I flag di compressione come SSH -C migliorano la velocità di trasferimento dei log o di altri dati pesanti.

Fattori e messa a punto delle prestazioni di VNC

VNC trasmette un desktop grafico come immagine continua, quindi naturalmente consuma larghezza di banda. Le applicazioni che prevedono modifiche visive pesanti e alte frequenze di aggiornamento, come lo streaming video o il rendering 3D, aumentano ulteriormente il traffico. L’ottimizzazione delle prestazioni di VNC comprende:

• Algoritmi di compressione come quelli utilizzati da RealVNC Connect riducono la quantità di dati pixel trasmessi e utilizzano tecniche di codifica avanzate che si adattano automaticamente alla larghezza di banda.
• L’accelerazione locale della GPU scarica parte della codifica della cattura dello schermo, riducendo la frequenza della CPU e mantenendo la velocità dei fotogrammi.
• Le impostazioni di qualità possono essere regolate per disattivare i componenti del desktop non necessari, come lo sfondo del desktop e gli effetti di animazione.
• Le funzioni di ridimensionamento che traducono i desktop host a bassa risoluzione in alta risoluzione o in più monitor aiutano a mantenere le immagini chiare.

Casi d’uso pratici: Quando usare SSH, VNC o entrambi

La scelta tra VNC e SSH dipende dal compito da svolgere. Ogni protocollo risponde a esigenze specifiche e spesso gli amministratori tendono a usarli entrambi insieme per avere una copertura più completa.

VNC: amministrazione grafica e supporto

Un server VNC fornisce una condivisione visiva completa dello schermo, il che lo rende ideale per:

• Gestione di strumenti o dashboard di Windows e di strumenti non essenziali di Windows Server che non hanno un equivalente CLI.
• Esecuzione di ambienti di sviluppo, come gli IDE che necessitano di un’interfaccia grafica.
• Supportare gli utenti remoti visualizzando l’aspetto del loro desktop in modo da poter risolvere i loro problemi in tempo reale.
• Utilizzo di applicazioni grafiche come CAD e pannelli web.

SSH: efficienza della riga di comando

Gli amministratori usano SSH quando vogliono controllare in modo rapido ed efficiente un server remoto. Funziona meglio per:

• Esaminare i log di sistema ed eseguire i comandi di monitoraggio
• Scripting delle distribuzioni su centinaia di server contemporaneamente
• Accedere in remoto a server che sono headless (non eseguono alcuna interfaccia grafica)
• Configurazione di nodi cloud e cluster di container da remoto

Integrazione e uso complementare

In questa guida abbiamo parlato molto dell’inoltro e del tunneling delle sessioni VNC attraverso connessioni SSH. Molti amministratori lo fanno quando hanno a che fare con applicazioni VNC vecchie o open-source che risiedono su server e desktop Linux.

Come eseguire il tunnel di una sessione VNC attraverso SSH

Un tunnel sicuro può essere creato con un semplice comando SSH. Il processo inizia scegliendo la porta locale a cui il client si connetterà. La porta 5901 è una scelta comune, ma qualsiasi porta non utilizzata può funzionare.

1. Apri una finestra di terminale locale (questa operazione può essere eseguita su un server Windows con OpenSSH installato).
2. Esegui il seguente comando, sostituendo utente con il nome del tuo account e server con il nome dell’host o l’IP del server remoto:

SSH -L 5901:localhost:5901 utente@server

1. Mantieni aperta la sessione. Questo comando inoltra il traffico VNC ricevuto sulla porta locale 5901 tramite SSH alla stessa porta dell’host remoto.
2. Avvia il client VNC e connettilo a localhost:5901. Ora la comunicazione tra il client e il server VNC è crittografata all’interno del canale SSH.

Questa configurazione consente agli amministratori di proteggere il traffico VNC con una crittografia e un’autenticazione forti, pur mantenendo il pieno controllo grafico di cui hai bisogno.

Anche se funziona bene, non è l’ideale per le sessioni non presidiate e non funziona bene in scala. RealVNC Connect offre una sessione VNC completamente crittografata che elimina la necessità di inoltro e tunneling SSH per Linux, riducendo la complessità e mantenendo l’efficienza e la sicurezza aziendale.

Flussi di lavoro ibridi: Combinare i punti di forza di entrambi

Ci sono casi in cui potresti aver bisogno di entrambe le cose allo stesso tempo. Ad esempio, un Windows Server che funge da jump box per entrare in una sottorete bloccata, dove poi avvii una sessione SSH per accedere ai server situati in quella sottorete.

Su Windows Server, anche OpenSSH è ora integrato e installabile. Ciò significa che gli amministratori possono lanciare Sessioni PowerShell su SSHcombinando il familiare scripting di Windows con il trasporto crittografato che SSH offre durante l’utilizzo di VNC o RDP.

Supporto remoto multipiattaforma per i server

Una cosa che accomuna VNC e SSH è il supporto multipiattaforma. Un singolo client può connettersi a quasi tutti i sistemi. Questa funzionalità rende VNC e SSH ideali per gli amministratori che hanno a che fare con ambienti misti.

Copertura VNC

Un server VNC può essere eseguito su Windows, Linux o MacOS, fornendo un accesso completo al desktop a prescindere dal sistema operativo ospite. Le moderne implementazioni, come RealVNC Connect, possono estendere il supporto a sistemi operativi mobili come Android e iOS, il che significa che gli amministratori possono connettersi a un server Windows o Linux utilizzando solo il proprio smartphone.

Copertura SSH

Anche SSH è quasi universale. La maggior parte delle piattaforme, dei router e delle apparecchiature basate su Unix includono un client SSH di default e, come abbiamo già detto, Microsoft ha integrato OpenSSH direttamente in Windows.

Gli amministratori possono ora lanciare sessioni di PowerShell o CMD attraverso SSH, rendendo più facile la gestione di ambienti eterogenei anche se il negozio di Windows è quasi al completo.

La leadership della tecnologia VNC di RealVNC

RealVNC Connect conosce il VNC. Dopo tutto, l’abbiamo inventato noi. La nostra piattaforma ha avuto un ruolo determinante nel far progredire il protocollo VNC dalle sue origini presso i laboratori AT&T fino alle attuali implementazioni a livello aziendale. Le soluzioni di RealVNC vanno oltre l’accesso remoto di base al desktop, combinando un design sicuro con funzionalità di livello aziendale.

Le principali aree di leadership includono:

• Sviluppo del protocollo: Il lavoro di fondazione dell’architettura originale del VNC Server e i contributi continui agli standard aperti.
• Certificazioni di sicurezza: Audit indipendenti, conformità con i framework e supporto per le strategie Zero Trust.
• Miglioramenti delle prestazioni: Algoritmi di codifica avanzati che riducono la larghezza di banda e mantengono le applicazioni reattive, anche in condizioni di rete non ottimali.
• Integrazioni aziendali: Compatibilità con i sistemi di identità, compresi SSO, PAM e MFA.
• Affidabilità in scala: Supporto per grandi distribuzioni, clustering e configurazioni ad alta disponibilità.
• Servizi professionali: Consulenza, formazione e supporto a lungo termine che aiutano i team IT a implementare e gestire l’accesso remoto in modo sicuro ed efficiente.

La domanda delle aziende continua a crescere per avere strumenti flessibili ma resistenti. RealVNC Connect for enterprise offre queste funzionalità alle organizzazioni che vogliono andare oltre SSH e RDP per le loro esigenze di accesso remoto.

Quadro decisionale per la scelta di VNC vs SSH

La scelta tra VNC e SSH dipende più dal contesto che da una singola “scelta migliore”. I responsabili delle decisioni IT devono valutare:

• Tipo di attività: Le applicazioni guidate dalla GUI hanno bisogno di VNC. Non c’è modo di aggirare l’ostacolo. Se esegui più operazioni testuali e automazioni, soprattutto in ambienti Linux, SSH è l’ideale.
• Abilità dell’utente: Il personale ITSD meno esperto può preferire i flussi di lavoro grafici rispetto alla CLI. Tuttavia, gli utenti più esperti tendono a trarre maggiori vantaggi dall’uso della riga di comando.
• Requisiti di sicurezza: SSH è crittografato per impostazione predefinita. VNC richiede implementazioni aziendali come RealVNC Connect per fornire un accesso remoto veramente sicuro.
• Qualità della rete: SSH è eccellente su collegamenti scadenti, ma se hai personale sul campo che ha bisogno di risolvere i problemi del desktop, SSH non ti aiuterà. Una soluzione di accesso remoto VNC è più ideale in questo caso.

Nella maggior parte delle aziende, una combinazione di entrambi crea flussi di lavoro resilienti per quasi tutti gli scenari di server remoto. RealVNC Connect supporta questo modello duale offrendo un’adozione sicura su tutte le piattaforme.

Conclusione: Selezione strategica della tecnologia

La scelta tra SSH e VNC evidenzia due approcci complementari al moderno accesso remoto. SSH offre un’opzione leggera e criptata per l’amministrazione a riga di comando, mentre VNC offre un’esperienza desktop grafica completa per le interazioni con le applicazioni basate su GUI.

La maggior parte delle aziende trarrà vantaggio dall’implementazione di entrambi i protocolli e dall’abbinamento di ciascuno di essi a compiti specifici e alle competenze degli utenti.

Se la tua organizzazione è più orientata verso il VNC, RealVNC Connect offre soluzioni di livello enterprise, senza tunneling SSH. Contatta RealVNC oggi stesso. I nostri consulenti esperti ti aiuteranno a progettare un’implementazione sicura che si allinei alla tua infrastruttura e ai tuoi requisiti operativi.

Domande frequenti

È possibile utilizzare VNC e SSH insieme?

Sì. Gli amministratori stabiliscono dei tunnel SSH con inoltro delle porte per trasmettere le sessioni del server VNC attraverso un traffico crittografato. La combinazione dell’accesso remoto grafico con l’autenticazione basata su chiavi forti attraverso questo sistema garantisce una maggiore sicurezza.

Quale protocollo è migliore per l’amministrazione del sistema?

Dipende dall’attività da svolgere. SSH è la soluzione migliore per l’esecuzione di script, l’automazione di attività e la revisione dei log su server distanti. VNC è l’opzione migliore per le applicazioni guidate dall’interfaccia grafica e per l’assistenza al Remote Desktop degli utenti.

Quale opzione è più sicura di default?

Tutte le comunicazioni vengono crittografate automaticamente tramite SSH. Il software aziendale RealVNC Connect migliora il protocollo VNC di base con funzioni di crittografia, MFA e auditing, rendendo le sessioni grafiche altrettanto sicure per gli ambienti regolamentati.