Como alterar a senha root do VPS no Ubuntu

Como alterar a palavra-passe root do seu 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 execute sudo passwd root. O comando pede a nova palavra-passe duas vezes e nunca pede a antiga, porque sudo já confirmou a sua identidade. Para alterar a sua própria palavra-passe de início de sessão, execute passwd sem argumentos. 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

Esta é toda a operação. O restante texto aborda os problemas que podem ocorrer: 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, expirar uma palavra-passe 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 deste guia podem ser corrigidas em dois minutos enquanto uma shell autenticada continua ativa. Depois de a última sessão ser fechada, normalmente é necessário aceder à consola.

Uma shell já aberta continua a funcionar depois de alterar, bloquear ou expirar a conta a que pertence, porque o SSH verifica as credenciais no início de sessão e não as verifica novamente. A exceção é sudo. Este verifica novamente a sua palavra-passe através do PAM (módulos de autenticação conectáveis) quando o respetivo carimbo temporal expira, por predefinição 15 minutos depois do último pedido. Por isso, a nova palavra-passe só é realmente testada na próxima vez que sudo a solicitar, e não no início de 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 o sistema de ficheiros que contém /etc/shadow não pode ser escrito, 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 VPS, a conta predefinida (ubuntu ou o nome fornecido pelo seu provedor) não tem qualquer 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. Em vez disso, 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

O root não tem de fornecer a palavra-passe antiga, e pam_unix ignora as verificações de robustez aplicadas aos utilizadores comuns. Assim, o 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 ! à frente do hash armazenado, pelo que 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 respetivo ~/.ssh/authorized_keys continua a funcionar, 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

Isto define a expiração da conta para uma data em 1970, pelo que o 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 versão mais antiga que ainda inclua nullok na pilha PAM, uma palavra-passe vazia pode ser utilizada por qualquer pessoa.

É necessário definir uma palavra-passe para root numa VPS?

O Ubuntu é distribuído com root bloqueado. /etc/shadow mantém ! no lugar do hash, e sudo passwd -S root apresenta uma linha que começa por root L. Nenhuma sessão pode iniciar com root usando uma palavra-passe até definir uma, razão pela qual a imagem fornece um utilizador com capacidade para usar sudo. Deve continuar a trabalhar com contas de utilizador com privilégios mínimos numa VPS, em vez de trabalhar como root.

Definir uma palavra-passe para root oferece uma única vantagem específica: uma forma de aceder através da consola do fornecedor. Essa consola liga-se à máquina virtual abaixo da camada 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 menu de recuperação do GRUB pede a palavra-passe de root quando root tem uma definida. 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 que root inicie sessão através de SSH. O Ubuntu é distribuído com PermitRootLogin prohibit-password, o que significa que apenas são aceites chaves. Verifique o que o seu servidor utiliza:

sudo sshd -T | grep -i permitrootlogin

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

Defina 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 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 do CI (integração contínua). Faça primeiro o 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á contém um hash, por isso este é copiado para /etc/shadow sem alterações. O hash pode ser guardado com segurança num repositório ou numa variável do CI, e o texto simples nunca sai da máquina onde foi introduzido.

O Ubuntu 24.04 aplica hash yescrypt às novas palavras-passe ($y$) quando passwd as define, enquanto openssl passwd -6 usa SHA-512. Ambos são verificados no início de sessão, porque libxcrypt lê os dois formatos. É possível 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.

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 validade descritos abaixo.

O teste ativo mais seguro é o próprio sudo. sudo -k descarta o carimbo de data e hora em cache, enquanto 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 uma solicitação de palavra-passe e o teste não comprova 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). significa que o servidor nunca ofereceu autenticação por palavra-passe, portanto nenhuma alteração de palavra-passe permitirá a entrada. 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, é pedida a palavra-passe atual e, em seguida, uma nova palavra-passe, 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 fez a 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 comunica apenas um código de saída diferente de zero.

