Como alterar a senha root da VPS no Ubuntu

Como alterar a senha do root da sua VPS no Ubuntu

Para alterar a senha do root da sua VPS (servidor virtual privado) no Ubuntu, abra uma sessão SSH (secure shell) como um usuário que possa executar sudo e execute sudo passwd root. O comando solicita a nova senha duas vezes e nunca solicita a senha antiga, porque sudo já confirmou sua identidade. Para alterar sua própria senha de login, execute passwd sem argumentos. Nesse caso, o comando solicita primeiro sua senha atual.

passwd                  # your own password
sudo passwd deploy      # another user's password
sudo passwd root        # root's password

Essa é toda a operação. O restante explica o que pode dar errado: confirmar que a nova senha funciona antes de perder a sessão que poderia corrigir o problema, definir senhas a partir de um script, expirar uma senha intencionalmente e recuperar o acesso quando a senha já foi perdida.

Abra uma segunda sessão antes de alterar uma senha

Abra agora uma segunda sessão SSH e mantenha-a conectada. Quase toda falha neste guia pode ser corrigida em dois minutos enquanto ainda houver um shell autenticado, mas exige acesso ao console depois que a última sessão for encerrada.

Um shell que já está aberto continua funcionando depois que você altera, bloqueia ou expira a conta à qual ele pertence, porque o SSH verifica as credenciais no login e não as verifica novamente. A exceção é sudo. Ele verifica novamente sua senha por meio do PAM (módulos conectáveis de autenticação) quando o carimbo de data e hora expira, por padrão 15 minutos após o último prompt. Portanto, a nova senha é testada de fato na próxima vez que sudo solicitar essa senha, e não no login.

Teste a nova senha na segunda sessão enquanto mantém a primeira aberta.

Altere sua própria senha com passwd

passwd

Changing password for deploy.
Current password:
New password:
Retype new password:
passwd: password updated successfully

passwd: password updated successfully é a única saída que significa que o hash em /etc/shadow foi substituído. Qualquer outra saída manteve a senha antiga.

Duas falhas ocorrem aqui. passwd: Authentication token manipulation error, seguido de passwd: password unchanged, significa que a senha atual digitada estava incorreta ou que o sistema de arquivos que contém /etc/shadow não pode ser gravado, que é o estado normal no modo de recuperação. You must choose a longer password. vem de pam_unix em /etc/pam.d/common-password, que aplica verificações de comprimento e similaridade a usuários comuns.

Na maioria das imagens de VPS, a conta padrão (ubuntu ou qualquer nome fornecido pelo seu provedor) não tem senha, apenas uma chave SSH. passwd não tem uma senha atual para verificar e, por isso, não consegue passar pelo primeiro prompt. Use sudo passwd $USER, que funciona porque o arquivo drop-in do sudoers da imagem permite que essa conta execute sudo sem senha.

Alterar a senha de outro usuário com sudo passwd

sudo passwd deploy

O root não precisa informar a senha antiga, e pam_unix ignora as verificações de força aplicadas a usuários comuns. Assim, o root pode definir uma senha que o usuário não poderia definir por conta própria.

Bloquear a senha é uma ação separada. sudo passwd -l deploy coloca um ! antes do hash armazenado, portanto nenhuma senha corresponde a ele. sudo passwd -u deploy remove esse caractere. Leia o estado novamente com sudo passwd -S deploy.

Bloquear a senha não impede que o usuário faça login. Qualquer chave em ~/.ssh/authorized_keys continua funcionando, porque a autenticação por chave pública nunca consulta /etc/shadow. Para bloquear completamente uma conta, expire a própria conta:

sudo usermod --expiredate 1 deploy

Isso define a expiração da conta para uma data em 1970, fazendo o sshd recusar o login, independentemente da credencial apresentada. Desfaça isso com sudo usermod --expiredate '' deploy.

Evite passwd -d. Ele define uma senha vazia em vez de bloquear a conta. Em uma versão mais antiga que ainda contenha nullok na pilha do PAM, uma senha vazia pode ser usada por qualquer pessoa.

O root precisa de uma senha em um VPS?

O Ubuntu é distribuído com o root bloqueado. /etc/shadow contém ! no lugar de um hash, e sudo passwd -S root exibe uma linha que começa com root L. Ninguém pode fazer login como root usando uma senha até que você defina uma. Por isso, a imagem fornece um usuário com capacidade de usar sudo. Trabalhar usando contas de usuário com privilégio mínimo em um VPS, em vez de trabalhar como root, é o padrão que deve ser mantido.

