Tag: windows

Ho quattro macchine su cui lavoro regolarmente: due desktop (uno Windows, uno Ubuntu) e due laptop (anche qui, uno per sistema). A questi si aggiungono alcuni server Linux VPS a cui mi collego per vari progetti. Sono tanti endpoint, tante chiavi SSH e tanti profili di terminale da tenere sincronizzati.

Per un po’ ho semplicemente convissuto col caos. Ogni volta che configuravo una nuova macchina, o reinstallavo un sistema operativo, ripetevo lo stesso rituale: ricreare la configurazione SSH, copiare le chiavi in qualche modo, reinserire tutti gli alias degli host, riconfigurare colori e font del terminale. E ogni volta che cambiavo qualcosa su una macchina — un nuovo server da aggiungere, una nuova chiave da registrare — dovevo ricordarmi di replicare quella modifica su tutte le altre. Inevitabilmente, me ne dimenticavo. Le configurazioni divergevano. Una macchina aveva l’alias, un’altra no. Era una seccatura lenta e sotterranea, che non raggiungeva mai il livello di crisi, ma non spariva mai.

Alla fine ho deciso di risolvere il problema per davvero. La soluzione che ho trovato è semplice nel concetto, solida nella pratica, e richiede circa venti minuti di configurazione iniziale.

L’idea di fondo: una cartella sola, ovunque

Il ragionamento è questo: invece di tenere chiavi SSH e file di configurazione sparsi su ogni singola macchina, si mette tutto in un’unica cartella all’interno del proprio cloud storage — OneDrive, Dropbox, Google Drive, qualunque si usi già. Ogni macchina poi punta a quella cartella, invece di mantenere una copia separata.

Il meccanismo che rende possibile tutto questo si chiama collegamento simbolico (o symlink). Funziona come un cartello stradale: quando il client SSH cerca il suo file di configurazione nel posto solito, trova un cartello che lo reindirizza alla cartella condivisa sul cloud. Dall’esterno non cambia nulla. Sotto il cofano, tutte le macchine leggono dalla stessa unica fonte di verità.

Su Windows i collegamenti simbolici funzionano allo stesso modo — ed è la scelta giusta anche lì. Forse hai sentito parlare degli hard link, un concetto correlato, ma gli hard link funzionano solo all’interno dello stesso disco. Dato che la cartella del cloud storage di solito si trova su un percorso diverso (o addirittura su un disco diverso) rispetto al profilo utente, i collegamenti simbolici sono la scelta corretta anche su Windows.

Un prerequisito importante: il client di cloud storage deve essere configurato per mantenere i file disponibili localmente, non solo nel cloud. Su OneDrive questa opzione si chiama “Mantieni sempre su questo dispositivo”. I file devono trovarsi fisicamente su disco, accessibili anche offline.

Creare la cartella condivisa

All’interno della directory sincronizzata col cloud, crea questa struttura:

~/CloudSync/ssh-terminal/
├── ssh/
│   ├── config
│   ├── id_ed25519_workstation
│   ├── id_ed25519_server
│   └── id_ed25519_development
└── terminals/
    ├── windows-terminal.json
    └── gnome-terminal-profiles/

La sottocartella ssh/ contiene le chiavi SSH e il file di configurazione. La sottocartella terminals/ contiene le impostazioni dei terminali. Vedremo come popolarle entrambe nei passi successivi.

Il file di configurazione SSH

SSH legge le sue impostazioni da un file di testo semplice chiamato config, normalmente situato in ~/.ssh/config. È lì che si definiscono gli alias degli host, si specifica quale chiave usare per quale server, si impostano le opzioni di connessione. Se non l’hai mai usato, è una di quelle cose che, una volta scoperte, ti chiedi come hai fatto a farne a meno.

Un esempio tipico di configurazione:

# Esempio di configurazione SSH condivisa
Host server-produzione
    HostName 192.168.1.100
    User administrator
    IdentityFile ~/.CloudSync/ssh-terminal/ssh/id_ed25519_production
    Port 22

Host sviluppo
    HostName dev.example.com
    User developer
    IdentityFile ~/.CloudSync/ssh-terminal/ssh/id_ed25519_development