O que significam os campos de validade 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 imediatamente à 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. Os dias de aviso (chage -W) indicam quando os logins começam a apresentar um aviso. Os dias de inatividade (chage -I) são o período de tolerância depois da expiração, antes de a palavra-passe deixar de ser aceite. A expiração da conta (chage -E) é uma data limite e é independente da palavra-passe.

sudo chage -M 90 -W 14 deploy

Defina esse valor apenas quando uma política o exigir. A NIST (o National Institute of Standards and Technology dos EUA) recomenda, desde 2017, que não se imponha a expiração regular de palavras-passe. Essa prática leva as pessoas a criar variações previsíveis da mesma palavra-passe. A NIST recomenda forçar uma alteração quando existirem indícios de comprometimento. Uma palavra-passe longa e única, guardada num gestor de palavras-passe, combinada 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 ocorre quando não existe qualquer início de sessão funcional.

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

1. Reinicie o servidor a partir do painel e monitorize a consola.
2. Abra o menu do GRUB. As imagens cloud normalmente definem GRUB_TIMEOUT=0. Por isso, mantenha Shift premida 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 mount -o remount,rw / primeiro. O modo de recuperação monta o sistema de ficheiros root como apenas de leitura. Sem este passo, passwd falha com passwd: Authentication token manipulation error porque não consegue escrever em /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, essa shell de recuperação solicita-a e o procedimento termina aí. Arranque antes 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

Consulte 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 partição EFI pequena, 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 não restar nenhuma sessão, use a consola.

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

Permission denied (publickey). significa que o servidor nunca disponibilizou a autenticação por palavra-passe. PasswordAuthentication no está definido algures e, no Ubuntu 22.04 e posteriores, normalmente encontra-se num ficheiro drop-in 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 uma palavra-passe, porque o método keyboard-interactive utiliza a mesma pilha PAM. Desativar um e manter o outro ativo é a forma de um servidor que parece aceitar apenas chaves continuar a aceitar palavras-passe introduzidas pelo utilizador.

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 por predefinição é 6. 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 bloqueou o seu endereço depois de várias falhas. A regra de bloqueio predefinida rejeita o pacote em vez de o descartar, razão pela qual a recusa surge rapidamente, sem esperar por um timeout. A partir da consola, sudo fail2ban-client status sshd apresenta 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; as chaves são o objetivo final

Uma senha que funciona por SSH é uma senha que qualquer scanner na Internet pode tentar adivinhar. Passe para a autenticação baseada em chaves; assim, as tentativas 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 numa VPS explica as restantes definições do sshd que vale a pena alterar, e os primeiros dez minutos numa VPS nova apresenta a ordem em que deve aplicá-las num servidor novo.

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, que pede um nome de utilizador e uma senha. Uma conta com uma senha forte que tenha guardado é o que distingue 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 como um utilizador que possa executar sudo e execute sudo passwd root. Isso define uma nova palavra-passe sem pedir a antiga, porque sudo já efetuou a sua autenticação. Se nenhuma conta no sistema puder executar sudo, abra a consola do fornecedor, 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 palavra-passe e foi essa que perdeu, o shell de recuperação irá pedi-la. 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 de Current password:. A linha passwd: password unchanged apresentada abaixo confirma que nada foi escrito. A outra causa é um sistema de ficheiros que não pode ser escrito. É isso que acontece no modo de recuperação, porque / está montado como somente de leitura. Execute mount -o remount,rw / e tente novamente.

Alterar a minha palavra-passe do Linux também altera a 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 de 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 interrompe as minhas chaves SSH ou as 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 alterar a palavra-passe, depois de passwd -l e depois de chage -d 0. As sessões já abertas continuam ativas, porque o SSH verifica as credenciais apenas no início da sessão. A única alteração dentro de uma sessão ativa ocorre em sudo, que pede a nova palavra-passe quando o respetivo 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. Ambos fazem a mesma coisa. A data da última alteração armazenada passa para a epoch. O PAM considera a palavra-passe expirada, e o próximo início de sessão interativo tem de definir uma nova palavra-passe antes de iniciar um 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.