It's not that different from having the same user/password accessible via ssh. It's best to not have direct access to important machines anyway, and go for a bastion or similar service.

But... you can switch to Kerberos SSO, or setup smart cards login instead.

You can also use it kind of like a jump host and do ssh keys I to secondary server.

I find it cool to give nice way to access in environments where ssh is not allowed by default, but https is. It's sometimes easier to setup proxies/reverse proxies in corporate forest instead of opting for direct ash access.

You don't have to run the web interface on the server.

You can use Cockpit Client (from flathub) to connect with SSH.

It depends on how you run your services.

We tested it before, however it is not quite good in our case.

Most of our services are running in a K8S cluster. The servers are just something we run the K8S node.

If we need to patch the system, we just “drain” the node, update and add it back.

So, if you do not need to directly operate the server, it will not be necessary.

You could also make Cocpit accesible only through VPN. Tailscale (and others) make it pretty easy.

Cockpit leverages the PAM stack, so you can have any authentication methodology you like.

Not production servers, but I use it on my home server running RHEL (and RockyLinux in the future).

I'm okay with using it instead of the shell because I know how to do stuff via the shell but I just got lazy.

It's not risky. For anything serious that can be an attractive target, it's a matter of time before getting doomed.