Cockpit or Webmin: Which One Better for Ubuntu VPS?

Cockpit vs Webmin: di short answer

Cockpit and Webmin na both web panels wey you fit use manage Linux server from browser, but dem dey answer different questions. Cockpit dey come inside your distribution own repository, and e dey read the machine through systemd, journald, polkit and udisks. So e dey show you server wey you still dey manage through SSH. Webmin old pass and e cover more things: e dey write configuration files for Apache, BIND, Postfix, MariaDB and plenty other services wey Cockpit no dey touch. E dey also run im own web server as root to do that work.

Install Cockpit when you want live view of one box, log reader, and emergency terminal. Install Webmin when you need form-based editor for service wey you no want configure by hand. No put any of dem for public port with password login. If you already dey run more than two or three servers, the honest answer often na neither. SSH plus Ansible path dey scale better than any panel.

Wetin each panel fit really change

Cockpit base install small, and most areas dey come as separate packages wey you fit leave out:

• systemd services and timers: start, stop, enable, and read the unit file
• the journal, filtered by unit and priority, wey be journalctl with date picker
• local accounts, group membership, and authorized SSH keys
• storage with cockpit-storaged: partitions, LVM volume groups, filesystems and mount points
• containers with cockpit-podman, wey dey manage Podman only
• package updates with cockpit-packagekit
• graphs of CPU, memory, disk and network with cockpit-pcp
• root terminal inside browser tab

Two areas fit look like dem don break for Ubuntu VPS, but dem no break. Cockpit Networking page na front end for NetworkManager, while Ubuntu server images dey use netplan with systemd-networkd, so the page fit no show or e fit empty. No install NetworkManager for remote box just to bring am back, because e go take over the interface, and one mistake fit make you lose the SSH session too. Cockpit firewall controls na front end for firewalld, while Ubuntu dey use ufw, so you no go get any firewall controls at all. You go still run sudo ufw status for terminal.

Webmin cover much more area, because e be collection of per-service modules instead of one program:

• Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL and Samba configuration through forms
• users, groups and disk quotas
• cron jobs and system clock
• package updates, plus file manager wey support upload and download
• firewall front ends, including one for iptables and one for firewalld
• configuration file backups, and cluster modules wey push one change go other Webmin servers

Webmin dey edit the real files under /etc. No hidden database dey behind the forms, so if /etc dey inside version control, sudo git -C /etc diff after you save form go show exactly wetin the module write. Na the fastest way to learn wetin any Webmin page really dey do. Webmin install and first login walkthrough dey explain the module tree in detail. Virtualmin and Usermin na separate products wey dem build on the same engine, for shared hosting and end users, and dem inherit everything wey we talk here about exposure.

How each one dey authenticate

Cockpit no get user database. Its login page dey run PAM (pluggable authentication modules) stack for /etc/pam.d/cockpit, so the accounts na your Unix accounts and the passwords na your Unix passwords. By default, e no dey allow root because /etc/cockpit/disallowed-users list am. Privileged actions dey pass through polkit, and the interface dey ask for your password again before e change anything. Na why the page header fit show "Limited access" until you escalate.

This design get one result wey people dey see for hardened box. If you follow key-only SSH login with password authentication disabled, the account fit no get any usable password, so Cockpit login go reject am while ssh still dey work. Check am for the server:

sudo passwd -S deploy

Output wey start with deploy L mean say the password dey locked, so PAM no get anything to accept and no password wey you type fit work. P mean say usable password dey set. Cockpit own login page no dey accept SSH keys. E only use keys when Cockpit connect from the machine wey you log into go another host.

Webmin dey keep its own users for /etc/webmin/miniserv.users, separate from /etc/passwd, and you fit also configure am to authenticate against Unix accounts. Webmin user wey get all modules na root for that machine, no matter wetin their login shell talk. Webmin release its own TOTP (time-based one-time password) support and its own host blocking after repeated failed logins. You switch both on inside Webmin Configuration. Cockpit go get second factor only if you add one to PAM, for example with libpam-google-authenticator.