Nota che i percorsi di IdentityFile usano il carattere ~ (tilde) per rappresentare la home directory. Vale la pena capire esattamente cosa significa, perché è il segreto della portabilità.

Su Linux e su Windows, ogni utente ha una home directory: una cartella personale dove il sistema conserva file, impostazioni e configurazioni. Su Linux è tipicamente /home/tuonome, su Windows C:\Users\tuonome. Il carattere tilde (~) è un’abbreviazione che sia Bash su Linux che PowerShell su Windows espandono automaticamente alla home directory dell’utente corrente. Quindi ~/.ssh/config diventa /home/tuonome/.ssh/config su Linux, e C:\Users\tuonome\.ssh\config su Windows.

Questo è ciò che rende il file di configurazione davvero portabile: dato che ogni macchina espande ~ alla propria home directory locale, la stessa riga funziona ovunque senza modifiche. Se avessimo scritto il percorso completo — /home/luca/CloudSync/... — funzionerebbe solo sulle macchine in cui il nome utente e la struttura delle directory coincidono esattamente.

Una volta che il file config è pronto nella cartella condivisa, lo si collega al percorso che SSH si aspetta:

New-Item -ItemType SymbolicLink `
  -Path "$env:USERPROFILE\.ssh\config" `
  -Target "$env:USERPROFILE\CloudSync\ssh-terminal\ssh\config"

ln -sf ~/CloudSync/ssh-terminal/ssh/config ~/.ssh/config

Da questo momento in poi, modificare il file di configurazione nella cartella cloud lo aggiorna istantaneamente su tutte le macchine. Aggiungi un nuovo server sul desktop, e il laptop lo conoscerà già alla prossima sincronizzazione.

Profili del terminale: Windows Terminal

Windows Terminal conserva l’intera configurazione — profili, schemi di colori, font, scorciatoie da tastiera — in un unico file JSON. Questo lo rende un candidato ideale per questo approccio.

Il file si trova in:

$env:LOCALAPPDATA\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json

Chiudi Windows Terminal, poi sostituisci quel file con un collegamento simbolico alla copia condivisa:

# Esegui in PowerShell come Amministratore, con il Terminale chiuso
New-Item -ItemType SymbolicLink `
  -Path "$env:LOCALAPPDATA\Packages\Microsoft.WindowsTerminal_8wekyb3d8bbwe\LocalState\settings.json" `
  -Target "$env:USERPROFILE\CloudSync\ssh-terminal\terminals\windows-terminal.json"

È anche possibile definire profili SSH direttamente all’interno della configurazione di Windows Terminal, in modo che i server specifici appaiano come voci con nome nel menu a tendina:

{
    "$schema": "https://aka.ms/terminal-profiles-schema",
    "profiles": {
        "list": [
            {
                "name": "SSH Produzione",
                "commandline": "ssh server-produzione",
                "icon": "ms-appx:///ProfileIcons/server.png"
            }
        ]
    }
}

Profili del terminale: GNOME Terminal e Ptyxis su Ubuntu

Sia GNOME Terminal che Ptyxis conservano la propria configurazione in dconf, un database di impostazioni a basso livello usato in tutto l’ambiente desktop GNOME. Pensalo come l’equivalente GNOME del Registro di sistema di Windows: un database strutturato dove le applicazioni memorizzano le proprie preferenze. Non c’è un singolo file a cui creare un collegamento, ma è possibile esportare e importare l’intera configurazione come uno snapshot in testo semplice usando lo strumento da riga di comando dconf.

L’approccio è identico per entrambi i terminali — cambia solo il percorso all’interno del database dconf.

GNOME Terminal

Per esportare i profili attuali:

dconf dump /org/gnome/terminal/legacy/profiles:/ \
  > ~/CloudSync/ssh-terminal/terminals/gnome-terminal-profiles/profiles.dconf

Per ripristinarli su un’altra macchina:

dconf load /org/gnome/terminal/legacy/profiles:/ \
  < ~/CloudSync/ssh-terminal/terminals/gnome-terminal-profiles/profiles.dconf

Ptyxis

Ptyxis è un emulatore di terminale più recente, ora predefinito nelle distribuzioni basate su GNOME più aggiornate, come Fedora 41 e Ubuntu 25.10. Usa un percorso dconf diverso:

dconf dump /org/gnome/Ptyxis/ \
  > ~/CloudSync/ssh-terminal/terminals/ptyxis-profiles/profiles.dconf

Per ripristinare:

dconf load /org/gnome/Ptyxis/ \
  < ~/CloudSync/ssh-terminal/terminals/ptyxis-profiles/profiles.dconf

Automatizzare il ripristino dei profili all’avvio

È possibile automatizzare il ripristino in modo che i profili vengano applicati automaticamente ad ogni accesso, aggiungendo un controllo al proprio profilo di shell (~/.profile). Adatta il percorso e la chiave dconf al terminale che utilizzi:

#!/bin/bash
# Per GNOME Terminal:
if [[ -f ~/CloudSync/ssh-terminal/terminals/gnome-terminal-profiles/profiles.dconf ]]; then
    dconf load /org/gnome/terminal/legacy/profiles:/ \
      < ~/CloudSync/ssh-terminal/terminals/gnome-terminal-profiles/profiles.dconf
fi

# Per Ptyxis:
if [[ -f ~/CloudSync/ssh-terminal/terminals/ptyxis-profiles/profiles.dconf ]]; then
    dconf load /org/gnome/Ptyxis/ \
      < ~/CloudSync/ssh-terminal/terminals/ptyxis-profiles/profiles.dconf
fi

Una nota sulla sicurezza

Conservare chiavi SSH private in una cartella sincronizzata col cloud è un compromesso ragionevole, ma richiede alcune precauzioni.

Usa sempre le passphrase

Ogni chiave privata deve essere protetta da una passphrase robusta. Questo garantisce che anche se qualcuno dovesse accedere al tuo cloud storage, non potrebbe usare le chiavi senza conoscere la passphrase. Per generare le chiavi:

ssh-keygen -t ed25519 -a 100 -C "workstation@$(hostname)" \
  -f ~/CloudSync/ssh-terminal/ssh/id_ed25519_$(hostname)

Il flag -t ed25519 seleziona un algoritmo moderno ed efficiente. Il flag -a 100 aumenta il numero di cicli di derivazione della chiave, rendendo significativamente più difficile un attacco a forza bruta sulla passphrase.

Usa chiavi separate per ogni dispositivo

Invece di condividere una singola coppia di chiavi su tutte le macchine, mantieni chiavi distinte per dispositivo o livello di fiducia:

• Workstation principale: id_ed25519_workstation
• Sistemi secondari: id_ed25519_backup
• Ambienti di sviluppo: id_ed25519_development

In questo modo, se una macchina viene compromessa, puoi revocare solo quella chiave senza influire su tutto il resto.

Limita i permessi sui file

SSH su Linux si rifiuterà di usare chiavi con permessi troppo permissivi — quindi questo passaggio non è opzionale.

Quando qualcosa va storto

Alcuni problemi che potresti incontrare, e come risolverli:

Per andare oltre: configurazione condizionale

SSH supporta gli include condizionali, che permettono di caricare blocchi di configurazione diversi a seconda del sistema operativo o di altre condizioni. È utile se hai alcune impostazioni che differiscono genuinamente tra Windows e Linux:

# ~/.ssh/config
Include ~/.ssh/config.d/common.conf

Match exec "uname -s | grep -q ^Linux"
    Include ~/.ssh/config.d/linux.conf

Il file comune contiene tutto ciò che è condiviso tra le macchine. I file specifici per piattaforma gestiscono le eccezioni.

Il risultato

Una volta messo in piedi, configurare una nuova macchina richiede circa cinque minuti: installa il client di cloud sync, aspetta che la cartella si scarichi, esegui due o tre comandi di collegamento, fatto. Ogni alias degli host, ogni chiave, ogni schema di colori del terminale — già lì, esattamente come li hai lasciati sulle altre macchine.

Ma la cosa più importante è un’altra: quando fai una modifica — aggiungi un nuovo server, ruoti una chiave, ritocchi un profilo del terminale — la fai una volta sola, e si propaga ovunque automaticamente. Niente più replicazione manuale. Niente più configurazioni che divergono. Niente più sorprese quando ti siedi a una macchina e scopri che è rimasta indietro.

È una di quelle soluzioni che, una volta installata, dimentichi di avere. Ed è esattamente questo il punto.