Como alterar a senha root do VPS no Ubuntu

Como alterar a palavra-passe root do VPS no Ubuntu

Para alterar a palavra-passe root do seu VPS (servidor privado virtual) no Ubuntu, abra uma sessão SSH (secure shell) com um utilizador que possa executar sudo e, em seguida, execute sudo passwd root. O comando pede a nova palavra-passe duas vezes e não pede a antiga, porque sudo já confirmou a sua identidade. Para alterar a palavra-passe da sua própria conta, execute passwd sem argumentos. Nesse caso, o comando pede primeiro a palavra-passe 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 os casos que normalmente causam problemas: confirmar que a nova palavra-passe funciona antes de perder a sessão que poderia corrigir o problema, definir palavras-passe a partir de um script, fazer uma palavra-passe expirar de propósito e recuperar o acesso quando a palavra-passe já foi perdida.

Abra uma segunda sessão antes de alterar uma palavra-passe

Abra agora uma segunda sessão SSH e mantenha-a ligada. Quase todas as falhas neste guia podem ser corrigidas em dois minutos enquanto ainda existe uma shell autenticada, mas exigem acesso à consola quando a última sessão é encerrada.

Uma shell que já esteja aberta continua a funcionar depois de alterar, bloquear ou expirar a conta a que pertence, porque o SSH verifica as credenciais no início da sessão e não volta a verificá-las. A exceção é sudo. Este componente volta a verificar a palavra-passe através do PAM (módulos de autenticação conectáveis) quando o respetivo timestamp expira, por predefinição 15 minutos depois do último pedido. Por isso, a nova palavra-passe é testada pela primeira vez na próxima vez que sudo a pedir, e não no início da sessão.

Teste a nova palavra-passe na segunda sessão enquanto mantém a primeira aberta.

Altere a sua própria palavra-passe 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 indica que o hash em /etc/shadow foi substituído. Qualquer outra saída deixou a palavra-passe antiga intacta.

Aqui ocorrem duas falhas. passwd: Authentication token manipulation error, seguido de passwd: password unchanged, indica que a palavra-passe atual introduzida estava incorreta ou que não é possível escrever no sistema de ficheiros que contém /etc/shadow, o 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 semelhança a utilizadores comuns.

Na maioria das imagens de VPS, a conta predefinida (ubuntu ou qualquer outro nome fornecido pelo seu provedor) não tem palavra-passe, apenas uma chave SSH. passwd não tem uma palavra-passe atual para validar e, por isso, não consegue ultrapassar o primeiro pedido. Use sudo passwd $USER, que funciona porque o ficheiro adicional de sudoers da imagem permite que essa conta execute sudo sem palavra-passe.

Alterar a palavra-passe de outro utilizador com sudo passwd

sudo passwd deploy

root não pede a palavra-passe antiga, e pam_unix ignora as verificações de robustez que aplica aos utilizadores normais. Assim, root pode definir uma palavra-passe que o utilizador não poderia definir por si próprio.

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

Bloquear a palavra-passe não impede o utilizador de iniciar sessão. Qualquer chave no seu ~/.ssh/authorized_keys continua a funcionar, porque a autenticação por chave pública nunca consulta /etc/shadow. Para impedir completamente o acesso à conta, expire a própria conta:

sudo usermod --expiredate 1 deploy

Isto define a expiração da conta para uma data em 1970, portanto sshd recusa o início de sessão independentemente da credencial apresentada. Reverta a alteração com sudo usermod --expiredate '' deploy.

Evite passwd -d. Este comando define uma palavra-passe vazia em vez de bloquear a conta. Numa release mais antiga que ainda inclua nullok na pilha PAM, uma palavra-passe vazia pode ser usada por qualquer pessoa.

O root precisa de uma palavra-passe numa VPS?

O Ubuntu é distribuído com o root bloqueado. /etc/shadow mantém ! no lugar do hash, e sudo passwd -S root apresenta uma linha que começa por root L. Não é possível iniciar sessão como root com uma palavra-passe até definir uma. Por isso, a imagem fornece um utilizador com capacidade para usar sudo. Deve manter o padrão de trabalhar através de contas de utilizador com privilégios mínimos numa VPS, em vez de trabalhar como root.

