Come installare e abilitare OpenSSH Server su CentOS 8

Su CentOS 8 OpenSSH Server è il punto di accesso standard per l’amministrazione remota. La parte delicata non è tanto installarlo, quanto farlo in modo pulito: servizio attivo, avvio automatico, firewall coerente e accesso verificato senza lasciare margini inutili. Se ti limiti a installare il pacchetto e basta, rischi di trovarti con il demone in ascolto ma irraggiungibile, oppure esposto nel modo sbagliato.

Qui l’obiettivo è semplice: portare una macchina CentOS 8 a un assetto SSH funzionante e ragionevolmente sicuro, con controlli pratici per capire subito se il problema è nel pacchetto, nel servizio, nel firewall o nella rete. Non serve inventarsi procedure strane: basta seguire l’ordine giusto e verificare ogni passaggio.

1. Verificare se OpenSSH Server è già presente

Su molte installazioni CentOS 8 il client SSH è già disponibile, mentre il server potrebbe non esserlo. Prima di installare, controlla lo stato del pacchetto e del servizio. È il modo più veloce per evitare di toccare qualcosa che magari funziona già.

Per capire se il demone è installato e se il servizio è noto a systemd, usa questi comandi:

rpm -q openssh-server
systemctl status sshd

Se il pacchetto è presente, `rpm` restituisce la versione installata. Se il servizio esiste ma non è attivo, `systemctl status sshd` ti mostra lo stato e gli ultimi log utili. Se invece il pacchetto manca, il sistema risponde con un messaggio tipo “package openssh-server is not installed”.

Un dettaglio che conviene non ignorare: il nome del servizio è `sshd`, non `ssh`. È un errore banale, ma capita spesso quando si passa da una distribuzione all’altra o si lavora su più ambienti.

2. Installare il pacchetto OpenSSH Server

Se il server non c’è, installalo con il gestore pacchetti di sistema. Su CentOS 8 il comando corretto è questo:

sudo dnf install -y openssh-server

Il pacchetto installa il demone `sshd`, i file di configurazione e le unità systemd necessarie. In condizioni normali non richiede passaggi aggiuntivi per partire, ma va comunque verificato che la configurazione predefinita sia compatibile con il tuo ambiente.

Subito dopo l’installazione, controlla che i file principali siano presenti:

ls -l /etc/ssh/sshd_config
ls -l /usr/sbin/sshd

Il primo è il file di configurazione del server, il secondo è il binario del demone. Se uno dei due manca, il problema non è SSH in sé ma il pacchetto o l’installazione del sistema base.

3. Abilitare e avviare il servizio sshd

Dopo l’installazione, il servizio va avviato e abilitato all’avvio automatico. Sono due operazioni distinte: una riguarda lo stato corrente, l’altra la persistenza al reboot.

sudo systemctl enable --now sshd

Questo comando è pratico perché fa entrambe le cose in una volta sola. Se preferisci procedere in modo più esplicito, puoi separare i passaggi:

sudo systemctl start sshd
sudo systemctl enable sshd

Dopo l’avvio, verifica che il servizio sia realmente attivo e non solo “configured”:

systemctl is-active sshd
systemctl is-enabled sshd

Il primo comando deve restituire `active`; il secondo, `enabled`. Se ottieni `inactive` o `failed`, vai subito ai log. Il punto giusto da guardare è quasi sempre questo:

journalctl -u sshd -b --no-pager

Se il demone non parte, spesso il problema è nella configurazione, in una chiave host mancante o in una policy di sicurezza che blocca l’avvio. In questo caso non forzare tentativi casuali: leggi l’errore, correggi e rilancia il servizio.

4. Aprire la porta nel firewall di CentOS 8

Con `sshd` attivo, il secondo punto critico è il firewall. Su CentOS 8 il comportamento predefinito di `firewalld` può bloccare l’accesso remoto anche quando il servizio è perfettamente funzionante in locale.

Per abilitare SSH nel firewall, usa il servizio predefinito invece di aprire numeri di porta a mano. È più leggibile e riduce gli errori:

sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --reload

Verifica poi che la regola sia effettivamente presente:

sudo firewall-cmd --list-services

Se devi controllare la zona attiva, perché la macchina usa più interfacce o più profili, aggiungi:

sudo firewall-cmd --get-active-zones
sudo firewall-cmd --zone=public --list-all

Se SSH è stato spostato su una porta non standard, il servizio `ssh` nel firewall non basta. In quel caso devi aprire la porta specifica, per esempio 2222/tcp, e assicurarti che anche `sshd_config` sia allineato. Ma per una configurazione standard, il servizio `ssh` è la scelta giusta.

5. Controllare la configurazione di sshd prima di esporlo

Prima di considerare il lavoro chiuso, conviene verificare il file `sshd_config`. Non serve fare tuning aggressivo subito; basta controllare che non ci siano impostazioni incoerenti o refusi che impediscono al servizio di partire o che rendono l’accesso troppo permissivo.

sudo sshd -t

Questo è il controllo più utile: se la sintassi è corretta, il comando non produce output. Se c’è un errore, ti indica il file e la riga da correggere. È molto meglio di scoprire il problema dopo un riavvio o, peggio, dopo aver chiuso la sessione corrente.

Il file di riferimento è ` /etc/ssh/sshd_config `, che normalmente contiene i parametri principali del server. Alcune direttive che vale la pena rivedere con attenzione sono queste:

Port 22
PermitRootLogin no
PasswordAuthentication yes
PubkeyAuthentication yes

Non bisogna confondere installazione e hardening. Per far partire il servizio basta la configurazione standard. Per renderlo più robusto, invece, puoi decidere se disabilitare il login diretto di root, usare chiavi pubbliche e limitare l’autenticazione a password solo se davvero necessaria.

Se cambi qualcosa in `sshd_config`, non riavviare alla cieca. Prima valida la sintassi, poi ricarica il servizio in modo controllato:

sudo systemctl reload sshd

Se il reload non è supportato dalla modifica introdotta, usa un restart solo dopo aver mantenuto una sessione alternativa aperta o una console fuori banda disponibile. È una precauzione elementare, ma evita di tagliarti fuori dalla macchina.

6. Testare l’accesso da un client remoto

La verifica vera non è locale. Devi testare da un host esterno, meglio se nello stesso segmento di rete in cui opereranno gli amministratori o i sistemi di automazione. Il test base è questo:

ssh utente@IP_DEL_SERVER

Se usi una porta diversa dalla 22, specifica il parametro `-p`:

ssh -p 2222 utente@IP_DEL_SERVER

Se la connessione fallisce, non andare subito a modificare il server. Prima distingui tra problema di rete, firewall, autenticazione o DNS. Una verifica rapida lato client aiuta molto:

nc -vz IP_DEL_SERVER 22
ssh -vvv utente@IP_DEL_SERVER

Il primo comando ti dice se la porta risponde; il secondo mostra la negoziazione SSH in dettaglio. Se la porta non è raggiungibile, il problema è quasi certamente a livello di rete o firewall. Se la porta risponde ma l’autenticazione fallisce, il problema è su account, chiavi o policy del server.

7. Gestire il caso in cui il servizio sia attivo ma non ascolti all’esterno

Uno scenario molto comune è questo: `sshd` risulta attivo, ma il server non è raggiungibile dall’esterno. In quel caso controlla su quali indirizzi e porte il demone è in ascolto.

ss -tlnp | grep sshd

Ti aspetti di vedere una riga in ascolto su `0.0.0.0:22`, `:::22` o comunque sull’interfaccia corretta. Se compare solo su `127.0.0.1:22`, allora il server SSH è limitato al loopback e non accetta connessioni remote. In quel caso va rivista la direttiva `ListenAddress` in `sshd_config`.

Se invece l’ascolto è corretto ma il test remoto fallisce, il nodo successivo da verificare è il firewall esterno: security group, ACL di rete, firewall perimetrale o regole del cloud. In pratica, non fermarti al primo host che risponde in locale.

