Visudo no Linux: modificando o sudoers sem perder o acesso root.

Um erro em /etc/sudoers pode remover seu último acesso de administrador enquanto a sessão SSH ainda estiver em execução. O risco geralmente decorre de uma regra mal escrita, um caminho de comando incorreto ou um arquivo adicionado muito rapidamente ao sistema. /etc/sudoers.d.

Eu nunca edito o arquivo sudoers com um editor aberto diretamente no arquivo. visual Bloqueie a configuração durante a edição e verifique a sintaxe antes de salvar. Em um servidor remoto, mantenha também uma segunda sessão root aberta até o teste final. Essa medida de segurança é tão importante quanto o próprio comando.

O Tux valida uma configuração do sudoers, mantendo ao mesmo tempo o acesso de administrador de backup. — O Visudo verifica a sintaxe do sudoers antes de salvar, mas uma segunda sessão root continua sendo essencial em um servidor remoto.

Primeiro, confirme se sua conta ainda possui privilégios de sudo e verifique quais comandos ela está autorizada a usar:

sudo -v
sudo -l
eu ia
grupos

sudo -v Valida informações de autenticação sem executar um comando sensível. sudo -l

Em seguida, abra um segundo terminal e mantenha uma sessão de root nele:

sudo -eu
Quem
c

Não feche esta sessão enquanto estiver editando. Em uma máquina remota, verifique também o acesso ao console, KVM ou painel de recuperação. O guia sobre o Contas e grupos Linux Pode ajudar você a confirmar a conta de destino antes de conceder privilégios a ela.

Salvar sudoers sem alterar suas permissões

Antes de editar, copie o arquivo principal para uma pasta reservada para o usuário root. A opção conserva, em particular, o proprietário, o grupo e o modo:

sudo cp -a /etc/sudoers "/root/sudoers.backup-$(date +%F-%H%M)"
sudo stat -c '%A %a %U:%G %n' /etc/sudoers /etc/sudoers.d

Em muitas distribuições, /etc/sudoers pertence a raiz: raiz quatrocentos e quarenta

Edite o arquivo principal com visudo

Para abrir a configuração principal, basta executar:

sudo visudo

visual Cria um bloqueio para impedir duas edições simultâneas. Ao fechar, analisa a sintaxe e normalmente recusa a instalação de uma configuração inválida. Se a ferramenta reportar um erro, retorne ao editor e corrija-o. Não force o salvamento de um arquivo que você não entende.

Uma regra do sudoers normalmente segue esta lógica: usuário ou grupo, hosts envolvidos, identidade de execução e, em seguida, comandos autorizados. Para autorizar a conta Alice Para reiniciar e verificar apenas o Nginx, primeiro verifique o caminho do binário:

comando -v systemctl

/usr/bin/systemctlA regra pode assumir esta forma:

Não use SEM SENHA Por hábito. Para automação, limite a uma única conta, um único comando e argumentos controlados. Uma regra ampla que concede acesso a um shell, editor ou comando que pode executar outros programas muitas vezes equivale a conceder acesso root completo.

Crie um arquivo limpo em /etc/sudoers.d

Para uma regra específica de um departamento ou equipe, prefiro um fragmento separado em vez do arquivo principal grande. Abra-o com a opção -f :

sudo visudo -f /etc/sudoers.d/administration

Escolha um nome simples, sem espaços, pontos ou caracteres especiais, como: ~De acordo com a diretiva @includedir Utilizado pela distribuição, alguns nomes podem ser ignorados. Após o registro, verifique o proprietário e o modo:

sudo chown root:root /etc/sudoers.d/administration

sudo stat -c '%A %a %U:%G %n' /etc/sudoers.d/administration

O tutorial geral sobre sudo no Linux Detalha a delegação por usuários, grupos e aliases. Aqui, o objetivo permanece mais restrito: instalar uma regra verificável sem perder a capacidade de reverter para a versão anterior.

Confirme toda a configuração antes de testar.

Após a edição ser concluída, execute uma verificação completa. Este comando verifica o arquivo principal e os arquivos incluídos aos quais ele faz referência:

sudo visudo -c

O resultado deve indicar que os arquivos analisados estão sintaticamente corretos. Se um fragmento for relatado, reabra esse arquivo específico com visudo -f

sudo -l -U alice

Essa leitura permite identificar uma regra que não foi carregada, um nome de usuário incorreto ou uma autorização muito mais ampla do que o esperado.

Faça o teste em uma nova sessão antes de fechar o root.

Abra uma terceira sessão com a conta em questão. Não utilize simplesmente a sessão que já possui um ticket sudo em cache. Invalide esse cache, solicite a lista de privilégios e, em seguida, execute apenas o comando autorizado:


sudo -v

sudo systemctl status nginx

Verifique também se um comando inesperado ainda é recusado. Uma regra está correta se o usuário mantiver o acesso esperado sem obter mais privilégios do que o necessário. Encerre a sessão root de backup somente após este teste.

Se visudo -c Se a operação falhar, corrija o fragmento defeituoso na sessão root ainda aberta. Para reverter ao arquivo salvo principal, substitua o caminho pelo seu backup atual:

cp -a /root/sudoers.backup-AAAA-MM-DD-HHMM /etc/sudoers
visudo -c

Se todas as sessões de administrador já estiverem fechadas, use o console do fornecedor, o modo de recuperação ou um ambiente ativo para montar o sistema e reparar a configuração. Editar o arquivo sudoers a partir de uma conta sem privilégios não funcionará.

Para entender uma recusa após uma validação bem-sucedida, verifique os eventos sudo da inicialização atual e, em seguida, o log de autenticação, caso sua distribuição o utilize:


sudo tail -n 100 /var/log/auth.log

Lá Página do manual do Visudo Documenta o bloqueio, o controle e a opção -f. Documentação sudoers(5) Este documento descreve a sintaxe, as inclusões e as regras de comando. Acima de tudo, mantenha esta ordem: faça backup do acesso, salve e edite com visual, validação global e, em seguida, teste em uma nova sessão.