Definir uma palavra-passe para root oferece uma possibilidade específica: entrar através da consola do fornecedor. Essa consola liga-se à máquina virtual por baixo da pilha de rede. Por isso, continua a funcionar quando o sshd está configurado incorretamente ou uma regra de firewall está errada. Também tem um custo. O shell root do menu de recuperação do GRUB pede a palavra-passe de root quando essa conta tem uma. Assim, a ferramenta que usaria para repor uma palavra-passe esquecida fica protegida pela mesma palavra-passe.

Definir uma palavra-passe para root não permite iniciar sessão como root através de SSH. O Ubuntu é distribuído com PermitRootLogin prohibit-password, o que significa que apenas são permitidas chaves. Verifique o que o seu servidor utiliza efetivamente:

sudo sshd -T | grep -i permitrootlogin

sshd -T apresenta a configuração efetiva depois de resolver cada linha Include. Por isso, é a única resposta fiável quando /etc/ssh/sshd_config.d/ contém ficheiros de configuração adicionais.

Definir uma palavra-passe a partir de um script com chpasswd

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

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

Isto funciona, mas coloca uma palavra-passe em texto simples no histórico da shell e nos logs de CI (integração contínua). Crie primeiro um hash:

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

openssl passwd -6 pede a palavra-passe duas vezes sem apresentar os caracteres introduzidos e depois imprime um hash crypt SHA-512 que começa por $6$. -e indica a chpasswd que o segundo campo já está com hash, por isso é copiado para /etc/shadow sem alterações. O hash pode ser guardado com segurança num repositório ou numa variável de CI, e o texto simples nunca sai da máquina onde foi introduzido.

O Ubuntu 24.04 cria hashes de novas palavras-passe com yescrypt ($y$) quando passwd as define, enquanto openssl passwd -6 usa SHA-512. Ambos são validados no início de sessão, porque a libxcrypt lê os dois formatos. Pode misturá-los, e openssl passwd -6 comporta-se 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. Esses hashes também sobrevivem a uma atualização de versão, por isso atualizar um servidor 24.04 para 26.04 não obriga a redefinir a palavra-passe de ninguém.

Como verificar se a palavra-passe foi realmente alterada?

Comece pelos metadados e confirme depois com um início de sessão.

sudo passwd -S deploy

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

O segundo campo indica o estado: P para uma palavra-passe utilizável, L para uma conta bloqueada e NP para uma conta sem palavra-passe. A data indica quando a palavra-passe foi alterada pela última vez, por isso deve corresponder à data de hoje. Os números seguintes são os campos de expiração descritos abaixo.

O teste ativo mais seguro é o próprio sudo. sudo -k elimina o carimbo temporal em cache e sudo -v força uma nova solicitação. Se a nova palavra-passe for aceite nesse ponto, o PAM aceitou-a e nada na sua sessão foi alterado.

sudo -k && sudo -v

Para testar outra conta, execute su - deploy a partir de uma shell sem privilégios. Não execute sudo su - deploy, porque root nunca recebe um pedido de palavra-passe e o teste não prova nada. Uma palavra-passe incorreta apresenta su: Authentication failure.

O teste real é um novo início de sessão SSH a partir do seu portátil, 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 palavra-passe, portanto nenhuma alteração de palavra-passe permitirá o acesso. Permission denied, please try again. significa que a ofereceu, mas rejeitou o que introduziu.

Forçar a alteração da palavra-passe no próximo início de sessão com chage

sudo chage -d 0 deploy

-d 0 define a data da última alteração como a época Unix, fazendo com que o PAM trate a palavra-passe como expirada. No próximo início de sessão interativo, é pedido primeiro o palavra-passe atual e depois uma nova, antes de ser disponibilizada uma shell. sudo passwd -e deploy faz exatamente o mesmo.

Use isto apenas em contas que iniciam sessão interativamente com uma palavra-passe. Uma palavra-passe expirada também afeta os inícios de sessão baseados em chaves, porque o sshd executa a fase de conta do PAM mesmo quando uma chave foi usada para autenticar. Um ssh deploy@203.0.113.10 'systemctl restart app' executado num script falha com este erro e é interrompido:

Password change required but no TTY available.

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

