Cockpit ou Webmin: qual usar no seu servidor?

Cockpit vs Webmin: a resposta curta

Cockpit e Webmin são painéis web para gerir um servidor Linux a partir de um navegador, mas respondem a necessidades diferentes. O Cockpit é disponibilizado no repositório da própria distribuição e consulta a máquina através de systemd, journald, polkit e udisks. Assim, mostra um servidor que continua a ser gerido por SSH. O Webmin é mais antigo e muito mais abrangente: escreve ficheiros de configuração para Apache, BIND, Postfix, MariaDB e dezenas de outros serviços que o Cockpit nunca altera. Para isso, executa o seu próprio servidor web como root.

Instale o Cockpit quando quiser uma vista em tempo real de um servidor, um leitor de logs e um terminal de emergência. Instale o Webmin quando precisar de um editor baseado em formulários para um serviço que não quer configurar manualmente. Não exponha nenhum dos dois numa porta pública com autenticação apenas por palavra-passe. Se já gere mais de dois ou três servidores, a resposta honesta muitas vezes é nenhum dos dois. A combinação de SSH e Ansible escala melhor do que qualquer painel.

O que cada painel pode realmente alterar

A instalação base do Cockpit é pequena, e a maioria das áreas corresponde a pacotes separados que pode deixar de instalar:

• serviços e temporizadores systemd: iniciar, parar, ativar e consultar o ficheiro da unidade
• o journal, filtrado por unidade e prioridade, que é journalctl com um seletor de data
• contas locais, associação a grupos e chaves SSH autorizadas
• armazenamento com cockpit-storaged: partições, grupos de volumes LVM, sistemas de ficheiros e pontos de montagem
• contentores com cockpit-podman, que gere apenas Podman
• atualizações de pacotes com cockpit-packagekit
• gráficos de CPU, memória, disco e rede com cockpit-pcp
• um terminal root no separador do navegador

Duas áreas parecem não funcionar numa VPS Ubuntu, mas não estão avariadas. A página Networking do Cockpit é uma interface para NetworkManager, e as imagens Ubuntu Server usam netplan com systemd-networkd, por isso a página não aparece ou fica vazia. Não instale NetworkManager num servidor remoto para recuperar essa página, porque ele assume o controlo da interface e um erro nessa configuração também lhe faz perder a sessão SSH. Os controlos de firewall do Cockpit são uma interface para firewalld, e o Ubuntu usa ufw, por isso não terá quaisquer controlos de firewall. Continue a executar sudo ufw status num terminal.

O Webmin cobre uma área muito mais ampla, porque é uma coleção de módulos por serviço e não um único programa:

• configuração de Apache, nginx, BIND, Postfix, Dovecot, MariaDB, PostgreSQL e Samba através de formulários
• utilizadores, grupos e quotas de disco
• tarefas cron e o relógio do sistema
• atualizações de pacotes, além de um gestor de ficheiros com carregamento e descarregamento
• interfaces para firewalls, incluindo uma para iptables e outra para firewalld
• cópias de segurança de ficheiros de configuração e módulos de cluster que enviam uma alteração para outros servidores Webmin

O Webmin edita os ficheiros reais em /etc. Não existe uma base de dados oculta por trás dos formulários; por isso, se /etc estiver sob controlo de versões, sudo git -C /etc diff depois de guardar um formulário mostra exatamente o que o módulo escreveu. Esta é a forma mais rápida de saber o que qualquer página do Webmin realmente faz. O guia de instalação e primeiro início de sessão do Webmin explica detalhadamente a árvore de módulos. Virtualmin e Usermin são produtos separados, construídos sobre o mesmo motor, para alojamento partilhado e para utilizadores finais, respetivamente, e herdam tudo o que é dito aqui sobre exposição.

Como cada um autentica

O Cockpit não tem uma base de dados de utilizadores. A página de início de sessão executa a pilha PAM (módulos de autenticação conectáveis) em /etc/pam.d/cockpit. Por isso, as contas são as suas contas Unix e as palavras-passe são as suas palavras-passe Unix. O root é recusado por predefinição porque /etc/cockpit/disallowed-users o lista. As ações privilegiadas passam pelo polkit. A interface pede novamente a sua palavra-passe antes de alterar qualquer coisa. Por isso, o cabeçalho da página pode apresentar "Acesso limitado" até o utilizador elevar os privilégios.

