Configurare SFTP con le chiavi SSH su Mac

L’autenticazione con password su SFTP funziona, e per un server esposto su internet è l’anello più debole che ti resta sotto controllo. Le password vengono riutilizzate, rubate con il phishing e provate a forza bruta da bot che scansionano la porta 22 di continuo. L’autenticazione a chiave elimina tutti e tre i problemi e, una volta configurata, è anche semplicemente più comoda.

L’intera procedura richiede circa cinque minuti.

Come funziona l’autenticazione a chiave

Generi una coppia di chiavi: una chiave privata che non lascia mai il tuo Mac, e una chiave pubblica che puoi distribuire senza rischi. La chiave pubblica va aggiunta in fondo a ~/.ssh/authorized_keys sul server.

Al login il server manda una sfida casuale; il client la firma con la chiave privata; il server verifica la firma con la chiave pubblica che ha già. La chiave privata non viene mai trasmessa, quindi non c’è niente sul filo che un intercettatore possa catturare e niente sul server che un attaccante possa rubare e riutilizzare altrove.

Generare una chiave

Usa ed25519. È più corta, più veloce e più solida di RSA a parità di sicurezza, ed è il valore predefinito ragionevole ormai da anni:

ssh-keygen -t ed25519 -C "carlo@macbook"

Accetta il percorso predefinito (~/.ssh/id_ed25519) e imposta una passphrase. La passphrase cifra la chiave privata sul disco, così un backup rubato del portatile non equivale a un server rubato. macOS può ricordarsela nel Keychain, quindi la digiti una volta sola.

Ora hai due file:

~/.ssh/id_ed25519        ← privata. Non condividerla mai, non copiarla mai su un server.
~/.ssh/id_ed25519.pub    ← pubblica. È questa quella da installare.

Se il tuo server è abbastanza vecchio da rifiutare ed25519 — raro oggi, ma capita su sistemi non aggiornati da tempo — genera invece con -t rsa -b 4096. Upstream supporta entrambe.

Installare la chiave pubblica sul server

Se hai accesso SSH con password, basta un comando:

ssh-copy-id deploy@esempio.it

Se ssh-copy-id non è disponibile, o se hai solo il gestore file di un pannello di controllo, fallo a mano. Copia il contenuto del file .pub e aggiungilo come riga singola a ~/.ssh/authorized_keys sul server, poi sistema i permessi — SSH si rifiuta di usare il file se sono troppo aperti:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Provalo prima di cambiare qualsiasi altra cosa:

ssh -i ~/.ssh/id_ed25519 deploy@esempio.it

Se ti fa entrare senza chiedere la password dell’account, la parte lato server è finita.

Usare la chiave da un client Mac

Qui macOS aggiunge una particolarità che conviene capire invece che combatterla.

Upstream gira in sandbox, lo stesso modello di sicurezza sotto cui girano il Finder e ogni app dell’App Store. Un’app in sandbox non può leggere percorsi arbitrari, e ~/.ssh è a tutti gli effetti un percorso arbitrario — non può frugare in silenzio tra le tue chiavi private, che è esattamente il punto.

Perciò la prima volta che un sito ha bisogno di una chiave, Upstream ti chiede di selezionare il file con un normale pannello di apertura. È quel consenso ad autorizzare l’accesso; da lì in poi il materiale della chiave viene conservato nel tuo Keychain e la connessione funziona senza chiedere più nulla. La passphrase, se l’hai impostata, viene custodita insieme.

È anche il motivo per cui importare ~/.ssh/config porta dentro il percorso di ogni IdentityFile e non la chiave stessa: il percorso è un appunto su quale chiave chiedere, e l’autorizzazione la dai una volta alla prima connessione.

Per configurarlo: apri il sito, scegli SFTP, imposta l’autenticazione a chiave invece che a password, seleziona il file della chiave, inserisci la passphrase se la chiave ne ha una, e connettiti.

Disattivare il login con password

Quando le chiavi funzionano per tutti gli account che usi, disattiva del tutto l’autenticazione con password. È questo il passaggio che elimina davvero l’esposizione agli attacchi a forza bruta: finché non lo fai, la password resta una via d’ingresso valida.

In /etc/ssh/sshd_config sul server:

PasswordAuthentication no
PubkeyAuthentication yes

Poi ricarica il demone SSH. Tieni aperta la sessione che hai già mentre provi una nuova connessione in una seconda finestra: se qualcosa non va, ti serve una strada di ritorno che non passi dalla console del tuo provider.

Passo per passo

1. Genera una coppia di chiavi ed25519 con ssh-keygen -t ed25519 -C "una-tua-nota", e imposta una passphrase quando te la chiede.
2. Installa la chiave pubblica con ssh-copy-id utente@host, oppure aggiungi a mano il contenuto del .pub a ~/.ssh/authorized_keys.
3. Sistema i permessi sul server — chmod 700 ~/.ssh e chmod 600 ~/.ssh/authorized_keys, altrimenti SSH ignora il file.
4. Prova dal Terminale con ssh -i ~/.ssh/id_ed25519 utente@host prima di coinvolgere un client grafico.
5. Indica la chiave al client — in Upstream imposta il sito sull’autenticazione a chiave e seleziona il file una volta; per via della sandbox di macOS questo consenso è esplicito, e da lì in poi resta nel Keychain.
6. Disattiva l’autenticazione con password sul server, provando in una seconda sessione prima di chiudere la prima.

Domande frequenti

Che tipo di chiave conviene usare, ed25519 o RSA?

ed25519, a meno che il server non sia troppo vecchio per accettarla. È più veloce, le chiavi sono molto più corte e il suo margine di sicurezza è almeno pari a quello di RSA-4096. Upstream supporta entrambi i tipi.

Serve davvero una passphrase sulla chiave?

Fortemente consigliata. Senza, chiunque ottenga il file — da un backup, da una cartella sincronizzata, da un portatile rubato — ha il tuo server. Con la passphrase, il file da solo non serve a niente. macOS se la ricorda nel Keychain, quindi il costo è una singola richiesta.

Perché l’app mi chiede di scegliere il file della chiave invece di trovarlo da sola?

Perché gira in sandbox e non può leggere ~/.ssh senza il tuo consenso esplicito. È una proprietà di sicurezza, non un limite: la stessa regola impedisce a qualsiasi app dell’App Store di leggersi in silenzio le tue chiavi private.

Posso usare la stessa chiave per più server?

Sì, ed è una pratica comune. Se però vuoi poter revocare l’accesso a un singolo server in modo indipendente, genera una chiave separata per ciascuno.

L’autenticazione a chiave funziona con FTP o FTPS?

No. Le chiavi SSH sono un concetto di SSH, quindi valgono solo per SFTP. FTPS autentica il server con un certificato, ma continua ad autenticare te con una password.

La chiave funziona nel Terminale ma non nel client. Perché?

Nella maggior parte dei casi al client è stata indicata la chiave pubblica (.pub) invece di quella privata, oppure la chiave è in un vecchio formato PEM che il client non interpreta. Rigenerarla con ssh-keygen nel formato OpenSSH predefinito risolve.