Definir uma senha para root oferece uma única vantagem específica: uma forma de acesso pelo console do provedor. Esse console se conecta à máquina virtual abaixo da pilha de rede. Por isso, continua funcionando quando o sshd está configurado incorretamente ou uma regra de firewall está errada. Isso também tem um custo. O shell de root do menu de recuperação do GRUB solicita a senha de root quando ela existe. Assim, a ferramenta que você usaria para redefinir uma senha esquecida passa a ficar protegida pela mesma senha.

Definir uma senha para root não permite que root faça login por SSH. O Ubuntu é distribuído com PermitRootLogin prohibit-password, o que significa que somente chaves são aceitas. Verifique o que o seu servidor realmente usa:

sudo sshd -T | grep -i permitrootlogin

sshd -T exibe a configuração efetiva depois que cada linha Include é resolvida. Portanto, é a única resposta confiável quando /etc/ssh/sshd_config.d/ contém arquivos drop-in.

Defina uma senha a partir de um script com chpasswd

passwd lê a senha do terminal e não pode ser controlado por um script. chpasswd lê pares de user:password na entrada padrão, um por linha.

printf '%s:%s\n' 'deploy' "$NEW_PASSWORD" | sudo chpasswd

Isso funciona, mas coloca uma senha em texto simples no histórico do shell e nos logs da sua CI (integração contínua). Gere o hash primeiro:

HASH=$(openssl passwd -6)
printf '%s:%s\n' 'deploy' "$HASH" | sudo chpasswd -e

openssl passwd -6 solicita a senha duas vezes sem exibi-la e imprime um hash crypt SHA-512 que começa com $6$. -e informa ao chpasswd que o segundo campo já está em formato de hash, portanto ele é copiado para /etc/shadow sem alterações. O hash pode ser armazenado com segurança em um repositório ou em uma variável da CI, e o texto simples nunca sai da máquina onde você o digitou.

O Ubuntu 24.04 gera hash para novas senhas usando yescrypt ($y$) quando passwd as define, enquanto openssl passwd -6 usa SHA-512. Ambos são verificados no login, porque a libxcrypt lê os dois formatos. É possível misturá-los, e openssl passwd -6 se comporta da mesma forma em todas as versões Ubuntu LTS, ao contrário de chpasswd -c YESCRYPT: o pacote shadow mais antigo do 20.04 não reconhece esse nome de método.

Como verificar se a senha realmente foi alterada?

Comece pelos metadados e confirme o resultado com um login.

sudo passwd -S deploy

deploy P 08/01/2026 0 99999 7 -1

O segundo campo indica o estado: P para uma senha utilizável, L para uma senha bloqueada e NP para nenhuma senha. A data indica quando a senha foi alterada pela última vez, portanto deve mostrar a data de hoje. Os números seguintes são os campos de validade descritos abaixo.

O teste ativo mais seguro é o próprio sudo. sudo -k descarta o registro de data e hora armazenado em cache, e sudo -v força um novo prompt. Se a nova senha for aceita nesse ponto, o PAM a aceitou, e nada na sua sessão foi alterado.

sudo -k && sudo -v

Para testar outra conta, execute su - deploy em um shell sem privilégios. Não execute sudo su - deploy, porque root nunca recebe uma solicitação de senha e o teste não comprova nada. Uma senha incorreta exibe su: Authentication failure.

O teste real é um novo login SSH a partir do seu laptop, mantendo a sessão de trabalho aberta:

ssh -o PubkeyAuthentication=no deploy@203.0.113.10

Permission denied (publickey). neste caso significa que o servidor nunca ofereceu autenticação por senha, portanto nenhuma alteração de senha permitirá o acesso. Permission denied, please try again. significa que o servidor ofereceu esse método, mas rejeitou o que você digitou.

Forçar a troca da senha no próximo login com chage

sudo chage -d 0 deploy

-d 0 define a data da última alteração como a época Unix, fazendo o PAM tratar a senha como expirada. No próximo login interativo, o sistema solicita a senha atual e, em seguida, uma nova senha, antes de fornecer um shell. sudo passwd -e deploy faz exatamente a mesma coisa.

Use isso somente em contas que fazem login interativamente com uma senha. Uma senha expirada também afeta logins baseados em chaves, porque o sshd executa a etapa de conta do PAM mesmo quando uma chave foi usada para autenticação. Um ssh deploy@203.0.113.10 'systemctl restart app' executado por script falha com esta mensagem e é interrompido:

Password change required but no TTY available.

Nada depois dessa linha é executado, e o job informa apenas um código de saída diferente de zero.

O que significam os campos de expiração da senha

sudo chage -l deploy

Last password change                                    : Aug 01, 2026
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

Esses números são os campos 4 a 8 da linha desse usuário em /etc/shadow. Mínimo de dias (chage -m) é o tempo que o usuário deve esperar antes de alterar a senha novamente. Isso impede que alguém volte imediatamente à senha antiga após uma alteração forçada. Máximo de dias (chage -M) é por quanto tempo a senha permanece válida. Dias de aviso (chage -W) indica quando os logins começam a exibir um aviso. Dias de inatividade (chage -I) é o período de tolerância após a expiração, antes que a senha deixe de ser aceita. Expiração da conta (chage -E) é uma data fixa e independente da senha.

sudo chage -M 90 -W 14 deploy

Defina esse valor somente quando uma política exigir. O NIST (National Institute of Standards and Technology dos EUA) recomenda desde 2017 não expirar senhas rotineiramente, porque isso incentiva as pessoas a usar variações previsíveis de uma mesma senha. A recomendação é forçar uma alteração quando houver evidências de comprometimento. Uma senha longa e exclusiva armazenada em um gerenciador de senhas, combinada com SSH baseado em chaves, é mais segura do que um ciclo de 90 dias.

O que fazer quando você perdeu a senha do root

Se alguma conta no servidor puder executar sudo, não há nada a recuperar: sudo passwd root define uma nova senha. O caso difícil ocorre quando não há nenhum login funcional.

Tudo abaixo exige o console do provedor, geralmente listado nos painéis como console VNC (virtual network computing) ou console serial. Ele se conecta à máquina virtual abaixo da pilha de rede, portanto as configurações do sshd e as regras do firewall não o afetam.

1. Reinicie o servidor pelo painel e monitore o console.
2. Abra o menu do GRUB. Imagens de nuvem geralmente definem GRUB_TIMEOUT=0, portanto mantenha Shift pressionado durante uma inicialização BIOS ou pressione Esc repetidamente durante uma inicialização UEFI, assim que a reinicialização começar.
3. Selecione Advanced options for Ubuntu, depois a entrada terminada em (recovery mode) e, em seguida, root no menu de recuperação.
4. Execute mount -o remount,rw / primeiro. O modo de recuperação monta o sistema de arquivos root como somente leitura. Sem isso, passwd falha com passwd: Authentication token manipulation error porque não pode gravar em /etc/shadow.
5. Execute passwd ubuntu para a conta necessária e reinicie pelo painel.

Se root já tiver uma senha e essa for a senha perdida, esse shell de recuperação solicitará a senha, e esse caminho estará bloqueado. Inicialize a imagem de recuperação do provedor, monte o disco real e altere a senha dentro dele.

lsblk
sudo mount /dev/vda1 /mnt
sudo mount --bind /dev /mnt/dev
sudo mount --bind /proc /mnt/proc
sudo mount --bind /sys /mnt/sys
sudo chroot /mnt passwd ubuntu
sudo umount -R /mnt

Leia o layout das partições usando lsblk em vez de copiar /dev/vda1 desta página. A partição root é a maior. Em uma imagem UEFI, ela fica ao lado de uma pequena partição EFI que não contém nenhum diretório /etc.

O que fazer quando o SSH parar de aceitar sua senha

Trabalhe a partir da sessão que você ainda tem. Se não houver mais nenhuma sessão, use o console.

Permission denied, please try again. significa que o servidor ofereceu autenticação por senha e rejeitou o que você enviou. As causas mais comuns são o caps lock ativado ou um layout de teclado do console diferente daquele usado quando você definiu a senha.

Permission denied (publickey). significa que o servidor nunca ofereceu autenticação por senha. PasswordAuthentication no está definido em algum lugar. No Ubuntu 22.04 e posteriores, ele geralmente fica em um arquivo de configuração complementar em /etc/ssh/sshd_config.d/ que substitui o arquivo principal. Leia os valores efetivos:

sudo sshd -T | grep -Ei 'passwordauthentication|kbdinteractiveauthentication|permitrootlogin'

KbdInteractiveAuthentication yes junto com PasswordAuthentication no ainda permite o uso de uma senha, porque o método keyboard-interactive usa a mesma pilha PAM. Desativar um e manter o outro ativado faz com que um servidor que aparenta aceitar apenas chaves continue aceitando senhas digitadas.