Este desenho tem uma consequência que ocorre em servidores com a segurança reforçada. Se seguiu início de sessão SSH apenas com chave e autenticação por palavra-passe desativada, a conta pode não ter nenhuma palavra-passe utilizável. Nesse caso, o início de sessão no Cockpit é recusado, enquanto ssh continua a funcionar. Verifique no servidor:

sudo passwd -S deploy

Uma saída que começa por deploy L significa que a palavra-passe está bloqueada. Nesse caso, o PAM não tem nada que possa aceitar e nenhuma palavra-passe introduzida funcionará. P significa que está definida uma palavra-passe utilizável. A própria página de início de sessão do Cockpit não aceita chaves SSH. As chaves só são usadas quando o Cockpit estabelece uma ligação a partir da máquina onde iniciou sessão para outro host.

O Webmin mantém os seus próprios utilizadores em /etc/webmin/miniserv.users, separados de /etc/passwd, e também pode ser configurado para autenticar contra contas Unix. Um utilizador do Webmin a quem tenham sido concedidos todos os módulos tem privilégios equivalentes aos do root nessa máquina, independentemente do shell de início de sessão definido para o utilizador. O Webmin inclui suporte próprio para TOTP (palavra-passe de uso único baseada no tempo) e bloqueia os hosts após várias tentativas de início de sessão falhadas. Ambas as funcionalidades são ativadas em Webmin Configuration. O Cockpit só obtém um segundo fator se adicionar um ao PAM, por exemplo com libpam-google-authenticator.

Como cada um é atualizado

O Cockpit é empacotado pela sua distribuição. No Ubuntu 24.04, ele vem do arquivo de pacotes, e o projeto upstream recomenda o pocket backports para obter uma compilação mais 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 mostra a versão instalada e o repositório de origem. Se o backports não tiver uma compilação mais recente, o apt usa a versão do arquivo de pacotes, o que é aceitável. cockpit.socket deve apresentar active (listening). As correções de segurança chegam depois pela mesma execução de unattended-upgrades que atualiza o kernel, a partir de um editor em que já confia.

O Webmin não está no arquivo de pacotes do Ubuntu. A instalação oficial adiciona primeiro o próprio repositório do Webmin e a respetiva chave de assinatura:

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

Leia esse script antes de o executar, porque ele é executado como root. A partir daí, cada apt upgrade no servidor também obtém pacotes do repositório do Webmin. Assim, adicionou um segundo editor com confiança ao nível de root no sistema. Esse é o custo real do Webmin, e merece um exemplo direto: a CVE-2019-15107 era uma backdoor presente em vários pacotes 1.9x que permitia a execução de comandos sem autenticação. Ela chegou aos utilizadores porque o host de compilação do projeto foi comprometido, e não o respetivo repositório de código-fonte. O empacotamento pela distribuição não torna isso impossível. Ele acrescenta uma etapa de compilação e revisão que não precisa de manter por conta própria.

Por que nenhum dos dois deve usar uma porta pública

O Cockpit escuta na porta TCP 9090 e o Webmin na porta TCP 10000, ambos com TLS (segurança da camada de transporte) e um certificado autoassinado. Por isso, a primeira coisa que aparece é um aviso do navegador. Criar e confiar num certificado autoassinado explica o que esse aviso informa e o que não informa. Ambas as portas são verificadas continuamente, e ambos os painéis dão acesso a root. Portanto, uma palavra-passe adivinhada ou reutilizada compromete completamente o servidor.

O padrão seguro é vincular o painel a localhost e aceder a ele através de um túnel SSH. Para o Cockpit, substitua a unidade socket:

sudo systemctl edit cockpit.socket

[Socket]
ListenStream=
ListenStream=127.0.0.1:9090

A linha ListenStream= vazia, sozinha, é obrigatória. O systemd acrescenta valores às definições de lista. Sem essa linha, a unidade mantém o 0.0.0.0:9090 original e adiciona o novo endereço, deixando o painel público. Aplique a substituição e verifique o que está a escutar:

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

