Como os usuários são criados no Linux, por dentro

Publicado em 2026-09-12 por frfrand

Qué hace realmente adduser: los cuatro archivos donde vive un usuario, para qué sirve /etc/skel y las dos trampas clásicas al crear y borrar cuentas.

adduser deploy e pronto. Mas o que aconteceu exatamente?

Nada mágico: foram escritos quatro arquivos de texto simples. Entender quais são muda bastante a relação com o sistema, porque a partir daí você pode ler o estado do seu servidor em vez de adivinhar.

/etc/passwd, a ficha pública

deploy:x:1001:1001:Deploy user:/home/deploy:/bin/bash

Sete campos separados por dois pontos: nome, marcador de senha, uid, gid, comentário, pasta pessoal e shell.

Este arquivo pode ser lido por qualquer pessoa. Por isso a senha não está mais aqui: o x significa "está no shadow". Nos anos setenta ela realmente vivia neste arquivo, e esse foi exatamente o problema que originou o /etc/shadow.

Duas coisas que se lêem de passagem:

• Um usuário com shell /usr/sbin/nologin ou /bin/false não pode iniciar sessão. Assim estão quase todos os usuários de serviço.
• O uid é o que manda. Dois nomes distintos com o mesmo uid são, para o kernel, o mesmo usuário.

/etc/shadow, a parte privada

deploy:$y$j9T$Kx2...:20028:0:99999:7:::

Aqui está o hash da senha, não a senha. O prefixo diz com qual algoritmo foi gerado: $y$ é yescrypt, $6$ é SHA-512. Se você vir $1$ (MD5) em um servidor moderno, algo está arrastado de muito atrás.

Os números que seguem são a política de envelhecimento: quando foi alterada pela última vez, a cada quanto pode e deve ser alterada, quantos dias de aviso.

Um sinal de exclamação ou um asterisco no início do hash significa que a conta não tem senha válida. Na prática, impede o login por senha, que é o habitual em um servidor onde se entra por chave SSH.

/etc/group e a armadilha do -a

sudo:x:27:deploy,ana docker:x:989:deploy

Cada linha é um grupo com a lista de seus membros secundários.

E aqui está uma das armadilhas mais caras do Linux:

usermod -G docker deploy # APAGA todos os outros grupos usermod -aG docker deploy # adiciona, que é o que você queria

Sem o "a", o comando substitui a lista completa de grupos secundários. Se deploy estava em sudo e você executou o primeiro, acabou de remover as permissões de administração. Se, além disso, você tinha o login do root desabilitado, precisará do console do provedor para consertar.

Escreva sempre -aG, como se fosse uma única palavra.

/etc/skel, o modelo da pasta pessoal

Quando se cria um usuário, sua pasta não nasce vazia: o conteúdo de /etc/skel é copiado.

Aí vivem o .bashrc, o .profile e o que você quiser adicionar. É o lugar certo para deixar a configuração que você quer que todos tenham naquele servidor: aliases úteis, um .vimrc razoável, uma mensagem de boas-vindas com as convenções da equipe.

$ ls -a /etc/skel . .. .bash_logout .bashrc .profile

Mudá-lo não afeta os usuários existentes, apenas os que forem criados depois.

Excluir um usuário tem mais passos do que parece

$ deluser --remove-home deploy

Isso exclui a conta e a pasta. Mas ainda ficam alguns cabos soltos que vale a pena revisar:

• /etc/sudoers.d/ : se havia uma regra para esse usuário, ela continua lá. E como as regras são escritas por nome, o dia em que outro usuário for criado com o mesmo nome, ele herda as permissões.
• crontab -u deploy -l : as tarefas agendadas do usuário.
• Arquivos órfãos: "find / -uid 1001" encontra o que ficou com o UID antigo. Se mais tarde outro usuário for criado com esse UID, ele se torna o dono desses arquivos sem saber.
• As chaves SSH do usuário em outros servidores, que não estão nesta máquina.

A forma curta

Para o dia a dia, o adduser (o invólucro interativo do Debian e Ubuntu) faz tudo corretamente e pergunta o necessário. O useradd é o comando de baixo nível: mais controle, e também mais formas de esquecer algo.

$ adduser deploy $ usermod -aG sudo deploy $ mkdir -p /home/deploy/.ssh && chmod 700 /home/deploy/.ssh $ chown -R deploy:deploy /home/deploy/.ssh

No ArduMaker, os usuários de um VPS são criados a partir do painel, cada um com sua própria chave SSH e permissões, sem precisar lembrar da ordem nem do "a". Mas saber quais arquivos estão sendo modificados por baixo é o que permite diagnosticar quando algo não fecha.