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 do systemd: iniciar, parar, ativar e ler 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 o 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 avariadas numa VPS Ubuntu, mas não estão. A página Networking do Cockpit é um front-end para o NetworkManager, e as imagens de servidor Ubuntu usam netplan com systemd-networkd, por isso a página não aparece ou fica vazia. Não instale o 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 um front-end para o 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 abrange muito mais áreas, porque é uma coleção de módulos específicos 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 transferência
• front-ends de firewall, incluindo um para iptables e outro 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

A maioria dos formulários do Webmin edita os ficheiros reais em /etc, sem uma base de dados oculta por trás. Assim, se /etc estiver sob controlo de versões, sudo git -C /etc diff depois de guardar um formulário mostra o que o módulo escreveu nesse local. Não mostra ações que executem um comando ou SQL, como fazem os módulos do MariaDB e PostgreSQL, nem escritas em ficheiros fora de /etc. Dentro destes limites, é a forma mais rápida de perceber o que uma 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, destinados ao alojamento partilhado e aos utilizadores finais, e herdam tudo o que é referido 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, 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 cockpit mostra a versão instalada e o repositório de origem. Executado sem um nome de pacote, apt policy lista apenas a prioridade de cada origem. Se o backports não tiver uma compilação mais recente, o apt recorre à versão do arquivo de pacotes, o que é aceitável. cockpit.socket deve mostrar 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 publicador 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 publicador 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. O problema chegou aos utilizadores porque o host de compilação do projeto foi comprometido, não o 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 vê é um aviso do navegador. Criar e confiar num certificado autoassinado explica o que esse aviso indica e o que não indica. Ambas as portas são verificadas constantemente, e ambos os painéis dão acesso a root. Por isso, uma palavra-passe adivinhada ou reutilizada compromete totalmente o servidor.

O padrão seguro é associar o painel a localhost e aceder-lhe 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 é obrigatória. O systemd acrescenta valores às definições de lista. Sem ela, 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 significa que a substituição não foi aplicada. Agora abra o túnel a partir da sua própria máquina e navegue para https://localhost:9090:

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

A porta local não tem de corresponder à porta remota. O Cockpit constrói a origem esperada a partir do cabeçalho Host enviado pelo navegador. Por isso, um túnel aberto na porta local 9999 em https://localhost:9999 passa a mesma verificação, porque os cabeçalhos Host e Origin do navegador indicam o mesmo endereço. A verificação falha quando algo entre o navegador e o Cockpit altera Host, como um reverse proxy que não encaminha o cabeçalho original. A página de login é carregada, mas o login falha, e cockpit-ws regista received request from bad Origin. Essa linha está no journal das unidades cockpit-wsinstance-https@, não em cockpit.service. Leia-a com sudo journalctl -u 'cockpit-wsinstance-https@*'. Para aceitar um endereço público diferente do endereço que o Cockpit vê, indique-o em /etc/cockpit/cockpit.conf:

[WebService]
Origins = https://panel.example.com

Reinicie com sudo systemctl restart cockpit para aplicar essa definição. No Webmin, a definição equivalente está 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 host. É isso que faz falhar a primeira tentativa de usar um reverse proxy. A linha referers= em /etc/webmin/config permite o hostname do proxy, e webprefix= no mesmo ficheiro indica ao Webmin que está alojado num caminho.

Um reverse proxy autenticado é a outra opção: nginx na frente, com uma camada de início de sessão único Authentik a tratar do login. Funciona, mas é a segunda melhor opção. O painel continua a executar como root atrás do proxy, e passa a manter duas portas de entrada em vez de uma. Um túnel não adiciona nenhum 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 nenhuma das duas opções é adequada

O painel é específico de cada servidor e exige intervenção manual. Também não deixa um registo do que mudou nem do motivo. Isso é aceitável para uma máquina. Com cinco máquinas, começa a repetir o trabalho. Com vinte, já precisa de adivinhar qual servidor não recebeu a alteração. O Cockpit pode adicionar outros hosts à mesma sessão através de SSH, mas esse seletor de hosts está obsoleto desde o Cockpit 322. O comportamento predefinido depende agora da distribuição. Quando está desativado, é necessário definir AllowMultiHost=yes em /etc/cockpit/cockpit.conf. Mesmo ativado, continua a obrigar a repetir a mesma alteração cinco vezes.

A alternativa é usar SSH diretamente e manter a configuração num repositório git. Gerir vários servidores Linux a partir de um único local explica a estrutura dessa configuração. Um primeiro playbook do Ansible aplica a mesma regra de firewall a todos os hosts a partir de um ficheiro que pode ser revisto como um diff. O trabalho com contentores segue o mesmo princípio: executar docker compose up -d por SSH a partir de um ficheiro no git, como descrito em o guia básico do Docker Compose, é melhor do que utilizar qualquer painel. Além disso, o Cockpit não gere Docker.

Use um painel para tarefas em que um terminal é pouco prático, como consultar 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 que verá

O Cockpit rejeita uma palavra-passe que o SSH aceita. A conta utiliza apenas chaves. sudo passwd -S alice apresenta L no segundo campo, pelo que o PAM não tem nenhuma palavra-passe para validar. 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 apresenta 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 efetuou a elevação.

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 utiliza netplan com systemd-networkd e ufw, pelo que as páginas não aparecem. Não há nenhuma falha; continue a utilizar ufw através do SSH.

A página de início de sessão do Cockpit carrega atrás de um proxy, mas o início de sessão falha. O proxy alterou o cabeçalho Host, pelo que a verificação Origin falha e sudo journalctl -u 'cockpit-wsinstance-https@*' apresenta received request from bad Origin. Encaminhe o Host original ou defina Origins em /etc/cockpit/cockpit.conf. Um túnel SSH simples não causa este problema, independentemente da porta local escolhida.

Os envios de formulários do Webmin falham depois de o colocar atrás de um proxy. A verificação Referer rejeita-os. Adicione o nome de anfitrião do proxy a referers= em /etc/webmin/config e defina webprefix= nesse ficheiro quando o painel for servido através de um 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 regista todas as tentativas de início de sessão em /var/webmin/miniserv.log. Vale a pena consultar esse ficheiro uma vez depois de qualquer alteração à forma como o serviço 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.