O resultado deve mostrar 127.0.0.1:9090. Um endereço *:9090 ou 0.0.0.0:9090 indica que a substituição não foi aplicada. Agora abra o túnel a partir da sua própria máquina e aceda a https://localhost:9090 no navegador:

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

Mantenha a porta local igual à porta remota. O Cockpit compara o cabeçalho Origin do navegador com o endereço que acredita estar a servir. Por isso, um túnel da porta local 9999 carrega a página de início de sessão, mas falha durante o início de sessão, e journalctl -u cockpit regista a origem rejeitada. Se precisar de uma porta local diferente, indique-a em /etc/cockpit/cockpit.conf:

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

Reinicie com sudo systemctl restart cockpit.socket para aplicar essa alteração. No Webmin, a definição equivalente fica em /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

O Webmin também verifica o cabeçalho Referer nos envios de formulários e recusa pedidos que pareçam vir de outro anfitrião. É isso que interrompe a primeira tentativa de usar um reverse proxy. A linha referers= no mesmo ficheiro é onde permite o nome de anfitrião do proxy, e webprefix= é onde indica ao Webmin que ele está alojado sob um caminho.

A outra opção é um reverse proxy autenticado: nginx à frente, com uma camada de início de sessão único do Authentik a tratar do início de sessão. Funciona, mas é a segunda melhor opção. O painel continua a ser executado como root atrás do proxy, e passa a manter duas portas de entrada em vez de uma. Um túnel não adiciona qualquer serviço à escuta na Internet e reutiliza a chave SSH que já protege.

Qual painel usar num servidor que já executa serviços de produção

Cockpit, por dois motivos importantes quando outras pessoas dependem da máquina. Ele é ativado por socket, portanto cockpit-ws só é executado enquanto há uma sessão aberta e não existe um daemon root permanente à espera numa porta. Além disso, não controla nenhum serviço: remova o pacote e todos os serviços continuam a funcionar exatamente como antes, porque o Cockpit não armazena configuração própria. O miniserv.pl do Webmin permanece residente, independentemente de haver alguém ligado. Verifique o consumo no seu sistema com systemctl status webmin, que apresenta a memória residente do processo em execução.

Se precisar dos módulos de DNS ou de correio do Webmin, coloque-os num servidor próprio. Um servidor Webmin dedicado a uma única função e vinculado a 127.0.0.1 representa um risco contido. O Webmin a partilhar um host com a sua aplicação voltada para os clientes não representa. Faça a configuração base antes de instalar qualquer um dos painéis: os primeiros dez minutos num novo VPS abrangem o utilizador não-root e a firewall que ambos os painéis pressupõem estar configurada.

Quando a resposta não é nenhuma das duas

Um painel é específico de cada servidor e exige trabalho manual. Ele não regista o que mudou nem o motivo da alteração. Isso é aceitável para uma máquina. Com cinco máquinas, está a repetir o trabalho. Com vinte, está a tentar adivinhar qual servidor não recebeu a alteração. O Cockpit pode adicionar outros hosts à mesma sessão por SSH, mas as versões recentes desativam essa funcionalidade por predefinição e exigem AllowMultiHost=yes em /etc/cockpit/cockpit.conf. Mesmo assim, continua a obrigá-lo a clicar cinco vezes na mesma alteração.

A alternativa é usar SSH simples com a configuração num repositório git. Gerir vários servidores Linux a partir de um único local explica a estrutura dessa configuração, e um primeiro playbook Ansible aplica a mesma regra de firewall a todos os hosts a partir de um ficheiro que pode rever como diff. O trabalho com contentores segue a mesma abordagem: docker compose up -d por SSH a partir de um ficheiro no git, como descrito em o guia de conceitos básicos do Docker Compose, é melhor do que clicar em qualquer painel, e o Cockpit não gere Docker.

Use um painel para aquilo em que um terminal é pouco prático, como ler um gráfico de métricas ou identificar qual das quarenta unidades falhou. Use código para qualquer tarefa que vá executar mais de duas vezes.

Modos de falha e mensagens apresentadas

O Cockpit rejeita uma palavra-passe que o SSH aceita. A conta aceita apenas chaves. sudo passwd -S alice apresenta L no segundo campo, pelo que o PAM não tem uma palavra-passe para verificar. Defina uma com sudo passwd alice ou mantenha essa conta para o SSH e inicie sessão no Cockpit com outro utilizador.

