Cockpit o Webmin: quale scegliere per il server

Cockpit vs Webmin: la risposta breve

Cockpit e Webmin sono entrambi pannelli web per gestire un server Linux tramite browser, ma rispondono a esigenze diverse. Cockpit è disponibile nel repository della distribuzione e interagisce con la macchina tramite systemd, journald, polkit e udisks. Mostra quindi un server che continui a gestire tramite SSH. Webmin è più datato e offre funzionalità molto più ampie: scrive i file di configurazione di Apache, BIND, Postfix, MariaDB e decine di altri servizi che Cockpit non modifica mai. Per farlo esegue un proprio web server con l'account root.

Installa Cockpit quando vuoi una vista in tempo reale di un singolo server, un lettore dei log e un terminale di emergenza. Installa Webmin quando ti serve un editor basato su moduli per un servizio che non vuoi configurare manualmente. Non esporre nessuno dei due su una porta pubblica con accesso tramite password. Se gestisci già più di due o tre server, spesso la risposta corretta è nessuno dei due: la combinazione di SSH e Ansible è più scalabile di qualsiasi pannello.

Che cosa può modificare realmente ogni pannello

L'installazione di base di Cockpit è ridotta e la maggior parte delle funzionalità è distribuita in pacchetti separati che si possono non installare:

• servizi e timer di systemd: avvio, arresto, abilitazione e lettura del file dell'unità
• il journal, filtrato per unità e priorità, che è journalctl con un selettore della data
• account locali, appartenenza ai gruppi e chiavi SSH autorizzate
• storage con cockpit-storaged: partizioni, gruppi di volumi LVM, filesystem e punti di mount
• container con cockpit-podman, che gestisce soltanto Podman
• aggiornamenti dei pacchetti con cockpit-packagekit
• grafici di CPU, memoria, disco e rete con cockpit-pcp
• un terminale root nella scheda del browser

Due aree sembrano non funzionare su un VPS Ubuntu, ma non è così. La pagina Networking di Cockpit è un front end per NetworkManager, mentre le immagini server di Ubuntu usano netplan con systemd-networkd; per questo la pagina è assente o vuota. Non installare NetworkManager su un sistema remoto per ripristinarla, perché prende il controllo dell'interfaccia e un errore in questa configurazione può interrompere anche la sessione SSH. I controlli del firewall di Cockpit sono un front end per firewalld, mentre Ubuntu usa ufw; di conseguenza non sono disponibili controlli del firewall. Continui a eseguire sudo ufw status in un terminale.

Webmin copre un numero molto maggiore di funzionalità, perché è una raccolta di moduli specifici per servizio e non un singolo programma:

• configurazione di Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL e Samba tramite moduli
• utenti, gruppi e quote disco
• job cron e orologio di sistema
• aggiornamenti dei pacchetti, oltre a un file manager con funzioni di upload e download
• front end per firewall, tra cui uno per iptables e uno per firewalld
• backup dei file di configurazione e moduli per cluster che distribuiscono una modifica ad altri server Webmin

Webmin modifica i file reali presenti in /etc. Non esiste un database nascosto dietro i moduli; quindi, se /etc è sotto controllo versione, sudo git -C /etc diff dopo il salvataggio di un modulo mostra esattamente ciò che il modulo ha scritto. È il modo più rapido per capire che cosa esegue realmente qualsiasi pagina di Webmin. La procedura di installazione di Webmin e il primo accesso descrive in dettaglio l'albero dei moduli. Virtualmin e Usermin sono prodotti distinti basati sullo stesso motore, destinati rispettivamente all'hosting condiviso e agli utenti finali, e sono soggetti a tutto ciò che viene detto qui sull'esposizione.

Come autentica ciascuna soluzione

Cockpit non dispone di un database utenti. La pagina di accesso esegue lo stack PAM (pluggable authentication modules) in /etc/pam.d/cockpit, quindi gli account sono gli account Unix e le password sono le password Unix. Per impostazione predefinita root viene rifiutato perché /etc/cockpit/disallowed-users lo elenca. Le operazioni privilegiate passano da polkit e l'interfaccia richiede nuovamente la password prima di modificare qualsiasi elemento. Per questo l'intestazione della pagina può mostrare "Accesso limitato" finché non si esegue l'elevazione dei privilegi.

Questo design ha una conseguenza che si verifica sui sistemi con configurazioni di sicurezza più restrittive. Se hai seguito l'accesso SSH solo con chiavi e hai disabilitato l'autenticazione tramite password, l'account può non avere alcuna password utilizzabile. Di conseguenza, l'accesso a Cockpit viene rifiutato, mentre ssh continua a funzionare. Verificalo sul server:

sudo passwd -S deploy

Un output che inizia con deploy L indica che la password è bloccata. PAM non ha quindi alcuna password da accettare e nessuna password immessa può funzionare. P indica che è impostata una password utilizzabile. La pagina di accesso di Cockpit non accetta le chiavi SSH. Le chiavi vengono usate soltanto quando Cockpit si connette a un altro host dal computer in cui hai effettuato l'accesso.

Webmin mantiene i propri utenti in /etc/webmin/miniserv.users, separati da /etc/passwd, e può anche essere configurato per autenticare gli account Unix. A un utente Webmin a cui sono assegnati tutti i moduli corrisponde l'accesso root su quel computer, indipendentemente da quanto indicato dalla shell di login dell'utente. Webmin include il supporto TOTP (time-based one-time password) e il blocco degli host dopo ripetuti accessi non riusciti. Entrambe le funzioni vengono attivate in Webmin Configuration. Cockpit ottiene un secondo fattore solo se ne aggiungi uno a PAM, ad esempio con libpam-google-authenticator.

Come viene aggiornato ciascuno

Cockpit è incluso nei pacchetti della distribuzione. In Ubuntu 24.04 proviene dall'archivio e il progetto upstream consiglia il pocket backports per ottenere una build più recente:

. /etc/os-release
sudo apt update
sudo apt install -t ${VERSION_CODENAME}-backports cockpit
sudo systemctl status cockpit.socket
apt policy cockpit

apt policy stampa la versione installata e il repository da cui proviene. Se backports non contiene una build più recente, apt utilizza la versione dell'archivio, che va bene. cockpit.socket dovrebbe restituire active (listening). Le correzioni di sicurezza arrivano quindi tramite la stessa esecuzione di unattended-upgrades usata per il kernel, da un publisher di cui ci si fida già.

Webmin non è incluso nell'archivio di Ubuntu. L'installazione ufficiale aggiunge prima il repository e la chiave di firma propri di Webmin:

curl -o webmin-setup-repo.sh https://raw.githubusercontent.com/webmin/webmin/master/webmin-setup-repo.sh
sudo sh webmin-setup-repo.sh
sudo apt-get install webmin --install-recommends

Leggere lo script prima di eseguirlo, perché viene eseguito come root. Da quel momento, ogni apt upgrade sul server scarica i pacchetti anche dal repository di Webmin. In questo modo si aggiunge un secondo publisher considerato attendibile con privilegi root sul sistema. Questo è il costo effettivo di Webmin e merita un esempio concreto: CVE-2019-15107 era una backdoor presente in diversi pacchetti 1.9x che consentiva l'esecuzione di comandi senza autenticazione. Ha raggiunto gli utenti perché il build host del progetto era stato compromesso, non il suo repository sorgente. La pacchettizzazione della distribuzione non rende questo scenario impossibile. Aggiunge però una fase di build e revisione che non è necessario gestire autonomamente.

Perché nessuno dei due deve essere esposto su una porta pubblica

Cockpit è in ascolto sulla porta TCP 9090 e Webmin sulla porta TCP 10000, entrambi tramite TLS (Transport Layer Security) con un certificato autofirmato. Per questo, la prima cosa visualizzata è un avviso del browser. Creazione e attendibilità di un certificato autofirmato spiega che cosa indica e che cosa non indica questo avviso. Entrambe le porte vengono sottoposte continuamente a scansione. Entrambi i pannelli consentono di accedere a root. Una password indovinata o riutilizzata comporta quindi la compromissione completa del server.

Il metodo sicuro consiste nel vincolare il pannello a localhost e raggiungerlo tramite un tunnel SSH. Per Cockpit, crea un override dell'unità socket:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

La riga vuota ListenStream= deve essere presente da sola. systemd aggiunge i valori alle impostazioni di tipo elenco. Senza questa riga, l'unità conserva il valore originale 0.0.0.0:9090 e aggiunge il nuovo indirizzo. Il pannello rimane quindi esposto pubblicamente. Applica l'override e verifica che cosa è in ascolto:

sudo systemctl daemon-reload
sudo systemctl restart cockpit.socket
sudo ss -lntp | grep 9090

L'output deve mostrare 127.0.0.1:9090. Un indirizzo *:9090 o 0.0.0.0:9090 indica che l'override non è stato applicato. Ora apri il tunnel dal tuo computer e accedi a https://localhost:9090:

ssh -N -L 9090:127.0.0.1:9090 deploy@203.0.113.10

Mantieni la porta locale uguale alla porta remota. Cockpit confronta l'header Origin del browser con l'indirizzo sul quale ritiene di essere pubblicato. Di conseguenza, un tunnel dalla porta locale 9999 carica la pagina di accesso, ma l'autenticazione non va a buon fine. Inoltre, journalctl -u cockpit registra l'origine rifiutata. Se devi usare una porta locale diversa, indicala in /etc/cockpit/cockpit.conf:

[WebService]
Origins = https://localhost:9999 https://127.0.0.1:9999

Riavvia con sudo systemctl restart cockpit.socket per applicare questa impostazione. Per Webmin, l'impostazione equivalente si trova in /etc/webmin/miniserv.conf:

bind=127.0.0.1

sudo systemctl restart webmin
sudo ss -lntp | grep 10000
ssh -N -L 10000:127.0.0.1:10000 deploy@203.0.113.10

Webmin controlla inoltre l'header Referer durante l'invio dei moduli e rifiuta le richieste che sembrano provenire da un altro host. È questo il motivo per cui un primo tentativo di reverse proxy non funziona. La riga referers= nello stesso file consente di autorizzare il nome host del proxy. La riga webprefix= indica invece a Webmin che deve essere pubblicato sotto un percorso.

L'altra opzione è un reverse proxy autenticato: nginx davanti al pannello e un livello di single sign-on con Authentik per gestire l'accesso. Funziona, ma è la seconda scelta. Il pannello continua a essere eseguito come root dietro il proxy. Inoltre, devi gestire due punti di accesso invece di uno. Un tunnel non aggiunge alcun servizio in ascolto su Internet e riutilizza la chiave SSH che già proteggi.

Quale pannello scegliere su un server che esegue già servizi di produzione

Cockpit, per 2 motivi importanti quando altre persone dipendono dalla macchina. È attivato tramite socket, quindi cockpit-ws viene eseguito solo mentre una sessione è aperta e non esiste un demone root permanente in attesa su una porta. Inoltre non gestisce alcuna configurazione propria: rimuovendo il pacchetto, tutti i servizi continuano a funzionare esattamente come prima, perché Cockpit non archivia configurazioni proprie. Il processo miniserv.pl di Webmin resta residente indipendentemente dal fatto che qualcuno abbia effettuato l'accesso. Verifica il consumo del tuo sistema con systemctl status webmin, che visualizza la memoria residente del processo in esecuzione.

Se ti servono i moduli DNS o di posta di Webmin, assegna loro un server dedicato. Un server Webmin che svolge una sola funzione ed è associato a 127.0.0.1 rappresenta un rischio contenuto. Webmin che condivide un host con un'applicazione esposta ai clienti non lo è. Esegui le attività di base prima di installare uno dei due pannelli: i primi 10 minuti su un nuovo VPS illustrano la creazione dell'utente non-root e la configurazione del firewall, che entrambi i pannelli presuppongono siano già presenti.

Quando la risposta non è nessuna delle due

Un pannello è specifico per singolo server e richiede interventi manuali; inoltre non registra che cosa è cambiato né il motivo. Questo va bene per un solo host. Con cinque host si ripete la stessa procedura, mentre con venti si deve indovinare quale server non ha ricevuto la modifica. Cockpit può aggiungere altri host a una sessione tramite SSH, ma le versioni recenti disabilitano questa funzione per impostazione predefinita e richiedono AllowMultiHost=yes in /etc/cockpit/cockpit.conf. Inoltre, si continua a fare clic cinque volte per applicare la stessa modifica.

L'alternativa è usare SSH direttamente e conservare la configurazione in un repository git. Gestire diversi server Linux da un unico punto descrive la struttura di questa configurazione, mentre un primo playbook Ansible applica la stessa regola firewall a ogni host partendo da un unico file, che può essere verificato tramite diff. Lo stesso vale per i container: eseguire docker compose up -d tramite SSH, usando un file presente in git come descritto nella guida introduttiva a Docker Compose, è preferibile a usare qualsiasi pannello; inoltre, Cockpit non gestisce Docker.

Usate un pannello per le attività in cui il terminale è meno adatto, ad esempio leggere un grafico delle metriche o individuare quale unità, tra quaranta, non è riuscita ad avviarsi. Usate il codice per qualsiasi attività che eseguirete più di due volte.

Modalità di errore e stringhe visualizzate

