1 17/10/2026 11 min

Perché VS Code Server su AlmaLinux e Rocky Linux 8

VS Code Server ha senso quando vuoi usare l’editor sul tuo portatile ma far girare il lavoro pesante su una macchina Linux remota: VM, server di sviluppo, jump host o nodo applicativo. Su AlmaLinux e Rocky Linux 8 il punto critico non è tanto “installarlo”, quanto farlo funzionare in modo ripetibile, con SSH stabile, librerie compatibili e un minimo di controllo operativo. Se tratti l’ambiente come una workstation improvvisata, prima o poi ti ritrovi con sessioni che cadono, estensioni che non partono o aggiornamenti che si rompono dopo un upgrade del sistema.

Qui l’obiettivo è semplice: ottenere una installazione pulita, accessibile via SSH, con un profilo utente dedicato o comunque ben definito, e con una procedura di verifica che ti dica subito se il problema è nel layer SSH, nel runtime del server o nei permessi della home. Non c’è magia: VS Code Server è solo un processo utente che ascolta su una porta locale e viene instradato tramite tunnel SSH. Se SSH non è sano, il resto è rumore.

Prerequisiti reali: SSH, home scrivibile e pacchetti base

Prima di aprire VS Code sul client, verifica il server Linux con tre controlli minimi: accesso SSH senza ambiguità, home dell’utente scrivibile e tool di base presenti. Su AlmaLinux e Rocky Linux 8 la parte più comune di errore è una home montata con permessi strani, o un ambiente con SELinux e policy troppo restrittive per il contesto d’uso.

Installa i pacchetti che di solito servono per il bootstrap e per eventuali estensioni native:

sudo dnf install -y curl tar gzip unzip git openssh-server openssh-clients ca-certificates

Verifica che SSH sia attivo e che l’utente con cui ti colleghi abbia una home reale, non un placeholder o una directory in sola lettura:

systemctl status sshd --no-pager
getent passwd <utente>
ls -ld /home/<utente>
test -w /home/<utente> && echo OK || echo KO

Se il comando `test -w` fallisce, non insistere con VS Code: il server non riuscirà a scrivere i file del proprio runtime, delle estensioni e della cache. In quel caso correggi prima ownership e permessi, oppure scegli un utente dedicato con home persistente.

Connessione via SSH: il vero punto di ingresso

VS Code Remote - SSH non richiede di aprire porte aggiuntive verso Internet. Il flusso corretto è: il client si collega in SSH al server, copia o aggiorna il componente server nella home dell’utente e poi apre un tunnel locale. Questo significa che la qualità della connessione SSH determina la qualità dell’esperienza. Se hai timeout, banner troppo lunghi, o autenticazione con catene di jump host fragili, il sintomo apparente sarà “VS Code non si collega”, ma il problema è altrove.

Conferma il collegamento base prima di coinvolgere l’editor:

ssh -v <utente>@<host>

Nel debug verboso controlla almeno questi punti: autenticazione completata, shell remota disponibile, nessun messaggio che blocchi la sessione in fase di login, e assenza di banner o script di profilo che stampano output indesiderato. Un `.bashrc` rumoroso può rompere il bootstrap del server quanto un firewall mal configurato.

Se usi chiavi SSH, evita password in chiaro e preferisci un file `~/.ssh/config` pulito sul client. Un esempio minimo:

Host alma-vscode HostName 192.0.2.10 User devops IdentityFile ~/.ssh/id_ed25519 ServerAliveInterval 30 ServerAliveCountMax 3

Il parametro `ServerAliveInterval` aiuta a tenere viva la sessione su reti instabili. Non risolve un problema di routing o di NAT aggressivo, ma riduce i falsi positivi in sessioni lunghe.

Installazione dal client: il metodo corretto e quello da evitare

Il modo più pulito per usare VS Code Server su AlmaLinux e Rocky Linux 8 è partire dal client VS Code con l’estensione Remote - SSH. Non serve scaricare manualmente pacchetti strani sul server se non hai un’esigenza precisa. Il client gestisce versione, compatibilità e aggiornamenti del componente server in modo coerente con la release locale dell’editor.

  1. Installa sul client l’estensione Remote - SSH.
  2. Apri la palette comandi e scegli Remote-SSH: Connect to Host....
  3. Seleziona l’host definito nel file `~/.ssh/config` oppure inserisci `utente@host`.
  4. Attendi il bootstrap: il client scarica il server nella home dell’utente remoto, in genere sotto `~/.vscode-server/`.
  5. Apri una cartella remota e verifica che il terminale integrato funzioni.

