SSH è una di quelle tecnologie che usiamo ogni giorno, quasi in automatico: ci connettiamo, copiamo file, facciamo tunnel verso servizi remoti — e raramente ci chiediamo se potremmo farlo meglio.
Partendo da una semplice “cheat sheet” piena di comandi copia‑e‑incolla, ho provato a trasformare tutto in una guida ragionata: più ordine, più sicurezza, meno fatica.

SSH oltre la cheat sheet

Le cheat sheet elencano opzioni utili, ma difficilmente aiutano a costruire un flusso di lavoro stabile. L’idea di fondo è semplice: spostare la complessità nei file giusti e fare in modo che SSH lavori per noi, non contro di noi.
In pratica significa:

• gestire correttamente le chiavi;
• usare davvero ~/.ssh/config;
• velocizzare le connessioni con multiplexing;
• passare senza dolore da un bastion all’altro;
• rendere più sicuro il server SSH.

Mani in pasta

Se ancora usi rsa da 4096 bit, è ora di cambiare. Le chiavi ed25519 sono oggi lo standard: rapide, sicure e più semplici da gestire.

NB: RSA funziona ancora, ma richiede chiavi grandi ed è più fragile dal punto di vista implementativo. ed25519 nasce invece con criteri moderni: è più veloce, più sicuro a parità di forza crittografica e riduce drasticamente gli errori. Per questo oggi è lo standard consigliato per SSH.

Creare una chiave moderna

ssh-keygen -t ed25519 -a 100 -C "marvin@laptop"

Questo comando genera la chiave privata (id_ed25519) e la pubblica (id_ed25519.pub).
Proteggila con una passphrase robusta: ti salva se la chiave finisce su un disco sbagliato.

Per installarla sul server, usa ssh-copy-id:

ssh-copy-id [email protected]

e dimentica il copia‑incolla su authorized_keys.

Alcune buone abitudini

• Una chiave per persona, non per gruppo.
• Chiavi distinte per contesti diversi (lavoro, test, personale).
• Permessi stretti (chmod 600) sulla directory ~/.ssh.
• Rotazione periodica e controllo delle chiavi presenti sui server.

Multiplexing e jump host

SSH non serve solo a “entrare in un server”.
Con un paio di opzioni si può rendere tutto più veloce e flessibile.

Multiplexing: connessioni istantanee

Nel tuo ~/.ssh/config puoi impostare:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/sockets/%r@%h-%p
    ControlPersist 10m

La prima connessione apre il canale, le successive lo riutilizzano.
scp, git, rsync: tutto diventa immediato.

Jump host con ProxyJump

Chi lavora dietro bastion lo sa bene: due SSH aperti in cascata sono un incubo.

Host bastion
    HostName bastion.example.com
    User marvin

Host internal-*
    ProxyJump bastion
    User marvin

Con questa configurazione:

ssh internal-db01

salta automaticamente attraverso bastion, senza comandi lunghi o doppi hop manuali.

Port forwarding e tunnel

Due righe che salvano la giornata:

• Local forwarding: accedi localmente a un servizio remoto.

  ssh -L 8080:localhost:80 marvin@server
  

• Remote forwarding: esponi un servizio locale verso un server remoto.

  ssh -R 2222:localhost:22 marvin@server
  

Tunnel potentissimi, ma da usare con prudenza: su server multi‑utente o esposti pubblicamente, possono creare canali imprevisti verso reti interne.

Gestione avanzata di ~/.ssh/config

Per chi amministra decine, centinaia o migliaia di macchine, il file ~/.ssh/config diventa un piccolo capolavoro di configurazione. Ecco le opzioni per sysadmin esperti.

Include per configurazioni esterne

Suddividi la config in file tematici:

~/.ssh/config:
Include config-work.conf
Include config-lab.conf

# ~/.ssh/config-work.conf
Host work-*
    User marvin
    IdentityFile ~/.ssh/id_ed25519_work
    ProxyJump bastion.work.example.com

Così gestisci ambienti separati senza un file monolitico ingestibile.

Match per condizioni dinamiche

Applica regole basate su rete, utente o altro:

Match exec "ip route | grep -q via 10.0.0.1"
    ProxyJump vpn-gateway

Match user root final
    PermitLocalCommand no

• Il primo Match attiva automaticamente il jump se sei dietro una VPN specifica.
• Il secondo blocca comandi locali pericolosi quando ti connetti come root.

Esempi pratici per Proxmox e container

Per chi usa Proxmox o swarm:

Host px-*
    HostName %h.proxmox.local
    User root
    Port 22
    IdentityFile ~/.ssh/id_ed25519_proxmox

Host swarm-*
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_swarm
    ControlPersist 1h

ssh px-node01 ti porta direttamente sul nodo Proxmox; ssh swarm-worker03 si connette al worker Docker con multiplexing lungo (1 ora).

Mettere in sicurezza SSH lato server

Lato server, l’obiettivo è abbattere la superficie d’attacco e rendere più difficile ogni tentativo di accesso non autorizzato.

Impostazioni consigliate in /etc/ssh/sshd_config

Protocol 2
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
AllowUsers marvin backup

Cosa andiamo a fare:

• vietare il login diretto di root;
• disabilitare l’autenticazione con password;
• limitare i tentativi di accesso;
• consentire solo gli utenti esplicitamente previsti.

In più, usare fail2ban, un firewall che limiti gli IP ammessi, o servizi come CrowdSec può ridurre drasticamente gli attacchi automatizzati.

Una SSH “ordinata” e sicura

In breve:

• chiavi ed25519, una per contesto e protetta da passphrase:
• ~/.ssh/config curato con alias, multiplexing, Include e Match per scenari complessi;
• ProxyJump per lavorare dietro bastion senza fatica;
• server senza accesso con password, login root disabilitato e regole di accesso minime;
• monitoraggio e rotazione delle chiavi nel tempo.

SSH non è solo un comando da terminale, è parte della tua infrastruttura personale.
Fatta bene, ti toglie attrito e riduce i rischi. Fatta male, diventa la scorciatoia più pericolosa del tuo sistema.

Le opinioni in quanto tali sono opinabili e nulla ti vieta di approfondire l’argomento.

Risorse:

• openssh
• Crowdsec
• Canale Telegram