Too many authentication failures em uma mensagem de desconexão significa que o cliente ofereceu várias chaves antes de chegar à senha, e o servidor atingiu MaxAuthTries, que por padrão é 6. Force um único método:

ssh -o IdentitiesOnly=yes -o PubkeyAuthentication=no deploy@203.0.113.10

Connection refused em uma porta que funcionava há um minuto geralmente significa que o fail2ban está monitorando o SSH e bloqueou seu endereço após várias falhas. A regra de bloqueio padrão rejeita o pacote em vez de descartá-lo. Por isso, a recusa retorna rapidamente em vez de atingir o tempo limite. No console, sudo fail2ban-client status sshd lista os endereços bloqueados e sudo fail2ban-client set sshd unbanip 203.0.113.10 remove o bloqueio do seu endereço.

Senhas são uma etapa intermediária; chaves são o estado final

Uma senha que funciona via SSH é uma senha que qualquer scanner na internet pode tentar adivinhar. Migre para a autenticação baseada em chaves; assim, as tentativas deixam de ser relevantes. Gere um par de chaves, instale a parte pública e confirme, em um segundo terminal, que a chave permite fazer login antes de alterar qualquer outra coisa. Noções básicas de gerenciamento de chaves SSH aborda a geração, authorized_keys e as frases secretas.

Depois, desative a autenticação por senha e confirme a alteração com sudo sshd -T, em vez de confiar no arquivo editado. proteção do SSH em um VPS apresenta as demais configurações do sshd que vale a pena alterar, e os primeiros dez minutos em um VPS novo define a ordem para aplicá-las em um servidor recém-instalado.

Depois disso, mantenha uma senha. Um servidor que aceita apenas chaves e tem uma configuração do sshd com problemas só pode ser acessado pelo console do provedor, que solicita um nome de usuário e uma senha. Uma conta com uma senha forte armazenada por você é o que diferencia uma correção de cinco minutos de uma reinstalação.

FAQ

Como altero a senha do root no meu VPS se não sei a senha antiga?

Entre como um usuário que possa executar sudo e execute sudo passwd root. Esse comando define uma nova senha sem solicitar a antiga, porque sudo já autenticou você. Se nenhuma conta no servidor puder executar sudo, abra o console do provedor, reinicie no menu de recuperação do GRUB, escolha a entrada de shell root, execute mount -o remount,rw / e depois execute passwd. Se root já tiver uma senha e essa for a senha perdida, o shell de recuperação a solicitará. Nesse caso, use a imagem de rescue do provedor, monte o disco e execute chroot.

Por que passwd exibe "Authentication token manipulation error"?

Duas causas produzem essa mensagem. A causa mais comum é uma resposta incorreta ao prompt Current password:, e a linha passwd: password unchanged abaixo confirma que nada foi gravado. A outra é um sistema de arquivos que não permite gravação. Isso ocorre no modo de recuperação porque / é montado como somente leitura. Execute mount -o remount,rw / e tente novamente.

Alterar minha senha do Linux também altera minha senha do sudo?

Sim. sudo não tem uma senha própria. Ele autentica você por meio do PAM usando a mesma entrada de /etc/shadow usada por SSH e su. Portanto, há uma senha por conta. Por isso, o primeiro prompt de sudo após uma alteração é o teste real. Execute sudo -k && sudo -v para forçar esse prompt enquanto você ainda tiver uma sessão funcional.

Alterar minha senha interromperá minhas chaves SSH ou minhas sessões abertas?

Não. A autenticação por chave pública nunca lê /etc/shadow. Portanto, as chaves continuam funcionando após uma alteração de senha, depois de passwd -l e depois de chage -d 0. As sessões já abertas continuam abertas porque o SSH verifica as credenciais somente no login. A única coisa que muda dentro de uma sessão ativa é sudo, que solicita a nova senha quando o registro de 15 minutos expira.

Como forço um usuário a alterar a senha no próximo login?

Execute sudo chage -d 0 deploy ou sudo passwd -e deploy, que faz a mesma coisa. A data armazenada da última alteração volta para a época Unix, o PAM considera a senha expirada e o próximo login interativo deve definir uma nova senha antes de iniciar um shell. Não faça isso em uma conta usada por scripts via SSH. Nesse caso, um comando não interativo falha com Password change required but no TTY available. e nunca é executado.