Durante la prima connessione il server viene installato o aggiornato automaticamente. Su sistemi con policy restrittive o storage limitato, questa fase fallisce spesso per mancanza di spazio nella home. Il path da controllare subito è `~/.vscode-server/` o, in alcune build, `~/.vscode-remote/`.

Se preferisci un controllo più manuale, puoi verificare che la directory esista e che contenga binari e log della sessione:

ls -la ~/.vscode-server
find ~/.vscode-server -maxdepth 2 -type f | head

Se la directory non compare dopo il primo tentativo di connessione, il problema è quasi sempre prima del bootstrap: SSH non stabile, shell remota non compatibile, home non scrivibile o blocco di rete verso il download iniziale del server.

Compatibilità su AlmaLinux e Rocky Linux 8: librerie, glibc e toolchain

AlmaLinux 8 e Rocky Linux 8 condividono la stessa base RHEL 8, quindi il comportamento del server è molto simile. Il punto delicato è la compatibilità delle librerie di sistema e degli eventuali binari caricati da estensioni o tool esterni. In ambienti minimal, il server parte, ma alcune estensioni falliscono perché mancano dipendenze banali come `tar`, `gzip`, `git` o certificati CA aggiornati.

Se lavori con repository Git, container, Python o tool di compilazione, conviene avere installato un baseline più robusto:

sudo dnf groupinstall -y "Development Tools"
sudo dnf install -y python3 perl findutils which procps-ng

Non è obbligatorio per il solo server VS Code, ma evita il classico effetto “si connette, poi non riesco a usare nulla”. Le estensioni remote spesso delegano a utility di sistema che in installazioni minimali non sono presenti o non sono nel PATH.

Per capire se il nodo è sano, controlla versione del sistema e presenza di spazio disco sufficiente:

cat /etc/redhat-release
df -h ~
df -ih ~

Lo spazio inode è spesso ignorato, ma su home con tanti file temporanei o cache di estensioni può diventare il vero collo di bottiglia anche quando i GB liberi sembrano abbondanti.

SELinux, firewall e porte: cosa serve davvero

Per l’uso standard di VS Code Server non devi esporre una porta pubblica aggiuntiva. Il server vive dietro SSH e il traffico applicativo passa nel tunnel. Questo riduce la superficie d’attacco e semplifica il firewall. Se ti trovi a dover aprire porte custom, di solito stai cercando di usare il prodotto in modo non allineato al modello previsto.

Controlla comunque che SSH sia raggiungibile e che il firewall locale non stia bloccando la porta 22 o quella custom, se l’hai cambiata:

sudo firewall-cmd --list-all
sudo ss -tlnp | grep sshd

Con SELinux in enforcing, in genere VS Code Server non richiede policy speciali se resta nella home dell’utente. Se però usi path non standard, mount particolari o directory con contesti modificati, verifica il contesto SELinux del path:

ls -Zd /home/<utente>
ls -Zd ~/.vscode-server

Se trovi contesti anomali, non disabilitare SELinux a caso. Prima identifica il messaggio nei log e correggi il contesto o il mount point. Disattivarlo per “far partire tutto” ti lascia un problema di sicurezza e uno operativo in più.

Hardening minimo: account, chiavi e superficie d’attacco

Su un server usato come ambiente remoto di sviluppo, la sicurezza non è un layer opzionale. Il minimo sensato è: accesso SSH con chiavi, password login disabilitato se non serve, account dedicato per sviluppo e nessun privilegio amministrativo permanente. Se il nodo ospita anche altri servizi, separa gli utenti e non usare root per comodità.

Nel file `/etc/ssh/sshd_config` le impostazioni da valutare sono queste:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Dopo una modifica a SSH, testa la configurazione prima di ricaricare il servizio:

sudo sshd -t
sudo systemctl reload sshd

Questo è il tipo di cambio che va fatto con prudenza: un errore di sintassi su `sshd_config` può tagliarti fuori dal server. Tieni sempre una sessione SSH aperta di fallback e, se sei su un host remoto, una console out-of-band o un accesso alternativo prima del reload.

Se vuoi ridurre ulteriormente l’esposizione, limita gli host sorgente con `AllowUsers` o `AllowGroups` e usa chiavi dedicate per ambiente. Evita di riutilizzare la stessa chiave personale su macchine che hanno ruoli diversi.

Uso pratico: aprire una cartella remota e lavorare senza attriti

Una volta stabilita la connessione, il flusso corretto è aprire una directory specifica, non l’intero filesystem. Questo migliora la reattività, riduce il rumore nel file watcher e limita gli effetti collaterali di progetti enormi o di directory con milioni di file temporanei.