Cockpit rifiuta una password accettata da SSH. L'account usa solo chiavi. sudo passwd -S alice stampa L nel secondo campo, quindi PAM non ha alcuna password da verificare. Impostarne una con sudo passwd alice oppure mantenere quell'account per SSH e accedere a Cockpit con un altro utente.

Cockpit rifiuta root anche con la password corretta. /etc/cockpit/disallowed-users elenca root. Accedere con un utente normale dotato di autorizzazioni sudo. Questo è il percorso previsto, perché polkit registra quale utente ha eseguito l'escalation dei privilegi.

Cockpit non mostra la pagina Networking o Firewall. Queste pagine richiedono NetworkManager e firewalld. Un VPS Ubuntu usa netplan con systemd-networkd e ufw, quindi le pagine non vengono visualizzate. Non c'è alcun problema: continuare a usare ufw tramite SSH.

La pagina di accesso di Cockpit viene caricata tramite il tunnel, ma l'accesso non riesce. La porta locale è diversa da quella remota, quindi il controllo Origin fallisce e journalctl -u cockpit lo mostra. Usare le stesse porte oppure impostare Origins in /etc/cockpit/cockpit.conf.

L'invio dei moduli Webmin fallisce dopo averlo configurato dietro un proxy. Il controllo Referer li rifiuta. Aggiungere il nome host del proxy a referers= in /etc/webmin/miniserv.conf e impostare webprefix= quando il pannello viene pubblicato sotto un percorso.

Non si è certi che un pannello sia esposto. sudo ss -lntp | grep -E '9090|10000' risponde a questa domanda direttamente dal server e Webmin registra ogni tentativo di accesso in /var/webmin/miniserv.log. È consigliabile leggerlo una volta dopo qualsiasi modifica alla modalità di ascolto.

FAQ

Cockpit o Webmin è migliore per un singolo VPS Ubuntu?

Per la maggior parte degli utenti, Cockpit, perché proviene dal repository ufficiale di Ubuntu, viene aggiornato insieme al resto del sistema e resta in esecuzione solo mentre è aperta una sessione del browser. Scegli Webmin quando ti serve un editor basato su moduli per un servizio che Cockpit non gestisce, ad esempio BIND o Postfix, accettando però che il suo web server venga eseguito continuamente come root e che gli aggiornamenti provengano dal repository di Webmin.

Posso eseguire Cockpit e Webmin sullo stesso server?

Sì. Usano porte diverse, 9090 e 10000, e non entrano in conflitto, perché ciascuno modifica direttamente il sistema senza prenderne il controllo esclusivo. È comunque un compromesso svantaggioso. Ogni pannello aggiunge un accesso separato con possibilità di operare come root sulla stessa macchina, quindi raddoppi la superficie di esposizione per risparmiare pochi clic. Se installi entrambi, associa entrambi a 127.0.0.1 e accedivi tramite un tunnel SSH.

È sicuro aprire la porta 9090 o 10000 a Internet?

Non con un accesso tramite password. Entrambi i pannelli consentono di arrivare a root ed entrambe le porte vengono individuate dalle scansioni di routine entro poche ore dall'apertura. Associa il pannello a 127.0.0.1, quindi esegui ssh -N -L 9090:127.0.0.1:9090 user@host e apri https://localhost:9090 nel browser. Verifica con sudo ss -lntp | grep 9090, che deve mostrare 127.0.0.1:9090 invece di 0.0.0.0:9090. Un reverse proxy autenticato è una seconda opzione accettabile.

Perché l'accesso a Cockpit non riesce quando SSH con una chiave funziona?

Cockpit esegue l'autenticazione tramite PAM usando una password Unix e la relativa pagina di accesso non accetta chiavi SSH. Su un server con configurazione di sicurezza rafforzata, spesso l'account non dispone di una password utilizzabile. Esegui sudo passwd -S youruser: un L nel secondo campo indica che la password è bloccata, quindi PAM non ha credenziali da accettare e ogni tentativo viene rifiutato. Imposta una password con sudo passwd youruser oppure usa un account diverso per il pannello.

Cockpit gestisce i container Docker?

No. La pagina dei container di Cockpit proviene da cockpit-podman e gestisce Podman. Il vecchio modulo Docker è stato rimosso anni fa e non verrà ripristinato. Se i tuoi servizi vengono eseguiti con Docker, gestiscili tramite un file compose mantenuto nel controllo versione e accessibile via SSH, lasciando a Cockpit la gestione del sistema circostante, ad esempio journal e dischi.