How dem dey update

Your distribution package Cockpit. For Ubuntu 24.04, e dey come from the archive, and the upstream project recommend the backports pocket if you want newer build:

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

apt policy go print the version wey you install and the repository wey e come from. If backports no carry newer build, apt go fall back to the archive version, and that one dey okay. cockpit.socket suppose read active (listening). Security fixes go then arrive through the same unattended-upgrades run wey your kernel dey use, from publisher wey you already trust.

Webmin no dey for Ubuntu's archive. The official install first add Webmin own repository and signing key:

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

Read that script before you run am, because e dey run as root. From that point, every apt upgrade for the server go also pull packages from Webmin's repository. So you don add another publisher wey get root-level trust for the machine. Na this be the real cost of Webmin, and e deserve plain example: CVE-2019-15107 na backdoor for several 1.9x packages wey allow unauthenticated command execution. E reach users because the project's build host get breached, no be the source repository. Distribution packaging no make this impossible. But e add build and review step wey you no dey maintain by yourself.

Kno Why Any of Dem Suppose Dey for Public Port

Cockpit dey listen for TCP 9090 and Webmin dey listen for TCP 10000, both dey use TLS (transport layer security) with self-signed certificate. Na why browser warning go show first. How to create and trust self-signed certificate explain wetin that warning tell you and wetin e no tell you. People dey scan both ports steady, and both panels fit give root access. So if person guess or reuse password, e don fully breach the server.

The safe way na to bind the panel to localhost, then reach am through SSH tunnel. For Cockpit, override the socket unit:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

The empty ListenStream= wey dey on im own line dey required. systemd dey append to list settings. So if you no put am, the unit go keep the original 0.0.0.0:9090 and add the new address. Your panel go still dey public. Apply the override and check wetin dey listen:

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

The output suppose show 127.0.0.1:9090. If address na *:9090 or 0.0.0.0:9090, the override no take effect. Now open the tunnel from your own machine and browse go https://localhost:9090:

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

Make the local port equal the remote port. Cockpit dey compare browser Origin header with the address wey e believe say e dey serve. So tunnel from local port 9999 fit load login page, then fail for login, and journalctl -u cockpit go record the rejected origin. If you need different local port, put the name for /etc/cockpit/cockpit.conf:

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

Restart with sudo systemctl restart cockpit.socket make e pick am up. For Webmin, the equivalent setting dey for /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 still dey check Referer header for form posts and dey reject request wey look like say e come from another host. Na this one dey break first attempt to use reverse proxy. The referers= line for the same file na where you allow the proxy hostname, and webprefix= na where you tell Webmin say e dey live under a path.

Another option na authenticated reverse proxy: nginx dey front, while Authentik single sign-on layer dey handle the login. E dey work, but na second-best option. The panel still dey run as root behind the proxy, and now you dey maintain two front doors instead of one. Tunnel no add any listening service to internet at all, and e reuse the SSH key wey you already dey protect.

Which panel you fit use for box wey already dey run production services

Cockpit, because of two reasons wey matter when other people dey depend on the machine. E dey use socket activation, so cockpit-ws dey run only while session dey open, and no permanent root daemon dey wait for port. E no own anything: if you remove the package, every service go continue to run exactly as before, because Cockpit no store any configuration of its own. Webmin's miniserv.pl dey remain resident whether anybody log in or not. Check wetin your own dey cost with systemctl status webmin; e go print resident memory of the running process.

If you need Webmin's DNS or mail modules, give dem server of their own. Webmin box wey dey do one job and bind to 127.0.0.1 na contained risk. Webmin wey share host with application wey your customers dey use no be. Do the basic setup before you install either panel: the first ten minutes for new VPS cover the non-root user and firewall wey both panels assume say e dey already there.

When neither one fit answer

