Como alterar a senha root no Ubuntu via SSH

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 são resolvidas em dois minutos enquanto ainda existe uma shell autenticada, mas exigem acesso à consola depois de a última sessão ser fechada.

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 as verifica novamente. A exceção é sudo. Este volta a verificar a palavra-passe através do PAM (módulos de autenticação conectáveis) quando as credenciais em cache expiram, após 15 minutos por predefinição no Ubuntu. Esse período não é contado a partir do último prompt, porque sudo -v atualiza as credenciais em cache sem pedir a palavra-passe novamente. Por isso, a nova palavra-passe é realmente testada 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

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 próprio utilizador não poderia definir.

Bloquear a palavra-passe é uma ação separada. sudo passwd -l deploy coloca um ! antes 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 esse utilizador de iniciar sessão. Qualquer chave no respetivo ~/.ssh/authorized_keys continua a funcionar, porque a autenticação por chave pública não verifica o hash da palavra-passe. 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. Assim, 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.

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.

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

passwd lê a partir do terminal e não pode ser executado 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 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 e, em seguida, imprime um hash crypt SHA-512 que começa por $6$. -e informa chpasswd de que o segundo campo já contém um hash, que é copiado para /etc/shadow sem alterações. O hash pode ser armazenado com segurança num repositório ou numa variável do CI, e o texto simples nunca sai da máquina onde o introduziu.

O Ubuntu 24.04 aplica yescrypt ($y$) às novas palavras-passe quando passwd as define, enquanto openssl passwd -6 utiliza SHA-512. Ambos são verificados no início de sessão, porque a libxcrypt lê os dois formatos. É possível misturá-los, e openssl passwd -6 funciona da mesma forma em todas as versões Ubuntu LTS desde a 18.04, o que não acontece com chpasswd -c YESCRYPT: o pacote shadow mais antigo do 20.04 não reconhece esse nome de método. O Ubuntu 16.04 é a exceção, porque o OpenSSL 1.0.2 incluído nessa versão não tem a opção -6. Esses hashes também permanecem válidos depois de uma atualização de versão, por isso atualizar um servidor 24.04 para a versão 26.04 não obriga a repor 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 considere a palavra-passe 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 para contas que iniciam sessão interativamente com uma palavra-passe. Uma palavra-passe expirada também afeta os inícios de sessão com chave, porque o sshd executa a etapa de conta do PAM mesmo quando a autenticação foi feita com uma chave. Um ssh deploy@203.0.113.10 'systemctl restart app' executado por um script falha desta forma antes de o comando ser executado:

Password change required but no TTY available.

O comando remoto nunca é executado e ssh termina com um código diferente de zero. Se o script chamador não parar perante erros, com set -e ou com uma verificação explícita, as linhas seguintes continuam a ser executadas e a tarefa pode terminar como se o reinício tivesse ocorrido.

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 não restar 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 na consola diferente do que usou quando definiu a palavra-passe.

Permission denied (publickey). significa que o servidor nunca ofereceu autenticação por palavra-passe, pelo que o valor efetivo é PasswordAuthentication no. Esse no pode estar no ficheiro principal ou num drop-in, por isso verifique ambos. O sshd lê os ficheiros em /etc/ssh/sshd_config.d/ no início da configuração e mantém o primeiro valor que encontra para cada palavra-chave, pelo que um drop-in substitui /etc/ssh/sshd_config. A mesma regra aplica-se frequentemente no sentido inverso em servidores Ubuntu 24.04 instalados a partir da ISO com o SSH ativado: o instalador deixa um drop-in do cloud-init, 50-cloud-init.conf, que define PasswordAuthentication yes, e um no adicionado ao ficheiro principal é ignorado. 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 executa 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.

Essa mesma linha também é apresentada numa mensagem de rejeição de login com chave. Por isso, se estava a oferecer uma chave em vez de uma palavra-passe, a configuração de palavras-passe do servidor é apenas uma das cinco causas de Permission denied (publickey), e o resultado de ssh -v indica qual delas está presente.

Too many authentication failures numa mensagem de desconexão significa que a ligação atingiu o limite de MaxAuthTries tentativas do servidor, que é de 6 por predefinição. A causa mais comum é um cliente que ofereceu várias chaves antes de chegar à palavra-passe. 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 a monitorizar o SSH 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 chega 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 endereço da lista.

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 como um utilizador que possa executar sudo e execute sudo passwd root. Isto define uma nova palavra-passe sem pedir a antiga, porque sudo já fez a sua autenticação. Se nenhuma conta no servidor puder executar sudo, abra a consola do fornecedor, reinicie para o 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 pede-a. Nesse caso, a alternativa é usar a imagem de rescue do fornecedor, montar o disco e executar chroot.

Por que motivo passwd apresenta "Authentication token manipulation error"?

Há duas causas para essa mensagem. A mais comum é uma resposta incorreta ao prompt 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 apenas para 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. Faz a sua autenticação através do PAM, usando a mesma entrada /etc/shadow que SSH e su utilizam. Por isso, existe uma palavra-passe por conta. É também por esse motivo que o primeiro prompt de sudo depois da alteração é o teste real. Execute sudo -k && sudo -v para forçar esse prompt enquanto ainda tem uma sessão funcional.

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

Uma alteração da palavra-passe ou passwd -l não interrompe essas sessões. A autenticação por chave pública não verifica o hash da palavra-passe. Por isso, as chaves continuam a funcionar depois de qualquer uma das operações. chage -d 0 é diferente: sshd continua a executar as verificações de conta do PAM depois de um início de sessão com chave. Essas verificações leem os campos de expiração da palavra-passe em /etc/shadow. Assim, uma palavra-passe expirada faz com que um início de sessão com chave peça uma nova palavra-passe e faz com que os comandos SSH executados por scripts falhem. As sessões já abertas continuam abertas, porque o SSH verifica as credenciais apenas no início da sessão. A única alteração numa sessão ativa ocorre em sudo, que pede a nova palavra-passe quando o carimbo temporal 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 tem o mesmo efeito. A data da última alteração armazenada passa para a epoch. O PAM trata a palavra-passe como 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 utilizada 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.