Rocky Linux: consentire l’accesso SSH a root con chiave pubblica

Su Rocky Linux potete consentire a root l'accesso SSH con chiave pubblica usando una regola Match User root e AuthenticationMethods publickey. Per l'amministrazione ordinaria è preferibile un account personale con sudo: se serve l'accesso diretto di root, verificate la configurazione effettiva e provate nuove sessioni prima di chiudere quella già aperta.

Preparare prima un amministratore ordinario

SSH (Secure Shell) consente di accedere al server attraverso una connessione cifrata. Root ha privilegi completi: un account personale con sudo permette invece di distinguere gli accessi e autorizzare le operazioni necessarie. Se adminuser non esiste e questo è il nome scelto:

sudo useradd adminuser
sudo usermod -aG wheel adminuser

Sostituite adminuser con l'account reale; se esiste già, controllatelo senza ripetere useradd. Verificate directory home, chiave pubblica autorizzata, proprietario e permessi. L'appartenenza a wheel deve essere accompagnata dalla corrispondente policy sudo effettivamente attiva.

Una chiave SSH non imposta la password dell'account. Se sudo richiede la password dell'utente, preparatela secondo la policy con sudo passwd adminuser. Da una nuova sessione dell'amministratore provate sudo -v; non risolvete il problema concedendo indiscriminatamente NOPASSWD.

Tenete aperta la sessione attuale e predisponete una console della macchina virtuale, seriale o del provider indipendente da SSH. Prima delle modifiche conservate una copia protetta di /etc/ssh/sshd_config, dei file inclusi e dell'eventuale authorized_keys che modificherete, con proprietario e permessi.

Leggere la configurazione SSH effettiva

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '
sudo grep -RinE '^[[:space:]]*(PermitRootLogin|PasswordAuthentication|PubkeyAuthentication)' \
  /etc/ssh/sshd_config /etc/ssh/sshd_config.d

sshd -T legge configurazione e valori predefiniti; la ricerca nei file aiuta a individuare dove sono definite le opzioni. L'elenco non si limita necessariamente ai percorsi mostrati: seguite anche eventuali Include che puntano altrove. Se il servizio usa un file alternativo con -f o opzioni di avvio, i test devono usare gli stessi parametri.

Le regole Match dipendono dalle condizioni della connessione. Per controllare root usate sshd -T -C con utente e indirizzo reali, come nell'esempio successivo. Verificate anche AuthorizedKeysFile, eventuali comandi o autorità di certificazione per le chiavi, AllowUsers, DenyUsers, gruppi e condizioni dell'account: consentire root in una direttiva non annulla gli altri controlli.

Preparare la chiave pubblica di root

Registrare la chiave e verificarne i permessi

L'esempio presume che root abbia home /root e che il file autorizzato effettivo sia /root/.ssh/authorized_keys. Controllate questi valori prima di procedere. Sostituite l'intera riga fittizia ssh-ed25519 public_key_string administrator_identifier con la chiave pubblica reale su una sola riga:

sudo install -d -m 700 -o root -g root /root/.ssh
echo 'ssh-ed25519 public_key_string administrator_identifier' | sudo tee -a /root/.ssh/authorized_keys
sudo chown root:root /root/.ssh/authorized_keys
sudo chmod 600 /root/.ssh/authorized_keys
sudo restorecon -Rv /root/.ssh

Le modalità previste sono 700 per la directory e 600 per il file, entrambi di root; controllate anche i permessi delle directory superiori. restorecon ripristina il contesto SELinux previsto. Se la policy usa un percorso diverso, adattate percorso e contesto invece di disattivare SELinux.

Non copiate la chiave privata sul server. Verificate impronta e provenienza della chiave pubblica con il titolare, conservate le chiavi già autorizzate e non aggiungete duplicati o righe spezzate. L'algoritmo deve essere ammesso dalla policy crittografica locale: l'esempio Ed25519 non va usato indiscriminatamente in ambienti con requisiti FIPS (Federal Information Processing Standards); impiegate una chiave conforme alla policy senza indebolirla.

Limitare le funzioni della singola chiave

Per una chiave di automazione, opzioni di authorized_keys come from=, command= e restrict possono limitare sorgente e funzionalità. Una restrizione al comando non equivale da sola a disabilitare ogni inoltro: scegliete esplicitamente le limitazioni necessarie e provatele con una chiave separata. Il manuale ufficiale di sshd e del formato authorized_keys descrive queste opzioni.

