SSH StrictModes, agent forwarding (ssh -A) e ssh -a spiegati

In breve: `StrictModes yes` (il valore predefinito di OpenSSH) fa sì che sshd controlli proprietario e permessi della tua home, di `~/.ssh` e di `~/.ssh/authorized_keys` prima di accettare una chiave, e rifiuta il login con «Authentication refused: bad ownership or modes» se uno di questi è scrivibile dal gruppo o da altri o appartiene a un altro utente. Correggi i permessi invece di disattivare il controllo. L'agent forwarding con `ssh -A` permette all'host remoto di usare le tue chiavi locali mentre sei connesso, quindi evitalo sugli host di cui non ti fidi completamente e usa invece `ssh -J` (ProxyJump); `ssh -a` minuscolo disattiva esplicitamente l'agent forwarding.

Questa guida completa la guida all'hardening SSH e si applica a Debian 12/13, Ubuntu 24.04 e ai sistemi della famiglia RHEL come AlmaLinux 9 e Rocky 9.

Cosa controlla SSH StrictModes

StrictModes è un'impostazione lato server in `/etc/ssh/sshd_config`. Il suo scopo è semplice: se un altro utente potesse scrivere nel tuo `authorized_keys`, potrebbe aggiungere la propria chiave ed entrare come te. Per questo sshd rifiuta di fidarsi del file a meno che l'intero percorso non sia protetto. Controlla il file e le directory sopra di esso, compresa la home.

Verifica il valore effettivo con `sshd -T | grep -i strictmodes`. Su Ubuntu 24.04 e Debian 13 controlla anche i file drop-in in `/etc/ssh/sshd_config.d/`.

Risolvere «Authentication refused: bad ownership or modes»

Il client mostra solo un generico `Permission denied (publickey)`. Il vero motivo è nel log del server, che indica il percorso esatto, per esempio `Authentication refused: bad ownership or modes for directory /home/alice` oppure `... for file /home/alice/.ssh/authorized_keys`. Usa la console del VPS o un'altra sessione per correggerlo.

1. 01.Leggi il log: `journalctl -u ssh -n 50` su Debian e Ubuntu, oppure `journalctl -u sshd -n 50` su AlmaLinux e Rocky.
2. 02.Correggi il proprietario della directory SSH dell'utente: `chown -R alice:alice /home/alice/.ssh`.
3. 03.Correggi i permessi: `chmod 700 /home/alice/.ssh` e `chmod 600 /home/alice/.ssh/authorized_keys`.
4. 04.Rimuovi la scrittura per gruppo e altri dalla home: `chmod go-w /home/alice`.
5. 05.Sui sistemi con SELinux (AlmaLinux, Rocky, Fedora), ripristina le etichette: `restorecon -Rv /home/alice/.ssh`.
6. 06.Prova da un nuovo terminale con `ssh -v alice@server` tenendo aperta la sessione funzionante.

# all-in-one, run as root on the server
chown -R alice:alice /home/alice/.ssh
chmod go-w /home/alice
chmod 700 /home/alice/.ssh
chmod 600 /home/alice/.ssh/authorized_keys
namei -l /home/alice/.ssh/authorized_keys   # shows owner and mode of every path component

Note · Non impostare `StrictModes no` per far sparire l'errore. Elimina una protezione reale e nasconde la configurazione sbagliata invece di correggerla.

StrictModes vs StrictHostKeyChecking

Le ricerche di «ssh strictmode» spesso confondono due opzioni che non c'entrano nulla l'una con l'altra. `StrictModes` sta in `sshd_config` sul server e controlla i permessi dei file. `StrictHostKeyChecking` sta in `ssh_config` o `~/.ssh/config` sul client e decide cosa succede quando la host key di un server è sconosciuta o è cambiata. Anche il client ha un proprio controllo dei permessi: rifiuta di usare una chiave privata leggibile da altri utenti, con un avviso su un file di chiave privata non protetto; `chmod 600 ~/.ssh/id_ed25519` lo risolve.

Agent forwarding con ssh -A: il rischio

`ssh -A` (o `ForwardAgent yes`) crea sull'host remoto un socket, indicato da `$SSH_AUTH_SOCK`, che inoltra le richieste di firma all'ssh-agent sulla tua macchina. La tua chiave privata non lascia mai la tua macchina, ma chiunque possa accedere a quel socket può usare la tua chiave mentre sei connesso. Sull'host remoto questo include root e qualsiasi processo in esecuzione con il tuo utente.

Se il server è compromesso, o amministrato da qualcun altro, un attaccante può accedere senza farsi notare a ogni altro host che la tua chiave apre, compresi hosting Git e server di produzione. Ecco perché il client OpenSSH usa per impostazione predefinita `ForwardAgent no`.

• ▹Non inoltrare mai il tuo agent verso host condivisi, di terzi o appena reinstallati che non hai messo in sicurezza.
• ▹Se devi proprio inoltrarlo, usa `ssh-add -c` così ogni uso della chiave richiede una conferma locale.
• ▹OpenSSH 8.9 e successivi supportano vincoli di destinazione con `ssh-add -h`, limitando gli host per cui una chiave inoltrata può essere usata.
• ▹Lato server, `AllowAgentForwarding no` in `sshd_config` lo disattiva, anche se gli utenti con accesso alla shell possono comunque configurare i propri inoltri.

Preferisci ProxyJump (ssh -J) per i bastion

Gran parte dell'agent forwarding serve a passare attraverso un bastion verso una macchina interna. `ssh -J` lo fa senza esporre il tuo agent: il bastion inoltra solo un flusso TCP cifrato, e l'autenticazione verso l'host interno avviene end-to-end dal tuo portatile. Per server raggiungibili solo su una rete privata, un tunnel WireGuard è un'altra opzione; vedi la guida alla VPN WireGuard o la guida alla mesh WireGuard, e per le impostazioni di keepalive e PSK questa guida all'ottimizzazione di WireGuard.

Su un VPS NoctisNode hai root completo via SSH su una macchina KVM, quindi un piccolo piano Wisp può fare da jump host dedicato senza nient'altro in esecuzione; vedi piani VPS.

# one-off
ssh -J [email protected] [email protected]

# ~/.ssh/config
Host bastion
    HostName bastion.example.com
    User alice
    ForwardAgent no

Host db1
    HostName 10.88.0.3
    User alice
    ProxyJump bastion

Cosa fa ssh -a (minuscolo)

`ssh -a` minuscolo disattiva l'agent forwarding per quella connessione, l'opposto di `-A`. È utile quando il tuo `~/.ssh/config` attiva `ForwardAgent` per un host wildcard e vuoi assicurarti che una specifica connessione non inoltri, per esempio `ssh -a admin@untrusted-host`. Non confonderlo con `ssh-agent -a`, che imposta il percorso del socket dell'agent, né con `ssh-add`, che carica le chiavi nell'agent.

FAQ