O que significam os campos de expiração da palavra-passe

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 utilizador em /etc/shadow. O número mínimo de dias (chage -m) indica quanto tempo o utilizador tem de esperar antes de voltar a alterar a palavra-passe. Isto impede que alguém volte diretamente à palavra-passe antiga depois de uma alteração forçada. O número máximo de dias (chage -M) indica durante quanto tempo a palavra-passe permanece válida. O número de dias de aviso (chage -W) indica quando os logins começam a apresentar um aviso. O número de dias de inatividade (chage -I) é o período de tolerância após a expiração, antes de a palavra-passe deixar de ser aceite. A expiração da conta (chage -E) é uma data fixa e é independente da palavra-passe.

sudo chage -M 90 -W 14 deploy

Defina esse valor apenas quando uma política o exigir. O NIST (National Institute of Standards and Technology dos EUA) recomenda, desde 2017, que não se force a expiração periódica das palavras-passe. Essa prática leva as pessoas a criar variações previsíveis da mesma palavra-passe. O NIST recomenda forçar uma alteração quando existirem indícios de comprometimento. Uma palavra-passe longa e exclusiva, guardada num gestor de palavras-passe, juntamente com SSH baseado em chaves, oferece mais segurança do que um ciclo de 90 dias.

O que fazer quando perdeu a palavra-passe de root

Se alguma conta no servidor puder executar sudo, não há nada a recuperar: sudo passwd root define uma nova palavra-passe. O caso difícil é não existir qualquer início de sessão funcional.

Tudo o que se segue requer a consola do fornecedor, normalmente identificada nos painéis como VNC (virtual network computing) ou consola série. Ela liga-se à máquina virtual abaixo da pilha de rede, por isso as definições do sshd e as regras da firewall não a afetam.

1. Reinicie o servidor a partir do painel e observe a consola.
2. Abra o menu do GRUB. As imagens cloud normalmente definem GRUB_TIMEOUT=0, por isso mantenha Shift premido durante um arranque BIOS ou prima Esc repetidamente durante um arranque UEFI, assim que o reinício começar.
3. Escolha Advanced options for Ubuntu, depois a entrada terminada em (recovery mode) e, em seguida, root no menu de recuperação.
4. Execute primeiro mount -o remount,rw /. A recuperação monta o sistema de ficheiros root apenas para leitura, por isso, sem este comando, passwd falha com passwd: Authentication token manipulation error porque não consegue escrever /etc/shadow.
5. Execute passwd ubuntu para a conta necessária e reinicie depois a partir do painel.

Se root já tiver uma palavra-passe e essa for a que perdeu, a shell de recuperação pede essa palavra-passe e este procedimento fica bloqueado. Em vez disso, arranque a imagem de recuperação do fornecedor, monte o disco real e altere a palavra-passe dentro desse sistema.

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 a disposição das partições com lsblk, em vez de copiar /dev/vda1 desta página. A partição root é a maior. Numa imagem UEFI, fica junto de uma pequena partição EFI que não contém qualquer diretório /etc.

O que fazer quando o SSH deixa de aceitar a sua palavra-passe

Trabalhe a partir da sessão que ainda tem aberta. Se já não houver nenhuma sessão, use a consola.

Permission denied, please try again. significa que o servidor ofereceu autenticação por palavra-passe e rejeitou o que enviou. As causas mais comuns são o Caps Lock ativo ou um esquema de teclado da consola diferente daquele que utilizou quando definiu a palavra-passe.

Permission denied (publickey). significa que o servidor nunca ofereceu autenticação por palavra-passe. PasswordAuthentication no está definido algures e, no Ubuntu 22.04 e posteriores, normalmente está num ficheiro de configuração adicional em /etc/ssh/sshd_config.d/ que substitui o ficheiro principal. Leia os valores efetivos:

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

KbdInteractiveAuthentication yes juntamente com PasswordAuthentication no continua a permitir a introdução de uma palavra-passe, porque o método keyboard-interactive utiliza a mesma pilha PAM. Desativar um e deixar o outro ativo é a forma de um servidor que parece aceitar apenas chaves continuar a aceitar palavras-passe introduzidas manualmente.

Essa mesma linha também é apresentada quando um início de sessão com chave é rejeitado. Portanto, se estava a oferecer uma chave em vez de uma palavra-passe, a configuração de palavras-passe do servidor é apenas uma das cinco falhas que causam Permission denied (publickey), e o resultado de ssh -v indica qual delas está a ocorrer.