8. Abilitare l’accesso con chiavi pubbliche invece delle password

Una volta che SSH funziona, il passo sensato è passare a chiavi pubbliche per gli accessi amministrativi. È la scelta più pulita in quasi tutti gli ambienti server, soprattutto se ci sono automazioni, deployment o più operatori.

Dal client, generi una chiave se non ne hai già una:

ssh-keygen -t ed25519 -C "utente@host"

Poi copi la chiave pubblica sul server:

ssh-copy-id utente@IP_DEL_SERVER

Se `ssh-copy-id` non è disponibile, puoi aggiungere manualmente la chiave in `~/.ssh/authorized_keys` sul server, mantenendo permessi corretti. I permessi sono cruciali: directory `.ssh` troppo aperta o file `authorized_keys` con mode errato causano il rifiuto della chiave anche quando il contenuto è giusto.

Una volta verificato che la chiave funziona, puoi valutare di disabilitare l’autenticazione a password nel file di configurazione. Fallo solo dopo aver confermato di avere un accesso alternativo valido, perché un errore qui può complicarti la vita in fretta.

9. Permessi, SELinux e altri dettagli che rompono tutto senza sembrare colpevoli

Quando SSH non funziona nonostante tutto sembri corretto, i colpevoli tipici sono sempre gli stessi: permessi sbagliati, SELinux, firewall o configurazione incompleta. Su CentOS 8 SELinux è da considerare seriamente, non come dettaglio secondario.

Se hai modificato file o directory legati all’accesso SSH, controlla i contesti SELinux e i permessi dell’home directory dell’utente. Un controllo rapido dei log può dare subito il segnale giusto:

sudo ausearch -m avc -ts recent
sudo journalctl -u sshd -b --no-pager

Se vedi denial SELinux, non disabilitare la protezione a caso. Prima capisci quale oggetto viene negato e correggi il contesto o la policy. Molti problemi di accesso chiave derivano da directory home con permessi troppo aperti o da file `authorized_keys` non leggibili dal demone nel modo previsto.

10. Verifica finale operativa

A questo punto la sequenza corretta è: pacchetto presente, servizio attivo, avvio automatico abilitato, firewall aperto, accesso remoto riuscito. Se vuoi fare un controllo sintetico, usa questa mini-checklist:

1. rpm -q openssh-server restituisce un pacchetto installato.

2. systemctl is-active sshd restituisce active.

3. systemctl is-enabled sshd restituisce enabled.

4. firewall-cmd --list-services mostra ssh.

5. ssh utente@IP_DEL_SERVER completa il login dal client remoto.

Se uno dei punti fallisce, non correggere tutto insieme. Isola il layer: pacchetto, servizio, firewall, rete o autenticazione. È l’unico modo affidabile per non confondere un sintomo con la causa.

11. Nota pratica su manutenzione e rollback

Quando tocchi `sshd_config`, la regola operativa è semplice: conserva sempre una sessione aperta di emergenza o una console fuori banda prima di applicare modifiche che possono bloccare l’accesso. Il rollback minimo, se qualcosa va storto, è ripristinare il file originale e riavviare il servizio.

sudo cp -a /etc/ssh/sshd_config /etc/ssh/sshd_config.bak
sudo cp -a /etc/ssh/sshd_config.bak /etc/ssh/sshd_config
sudo systemctl restart sshd

Questa copia di sicurezza è banale ma efficace. Se usi gestione centralizzata della configurazione, meglio ancora: conserva lo snippet nel controllo versione e applica i cambiamenti in modo tracciabile. Su una macchina singola, invece, un backup locale prima del change è il minimo sindacale.

In sintesi: installare OpenSSH Server su CentOS 8 è semplice, ma va fatto con disciplina. Il servizio deve essere presente, attivo, abilitato e raggiungibile, e ogni modifica successiva va validata prima del riavvio. Se segui l’ordine giusto, l’accesso remoto diventa stabile e prevedibile, non un esercizio di fortuna.