O Cockpit recusa o root mesmo com a palavra-passe correta. /etc/cockpit/disallowed-users lista root. Inicie sessão com um utilizador normal que tenha permissões sudo. Esse é o procedimento previsto, porque o polkit regista qual foi a pessoa que elevou os privilégios.

O Cockpit não apresenta a página Networking nem a página Firewall. Essas páginas precisam do NetworkManager e do firewalld. Um VPS Ubuntu usa netplan com systemd-networkd e ufw, por isso as páginas não aparecem. Não há nenhuma falha, e a solução é continuar a usar ufw através do SSH.

A página de início de sessão do Cockpit carrega através do túnel, mas o início de sessão falha. A porta local é diferente da porta remota, pelo que a verificação Origin falha e journalctl -u cockpit apresenta essa informação. Faça corresponder as portas ou defina Origins em /etc/cockpit/cockpit.conf.

Os envios de formulários do Webmin falham depois de o colocar atrás de um proxy. A verificação Referer rejeita os pedidos. Adicione o nome de host do proxy a referers= em /etc/webmin/miniserv.conf e defina webprefix= quando o painel for servido num caminho.

Não tem a certeza de que um painel está exposto. sudo ss -lntp | grep -E '9090|10000' responde a essa questão a partir do próprio servidor, e o Webmin escreve todas as tentativas de início de sessão em /var/webmin/miniserv.log. Vale a pena consultar esse registo uma vez depois de qualquer alteração à forma como o painel escuta.

FAQ

O Cockpit ou o Webmin é melhor para um único VPS Ubuntu?

Para a maioria das pessoas, o Cockpit, porque vem do repositório oficial do Ubuntu, recebe correções juntamente com o resto do sistema e só é executado enquanto existe uma sessão do navegador aberta. Escolha o Webmin quando precisar de um editor baseado em formulários para um serviço que o Cockpit não gere, como BIND ou Postfix, e aceite em troca que o seu servidor web seja executado como root permanentemente e que as atualizações venham do próprio repositório do Webmin.

Posso executar o Cockpit e o Webmin no mesmo servidor?

Sim. Usam portas diferentes, 9090 e 10000, e não entram em conflito, porque cada um edita diretamente o sistema em vez de o controlar. Ainda assim, é uma má troca. Cada painel é um login separado com capacidade para usar root na mesma máquina, pelo que duplica a exposição para poupar alguns cliques. Se instalar ambos, faça bind dos dois a 127.0.0.1 e aceda a eles através de um túnel SSH.

É seguro abrir a porta 9090 ou 10000 para a Internet?

Não com um login por palavra-passe. Ambos os painéis dão acesso a root, e ambas as portas são encontradas por varrimentos de rotina poucas horas depois de serem abertas. Faça bind do painel a 127.0.0.1, execute ssh -N -L 9090:127.0.0.1:9090 user@host e aceda a https://localhost:9090 no navegador. Confirme com sudo ss -lntp | grep 9090, que deve mostrar 127.0.0.1:9090 em vez de 0.0.0.0:9090. Um reverse proxy autenticado é uma segunda opção aceitável.

Porque falha o meu login do Cockpit quando o SSH com uma chave funciona?

O Cockpit autentica através do PAM com uma palavra-passe Unix, e a sua página de login não aceita chaves SSH. Num servidor reforçado, a conta muitas vezes não tem uma palavra-passe utilizável. Execute sudo passwd -S youruser: um L no segundo campo significa que a palavra-passe está bloqueada, pelo que o PAM não tem nada para aceitar e todas as tentativas são rejeitadas. Defina uma palavra-passe com sudo passwd youruser ou use outra conta para o painel.

O Cockpit gere contentores Docker?

Não. A página de contentores do Cockpit vem de cockpit-podman e gere Podman. O módulo antigo do Docker foi removido há anos e não será recuperado. Se os seus serviços forem executados com Docker, faça a gestão através de um ficheiro compose sob controlo de versões e por SSH, e deixe o Cockpit gerir o sistema à sua volta, como o journal e os discos.