Richiedere la chiave pubblica nella regola di root

Esaminate la struttura di Include e Match prima di modificare il file. OpenSSH usa normalmente il primo valore letto per ciascuna opzione; gli include con caratteri jolly sono letti in ordine lessicografico. Un file con prefisso 90 non prevale automaticamente su valori letti prima.

Le opzioni di un blocco Match applicabile possono sostituire quelle globali; se più blocchi corrispondono, per la stessa opzione conta la prima occorrenza pertinente. Se esiste già una regola efficace per root, modificate quella. Altrimenti questo è un esempio da collocare in fondo a /etc/ssh/sshd_config, dopo averne controllato la struttura:

Match User root
    PermitRootLogin prohibit-password
    PubkeyAuthentication yes
    AuthenticationMethods publickey

Il blocco riguarda root e prosegue fino a un altro Match o alla fine del file. Non inseritelo casualmente in un file incluso prima di direttive che devono restare globali. Conservate la policy degli altri utenti e le eventuali richieste di autenticazione a più fattori dell'organizzazione.

PermitRootLogin prohibit-password vieta per root password e autenticazione interattiva da tastiera; non significa da solo che ogni altro metodo sia escluso. Qui AuthenticationMethods publickey richiede esplicitamente il metodo a chiave pubblica. Le chiavi ammesse possono provenire anche da file o autorità già configurati: controllate le sorgenti autorizzate effettive.

sudo sshd -t
sudo sshd -T -C user=root,host=client.example.test,addr=192.0.2.10 | grep -E "^(permitrootlogin|pubkeyauthentication|passwordauthentication|authenticationmethods) "

Sostituite client.example.test con il nome del client pertinente e 192.0.2.10 con l'indirizzo sorgente visto dal server, considerando VPN o NAT. Sono esempi di documentazione. Se esistono condizioni sull'indirizzo o sulla porta locale, aggiungete i relativi parametri laddr e lport al test.

Per questa policy root deve risultare con permitrootlogin prohibit-password, pubkeyauthentication yes e authenticationmethods publickey. Un eventuale passwordauthentication yes nel riepilogo non annulla il divieto specifico di root. Ripetete la verifica con user=adminuser e le condizioni reali per controllare che l'amministratore ordinario conservi la policy prevista.

Verificare la sintassi e provare nuove connessioni

1. Tenete aperta la sessione amministrativa attuale e verificate la console di recupero.
2. Eseguite sshd -t: deve terminare con codice zero e senza errori. In caso contrario correggete il file indicato e ripetete il controllo.
3. Confrontate i valori di sshd -T -C per root e per l'amministratore ordinario, poi ricaricate il servizio.
4. Da un terminale separato del client provate una connessione realmente nuova con la chiave autorizzata.
5. Provate separatamente il rifiuto dell'autenticazione tramite password e il login dell'amministratore con sudo -v.

Dopo aver verificato i valori effettivi, la sequenza seguente ricarica il servizio solo se la sintassi è valida e riesegue il controllo root solo se il reload riesce. Sostituite prima le condizioni di esempio:

sudo sshd -t &&
sudo systemctl reload sshd &&
sudo sshd -T -C user=root,host=client.example.test,addr=192.0.2.10 | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication|authenticationmethods) '

Il test dei file non prova che una connessione autenticherà davvero il client. Per evitare di riutilizzare una connessione multiplexata, sul client potete provare ssh -o ControlMaster=no -o ControlPath=none -o IdentitiesOnly=yes -o PreferredAuthentications=publickey -i /percorso/chiave root@server. Sostituite chiave e server, aggiungete la porta se diversa da quella prevista e verificate l'impronta del server tramite un canale affidabile; non disabilitate il controllo della chiave host.

Per una prova separata del metodo password usate, dalla stessa sorgente autorizzata, ssh -o ControlMaster=no -o ControlPath=none -o PubkeyAuthentication=no -o KbdInteractiveAuthentication=no -o PreferredAuthentications=password root@server. Con la policy a chiave deve essere negato l'accesso; un timeout di rete non dimostra che la password sia stata correttamente rifiutata. Esaminate l'esito e i log del server, evitando tentativi ripetuti che attivino blocchi dell'account.

