Chiave SSH su Ubuntu: generala correttamente prima di disabilitare le password

Se si amministra un server Ubuntu tramite SSH, la chiave pubblica deve essere pronta prima di toccare l’autenticazione tramite password. Questo è il punto che troppo spesso vedo invertito: noi rafforziamo sshdRiavviiamo il servizio e scopriamo che la chiave non è mai stata testata correttamente.

In questa guida, partiamo da un elemento chiave ed25519Installiamo la chiave pubblica sul server, apriamo una seconda sessione per testarla e solo dopo disabilitiamo le password. Non richiede più tempo e impedisce di rimanere bloccati fuori dal proprio account.

Crea una chiave SSH ed25519 sul tuo computer

Sul tuo computer locale, genera una chiave ed25519. Questo è il formato che sceglierei oggi per la tipica amministrazione SSH.

ssh-keygen -t ed25519 -a 100 -C "admin@post"

Il comando chiede dove salvare la chiave. Se non si dispone già di una chiave dedicata, è possibile mantenere il percorso suggerito:

~/.ssh/id_ed25519

Aggiungi una passphrase. Su un laptop o un computer che porti fuori dall’ufficio, non lascerei mai una chiave privata senza protezione. La passphrase protegge la chiave nel caso in cui il file venga copiato o se il computer viene compromesso.

Successivamente, verifica che entrambi i file esistano:

ls -l ~/.ssh/id_ed25519 ~/.ssh/id_ed25519.pub

Il file senza estensione .pub è la chiave privata. Non deve essere inviata al server, copiata in un ticket o condivisa. Il file .pub è la chiave pubblica, quella che installerai su Ubuntu.

Installa la chiave pubblica su Ubuntu

Se hai ancora accesso tramite password, il metodo più semplice è ssh-copy-id :

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server

Sostituire utente tramite l’account SSH di destinazione e server tramite indirizzo IP o nome IN. Il comando aggiunge la tua chiave pubblica in ~/.ssh/authorized_keys lato server.

Se ssh-copy-id Se non è disponibile, puoi farlo manualmente da una sessione SSH esistente:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
nano ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Incolla una sola riga: il contenuto completo del tuo file id_ed25519.pubNon incollare mai la chiave privata. Se non sei sicuro, il file pubblico di solito inizia con ssh-ed25519.

Esegui un test in una seconda sessione prima di chiudere quella precedente.

Non chiudere la sessione SSH corrente. Apri un secondo terminale e verifica la connessione con la seguente chiave:

ssh -i ~/.ssh/id_ed25519 user@server

Se accedi al server senza password, la chiave funziona. Se la connessione richiede comunque la password utente, verifica prima i permessi:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys

Su Ubuntu, controlla anche i log SSH per verificare se la chiave viene rifiutata:

sudo journalctl -u ssh -n 80 --no-pager

Un proprietario di cartella errato, una chiave incollata su più righe o un account di destinazione diverso sono tutti elementi sufficienti a bloccare l’autenticazione. Non modificare la configurazione SSH finché questo passaggio non è completato.

Preparare sshd prima di disabilitare le password

Prima di modificare la configurazione, eseguire un backup del file principale:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Successivamente, controlla se ci sono file in /etc/ssh/sshd_config.d/ Definisci già l’autenticazione tramite chiave o password:

sudo grep -R "^PubkeyAuthentication|^PasswordAuthentication" /etc/ssh/sshd_config /etc/ssh/sshd_config.d/*.conf 2>/dev/null

Su Ubuntu, preferisco creare un file dedicato piuttosto che modificare dieci righe nel mezzo del file principale:

sudo nano /etc/ssh/sshd_config.d/99-disable-password.conf

Aggiungere:

Autenticazione tramite chiave pubblica sì
Autenticazione tramite password no

Prima di riavviare SSH, verifica la sintassi. Questo è imprescindibile su un server remoto.

sudo /usr/sbin/sshd -t

Se il comando non restituisce nulla, la sintassi è valida. Se viene visualizzato un errore, correggilo prima di ricaricare.

Ricarica SSH senza interrompere l’accesso

Una volta convalidata la sintassi, ricaricare il servizio:

sudo systemctl reload ssh
sudo systemctl status ssh --no-pager

Mantieni aperta la prima sessione. In un secondo terminale, riprova la connessione tramite chiave:

ssh -i ~/.ssh/id_ed25519 user@server

Verificate inoltre se la connessione senza chiave fallisce, se disponete di un account di prova o di una macchina in cui la chiave non è caricata. L’obiettivo è verificare la realtà dei fatti, non limitarsi a leggere una riga di configurazione.

Se utilizzi SSH su Ubuntu, tieni questa guida a portata di mano. Riavvio di SSH su UbuntuE se hai un firewall locale, controlla anche le tue regole con l’articolo su UFW prima di aprire un server.

I controlli che impediscono il lockdown

• la chiave privata rimane esclusivamente sul tuo computer;
• la chiave pubblica è effettivamente in ~/.ssh/authorized_keys l’utente giusto;
• I diritti sono corretti su ~/.ssh E chiavi_autorizzate ;
• Una seconda sessione SSH per chiave funziona prima di qualsiasi interruzione;
• sudo /usr/sbin/sshd -t non restituisce alcun errore;
• Il firewall continua a consentire la porta SSH corretta.

Se perdi l’accesso SSH dopo una modifica, dovrai utilizzare la console di ripristino, KVM, l’accesso al provider cloud o la modalità di ripristino. Questo metodo mira a evitarlo. Per una riparazione più completa, puoi anche fare riferimento alla guida su una reinstallazione pulita di SSH su Ubuntu.

Per la documentazione ufficiale, Ubuntu mantiene una pagina su OpenSSHServerPagine di riferimento ssh-keygen E ssh-copy-id Descrivono inoltre in dettaglio le opzioni utilizzate.