A panel na per-server and manual, and e no keep record of wetin change or why. For one box, e dey okay. For five boxes, you dey repeat the same work, and for twenty, you dey guess which server miss the change. Cockpit fit add other hosts to one session through SSH, but recent versions disable this by default and want AllowMultiHost=yes for /etc/cockpit/cockpit.conf, and you still dey click the same change five times.

The alternative na plain SSH with your configuration inside a git repository. Manage several Linux servers from one place explain the structure of this setup, and a first Ansible playbook apply the same firewall rule to every host from one file wey you fit review as a diff. Container work dey follow the same method: docker compose up -d through SSH from a file for git, as e dey show for the Docker Compose basics guide, better pass clicking through any panel, and Cockpit no manage Docker at all.

Use a panel for work wey terminal no too good at, like reading a metrics graph or finding which one among forty units fail. Use code for anything wey you go do more than twice.

Failure modes and strings wey you go see

Cockpit dey reject password wey SSH accept. The account na key-only. sudo passwd -S alice dey print L for the second field, so PAM no get password to check. Set one with sudo passwd alice, or keep that account for SSH and log in to Cockpit as another user.

Cockpit dey refuse root even when password correct. /etc/cockpit/disallowed-users dey list root. Log in as normal user wey get sudo rights. Na the intended path be this, because polkit go record which human escalate privilege.

Cockpit no show Networking or Firewall page. Those pages need NetworkManager and firewalld. Ubuntu VPS dey run netplan with systemd-networkd and ufw, so the pages no go appear. Nothing spoil, and the fix na to continue using ufw over SSH.

Cockpit login page loads through the tunnel, but login fails. Your local port different from the remote port, so the Origin check dey fail and journalctl -u cockpit dey show am. Make the ports match, or set Origins inside /etc/cockpit/cockpit.conf.

Webmin form posts dey fail after you put am behind proxy. The Referer check dey reject dem. Add the proxy hostname to referers= inside /etc/webmin/miniserv.conf, and set webprefix= when the panel dey serve under a path.

You no sure whether panel dey exposed. sudo ss -lntp | grep -E '9090|10000' go answer that from the server itself, and Webmin dey write every login attempt to /var/webmin/miniserv.log. E good make you read am once after any change to how e dey listen.

FAQ

Cockpit or Webmin better for one Ubuntu VPS?

For most people, Cockpit better, because e dey come from Ubuntu own repository, system patches dey update am together with the rest of the system, and e dey run only when browser session open. Choose Webmin when you need form-based editor for service wey Cockpit no dey support, like BIND or Postfix. But accept say Webmin web server go run as root all the time, and Webmin own repository go provide the updates.

I fit run Cockpit and Webmin for the same server?

Yes. Dem dey use different ports, 9090 and 10000, and dem no conflict because each one dey edit the system directly instead of owning am. E still no be good trade-off. Each panel na separate root-capable login for the same machine, so you double the exposure just to save few clicks. If you install both, bind both to 127.0.0.1 and reach dem through SSH tunnel.

E safe to open port 9090 or 10000 to internet?

Password login no make am safe. Both panels lead to root, and routine scanning fit find both ports within hours after you open dem. Bind the panel to 127.0.0.1, then run ssh -N -L 9090:127.0.0.1:9090 user@host and browse go https://localhost:9090. Confirm with sudo ss -lntp | grep 9090. E must show 127.0.0.1:9090 instead of 0.0.0.0:9090. Authenticated reverse proxy na acceptable second option.

Why my Cockpit login dey fail when SSH with key dey work?

Cockpit dey authenticate through PAM with Unix password, and e login page no accept SSH keys. For hardened server, the account often no get usable password. Run sudo passwd -S youruser. An L for the second field mean say the password lock, so PAM get nothing to accept and every attempt dey reject. Set password with sudo passwd youruser, or use different account for the panel.

Cockpit dey manage Docker containers?

No. Cockpit container page dey come from cockpit-podman and e dey manage Podman. Dem drop the old Docker module years ago, and dem no dey bring am back. If your services dey run under Docker, manage dem with compose file for version control through SSH. Make Cockpit handle the system around dem, like the journal and disks.