Se il reload fallisce, leggete journalctl -u sshd e lo stato del servizio. Non chiudete la sessione corrente. Per recuperare, ripristinate tramite sessione ancora aperta o console i file interessati dal backup, ripetete sshd -t e i controlli contestuali, quindi ricaricate e provate un nuovo accesso. Non fate affidamento sul solo fatto che una vecchia connessione continui a funzionare.

Ridurre ulteriormente l'ambito di accesso

Limitare la rete di gestione nel firewall

Preferite una VPN o una rete amministrativa. Controllate la zona associata al traffico e le regole già presenti. Questa è un'autorizzazione aggiuntiva IPv4 di esempio, non una regola che vieta automaticamente tutte le altre sorgenti:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --add-rich-rule='rule family="ipv4" source address="192.0.2.0/24" service name="ssh" accept'

Sostituite public e 192.0.2.0/24 con zona e rete reali. Verificate anche cosa include il servizio firewalld ssh: se sshd usa una porta diversa, la definizione o la regola devono corrispondere. Una regola IPv4 non limita il traffico IPv6, che richiede una verifica separata.

La rich rule viene aggiunta alla configurazione runtime. Una precedente apertura generale del servizio o della porta può continuare ad autorizzare l'accesso da altre reti. Prima provate una nuova connessione dal percorso amministrativo previsto e assicuratevi della console; soltanto dopo valutate la rimozione mirata dell'apertura troppo ampia, senza toccare regole estranee.

Dopo la prova aggiungete la stessa regola con --permanent e controllate sia runtime sia configurazione permanente. Non usate una conversione globale runtime-to-permanent per questo singolo cambiamento. Per annullare una regola aggiunta da voi, rimuovete la stessa stringa con --remove-rich-rule negli ambiti in cui l'avete creata, preservando le regole preesistenti. La documentazione delle rich rule di firewalld e la guida a firewalld su Rocky Linux chiariscono questi elementi.

Separare utenti e chiavi

• Assegnate chiavi diverse alle persone, così da revocare quelle di un titolare senza sostituirle tutte.
• Tenete distinte chiavi di automazione e chiavi per l'amministrazione interattiva.
• Proteggete le chiavi private con passphrase e usate l'inoltro dell'agente soltanto quando necessario.
• Raccogliete e controllate log SSH e tentativi anomali, correlando utente, sorgente e impronta della chiave quando disponibili.

Valutare un'eccezione temporanea per la password di root

Abilitare root con password espone direttamente privilegi completi a errori e furti di credenziali. Se un requisito eccezionale lo impone, limitate l'accesso a una rete gestita, il tempo di applicazione e le persone autorizzate, con credenziali temporanee e monitoraggio. Questo esempio modifica i valori nello stesso blocco root già individuato, non propone di abilitarli globalmente:

PermitRootLogin yes
PasswordAuthentication yes
AuthenticationMethods any

Se AuthenticationMethods publickey resta efficace, aggiungere soltanto yes non abilita una sessione con la sola password. any permette un singolo metodo tra quelli abilitati: controllate quindi anche gli altri metodi, le regole degli account e PAM, il sistema di autenticazione della distribuzione. Non cambiate alla cieca i blocchi dell'account o la policy per superare un rifiuto.

Prima di applicare l'eccezione ripetete test di sintassi, valori contestuali e prove da una nuova sessione. Alla fine ripristinate la policy originaria, verificate nuovamente accessi ammessi e negati e sostituite o ritirate la credenziale temporanea secondo le regole dell'organizzazione.

Vietare di nuovo l'accesso diretto di root

Prima provate una nuova connessione dell'amministratore ordinario e sudo -v. Nel blocco root effettivamente modificato impostate:

PermitRootLogin no

Non aggiungete un valore concorrente in un altro file sperando che prevalga. Verificate con sshd -t e sshd -T -C per le condizioni di root, applicate la configurazione solo dopo controlli riusciti e tenete aperta la sessione esistente finché una nuova connessione root viene negata e l'amministratore ordinario continua a entrare. La modifica riguarda nuovi accessi, non chiude automaticamente una sessione root già autenticata.

Individuare la causa di un problema

Riferimenti della configurazione OpenSSH

Il manuale ufficiale di sshd_config definisce PermitRootLogin, Match, Include e i metodi di autenticazione; il manuale delle opzioni del client SSH descrive chiavi e riuso delle connessioni. Confrontate sempre le opzioni con la versione OpenSSH installata su Rocky e con la policy applicata alla macchina.