Usa una struttura ordinata, ad esempio `~/projects/app1`, `~/projects/app2`, e non lavorare direttamente in path condivisi o montati in NFS senza verificare le performance. I watcher di VS Code soffrono facilmente su storage lenti o con latenza alta.

Se il terminale integrato non apre correttamente, il controllo utile è semplice: il server remoto è partito, la shell è disponibile e il PATH contiene gli strumenti di base. Se il terminale mostra errori di avvio, spesso il problema è nel profilo utente (`.bashrc`, `.bash_profile`, `.profile`) o in un ambiente shell non interattivo che stampa output indesiderato.

Un test rapido di coerenza lato shell è questo:

ssh <utente>@<host> 'echo $SHELL; uname -r; whoami'

Se il comando produce testo extra prima o dopo, hai già un indizio: qualcosa nel login remoto sta sporcando l’output e può interferire con il bootstrap del server.

Troubleshooting: i guasti più comuni e come isolarli

Quando VS Code Server non parte su AlmaLinux o Rocky Linux 8, conviene ragionare per layer. Prima SSH, poi home e permessi, poi spazio disco, infine runtime del server. Questo ti evita di fare reinstallazioni inutili o di cancellare directory a caso.

  1. SSH non si connette: prova `ssh -v utente@host` e controlla `sshd` con `systemctl status sshd`. Se fallisce qui, VS Code non c’entra nulla.
  2. Connessione SSH ok, ma VS Code resta in “setting up”: verifica `~/.vscode-server/` e lo spazio con `df -h ~`. Se la home è piena, libera spazio o cambia destinazione del profilo utente.
  3. Editor aperto ma estensioni non caricano: controlla dipendenze base e log del server remoto. Se usi estensioni native, verifica compatibilità con l’architettura del nodo.

Per vedere i log del server remoto, il path esatto può variare in base alla versione, ma in genere trovi file sotto la home dell’utente dentro `~/.vscode-server/` o sottodirectory di log legate alla build corrente. Se il client mostra un codice di errore, recupera prima quel codice: è molto più utile del generico “non si connette”.

Se sospetti un problema di rete verso il download iniziale, un test semplice è verificare che il server raggiunga gli endpoint necessari per il bootstrap. In ambienti chiusi, proxy e filtri DNS possono bloccare il recupero del componente. In quel caso la soluzione non è reinstallare VS Code, ma consentire il traffico richiesto oppure pre-posizionare il server nel modo corretto per la tua policy.

Aggiornamenti e manutenzione: evitare drift e installazioni sporche

VS Code Server cambia versione in base al client. Questo è comodo, ma introduce drift se il server viene usato da più operatori con build diverse di VS Code. Il risultato tipico è una serie di directory server accumulate nella home e un consumo disco che cresce nel tempo. Vale la pena programmare una pulizia ragionata, senza cancellare alla cieca l’intera home.

Controlla periodicamente cosa occupa spazio:

du -sh ~/.vscode-server/* 2>/dev/null | sort -h

Se trovi vecchie build inutilizzate, puoi rimuoverle solo dopo aver verificato che nessuna sessione le stia usando. La regola pratica è semplice: chiudi le sessioni, conferma che non ci siano processi attivi del server, poi pulisci i residui. Non farlo mentre qualcuno è ancora collegato.

Per l’osservabilità minima tieni sotto mano anche questi controlli:

journalctl -u sshd --since "1 hour ago" --no-pager
ss -tnp | grep ':22'
free -h

Non sono comandi spettacolari, ma ti dicono subito se il problema è di accesso, saturazione memoria o stabilità del servizio SSH.

Checklist operativa finale

Se vuoi una procedura rapida e affidabile, l’ordine giusto è questo: verifica SSH, verifica permessi home, controlla spazio disco, connetti da VS Code, poi osserva i log del server remoto solo se qualcosa fallisce. È un percorso banale, ma è quello che evita il 90% dei tentativi a vuoto.

  1. Conferma `sshd` attivo e raggiungibile.
  2. Conferma che l’utente abbia una home scrivibile.
  3. Conferma spazio e inode liberi nella home.
  4. Connetti VS Code con Remote - SSH e attendi il bootstrap.
  5. Se fallisce, raccogli il codice errore e i log sotto `~/.vscode-server/` prima di cambiare qualcosa.

Su AlmaLinux e Rocky Linux 8 il server funziona bene se lo tratti come un servizio utente serio, non come un accessorio dell’editor. La differenza la fanno i dettagli: SSH pulito, home corretta, dipendenze minime e un po’ di disciplina sui permessi. Se questi quattro elementi sono sotto controllo, VS Code Server diventa uno strumento stabile e molto comodo per sviluppo e amministrazione remota.