Too many authentication failures numa mensagem de desligamento significa que o cliente ofereceu várias chaves antes de chegar à palavra-passe, e o servidor atingiu MaxAuthTries, que é 6 por predefinição. Force um único método:

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

Connection refused numa porta que funcionava há um minuto normalmente significa que o fail2ban está a monitorizar o SSH e baniu o seu endereço depois de várias falhas. A regra de banimento predefinida rejeita o pacote em vez de o descartar, razão pela qual a recusa regressa rapidamente em vez de ocorrer um timeout. A partir da consola, sudo fail2ban-client status sshd lista os endereços banidos e sudo fail2ban-client set sshd unbanip 203.0.113.10 remove o seu.

Senhas são uma etapa intermédia; as chaves são o estado final

Uma senha que funciona pelo SSH é uma senha que qualquer scanner na Internet pode tentar adivinhar. Mude para a autenticação baseada em chaves e as tentativas de adivinhação deixam de ser relevantes. Gere um par de chaves, instale a chave pública e confirme, a partir de um segundo terminal, que a chave permite iniciar sessão antes de alterar qualquer outra coisa. Noções básicas de gestão 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 apenas no ficheiro que editou. Reforçar a segurança do SSH num VPS aborda as restantes definições do sshd que vale a pena alterar, e Os primeiros dez minutos num VPS novo apresenta a ordem em que deve aplicá-las num servidor acabado de instalar.

Depois disso, mantenha uma senha. Um servidor que aceita apenas chaves e tem uma configuração do sshd inválida só pode ser acedido através da consola do fornecedor, e essa consola pede um nome de utilizador e uma senha. Uma conta com uma senha forte guardada é o que separa uma correção de cinco minutos de uma reinstalação.

FAQ

Como altero a palavra-passe de root no meu VPS se não sei a antiga?

Inicie sessão com um utilizador que possa executar sudo e execute sudo passwd root. O comando define uma nova palavra-passe sem pedir a antiga, porque sudo já o autenticou. Se nenhuma conta no sistema puder executar sudo, abra a consola do fornecedor, reinicie no menu de recuperação do GRUB, escolha a entrada da shell root, execute mount -o remount,rw / e, em seguida, execute passwd. Se root já tiver uma palavra-passe e essa for a que perdeu, a shell de recuperação pede-a. Nesse caso, a alternativa é usar a imagem de rescue do fornecedor, montar o disco e executar chroot.

Porque é que passwd apresenta "Authentication token manipulation error"?

Duas causas produzem essa mensagem. A mais comum é uma resposta incorreta ao pedido Current password:. A linha passwd: password unchanged apresentada abaixo confirma que nada foi escrito. A outra é um sistema de ficheiros que não permite escrita. É isso que acontece no modo de recuperação, porque / está montado como apenas de leitura. Execute mount -o remount,rw / e tente novamente.

Alterar a minha palavra-passe do Linux também altera a minha palavra-passe do sudo?

Sim. sudo não tem uma palavra-passe própria. Autentica-o através do PAM, usando a mesma entrada /etc/shadow que o SSH e su usam. Por isso, existe uma palavra-passe por conta. É também por isso que o primeiro pedido sudo depois da alteração é o teste real. Execute sudo -k && sudo -v para forçar esse pedido enquanto ainda tem uma sessão funcional.

Alterar a minha palavra-passe vai invalidar as minhas chaves SSH ou fechar as minhas sessões abertas?

Não. A autenticação por chave pública nunca lê /etc/shadow. Por isso, as chaves continuam a funcionar depois de uma alteração da palavra-passe, depois de passwd -l e depois de chage -d 0. As sessões que já estão abertas continuam abertas, porque o SSH verifica as credenciais apenas no início da sessão. A única coisa que muda numa sessão ativa é sudo, que pede a nova palavra-passe quando o timestamp de 15 minutos expira.

Como obrigo um utilizador a alterar a palavra-passe no próximo início de sessão?

Execute sudo chage -d 0 deploy ou sudo passwd -e deploy, que faz a mesma coisa. A data da última alteração armazenada passa para a época Unix. O PAM considera a palavra-passe expirada, e o próximo início de sessão interativo tem de definir uma nova antes de iniciar a shell. Não faça isto numa conta usada por scripts através de SSH. Nesse caso, um comando não interativo falha com Password change required but no TTY available. e nunca é executado.