Como gerenciar chaves SSH no Ubuntu 24.04

Como funcionam as chaves SSH

Uma chave SSH é um par de ficheiros: uma chave privada que permanece no seu dispositivo e uma chave pública que copia para cada servidor onde pretende iniciar sessão. Quando estabelece a ligação, o servidor utiliza a chave pública para enviar um desafio ao qual apenas a chave privada correspondente consegue responder. A chave privada nunca sai do seu dispositivo, por isso nenhum segredo é transmitido pela rede e um servidor comprometido não tem nada de útil para roubar. É por isso que as chaves são melhores do que as palavras-passe. Gerir bem as chaves SSH resume-se a quatro hábitos: uma chave por dispositivo, as permissões de ficheiro exigidas pelo sshd, um ficheiro ~/.ssh/config para deixar de introduzir opções manualmente e saber como remover uma chave no dia em que um portátil desaparece.

Este guia aborda cada hábito no Ubuntu 24.04, embora quase tudo se aplique a qualquer servidor Linux e a qualquer versão recente do OpenSSH.

Antes de começar, é importante esclarecer uma questão de terminologia, porque isso evita erros reais. A chave pública não é secreta. Pode colá-la num ticket, enviá-la por email ou publicá-la, e ninguém conseguirá iniciar sessão com ela. A chave privada é o segredo. Qualquer pessoa que copie esse ficheiro e saiba a respetiva frase-passe, se existir, pode agir como se fosse você perante os seus servidores.

Criar uma chave: ed25519 é a predefinição correta

No seu próprio computador, e não no servidor, execute:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 escolhe o tipo de chave. Ed25519 é a predefinição moderna: as chaves são curtas, rápidas e suportadas por todas as versões do OpenSSH desde 2014. Use ssh-keygen -t rsa -b 4096 apenas quando precisar de comunicar com um dispositivo antigo que não compreenda ed25519. -C "laptop" define um comentário. O comentário não tem qualquer função criptográfica, mas permite reconhecer esta chave no ficheiro authorized_keys de um servidor daqui a dois anos. Por isso, indique o dispositivo onde a chave está armazenada.

ssh-keygen pergunta onde guardar a chave. Aceite o valor predefinido, ~/.ssh/id_ed25519. Em seguida, pede uma frase-passe. Defina uma; a secção abaixo sobre frases-passe explica por que razão isso não lhe acrescenta trabalho no dia a dia. No fim, terá dois ficheiros: ~/.ssh/id_ed25519 é a chave privada e ~/.ssh/id_ed25519.pub é a chave pública. Consulte a parte pública:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

É uma única linha: o tipo de chave, o material criptográfico e o seu comentário. É essa linha que será colocada nos seus servidores.

Uma chave por dispositivo, não uma por servidor

A primeira pergunta costuma ser: preciso de uma chave nova para cada servidor? Não. Crie uma chave para cada dispositivo onde escreve e coloque essa chave pública em todos os servidores a que o dispositivo precisa de aceder. A chave identifica o dispositivo. O ficheiro authorized_keys em cada servidor contém a lista de dispositivos autorizados.

Este modelo escala, e as alternativas falham de formas previsíveis. Uma chave por servidor significa que um portátil com vinte servidores transporta vinte chaves privadas, e acabará por perder o controlo sobre qual corresponde a cada servidor. Uma única chave partilhada por todos os dispositivos é pior: se o portátil for roubado, não pode revogar o acesso do portátil sem também bloquear o computador de secretária, porque ambos têm a mesma chave privada. Terá de substituir a chave em todo o lado e distribuí-la novamente por todos os dispositivos ao mesmo tempo.

Com uma chave por dispositivo, a perda do portátil custa-lhe uma linha por servidor: elimine a linha do portátil de authorized_keys, e todos os outros dispositivos continuam a funcionar. O comentário definido com -C facilita a localização dessa linha.

A regra subjacente ao modelo é simples: uma chave privada é criada num dispositivo e deixa de ser válida com esse dispositivo. Nunca copie uma chave privada para uma segunda máquina e nunca a carregue para um servidor. Quando um novo dispositivo precisar de acesso, gere nele uma chave nova.

Coloque a chave pública no servidor

O caminho mais simples é ssh-copy-id, que é fornecido com o OpenSSH:

ssh-copy-id matt@10.0.0.10

O comando inicia sessão com o método que ainda funcionar, normalmente uma palavra-passe, acrescenta a sua chave pública a ~/.ssh/authorized_keys no servidor e cria o diretório e o ficheiro com as permissões corretas, se ainda não existirem. Teste abrindo uma nova sessão SSH: o servidor deverá permitir o acesso sem pedir a palavra-passe da conta. Se a sua chave tiver uma passphrase, a sua própria máquina poderá pedi-la; esse pedido é local e não corresponde à palavra-passe do servidor.

Quando o início de sessão por palavra-passe já está desativado, ssh-copy-id não consegue aceder ao servidor, pelo que deve adicionar a linha manualmente. Inicie sessão através de uma sessão que ainda funcione ou da consola Web do seu fornecedor e execute o seguinte no servidor:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Cole a sua chave pública real entre as aspas. Use a linha única completa de id_ed25519.pub. authorized_keys contém uma chave pública por linha e constitui toda a base de dados de acesso: adicionar um dispositivo significa acrescentar uma linha, e revogar um dispositivo significa eliminar uma linha. Num servidor novo, este passo deve ser executado em nos primeiros 10 minutos num VPS novo, imediatamente antes de desativar o início de sessão por palavra-passe.

As permissões que impedem o início de sessão com chave

Esta é a forma mais comum de o início de sessão com chave falhar. Do lado do cliente, a falha é silenciosa. O sshd é executado com StrictModes yes por predefinição no Ubuntu 24.04. Isto significa que se recusa a utilizar um ficheiro authorized_keys que outros utilizadores possam editar. Se o ficheiro, o diretório ~/.ssh ou o seu diretório pessoal puderem ser escritos por qualquer pessoa além de si, o sshd ignora a sua chave e passa a pedir uma palavra-passe, sem apresentar explicações no cliente. (O OpenSSH do Ubuntu tolera exatamente um caso restrito: um ficheiro com permissão de escrita para o grupo privado do próprio utilizador, do qual mais ninguém faça parte. Não dependa desse comportamento; mantenha os modos abaixo.) O motivo só aparece no log do servidor:

sudo grep 'Authentication refused' /var/log/auth.log

Numa imagem mínima sem rsyslog, não existe auth.log. A mesma linha fica disponível no journal: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

A correção consiste em alterar duas permissões e verificar a propriedade. Execute estes comandos no servidor, como o utilizador afetado:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

A regra a memorizar é: 700 no diretório .ssh e 600 em tudo o que estiver dentro dele. Os mesmos números aplicam-se ao seu próprio computador, porque o cliente também verifica as permissões. Uma chave privada que possa ser lida por outros utilizadores faz o ssh recusar a chave imediatamente. Neste caso, o erro é explícito:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 corrige o problema.

~/.ssh/config: pare de escrever opções

O ficheiro ~/.ssh/config no seu computador dá um nome curto a cada servidor e guarda as opções que escreve repetidamente. Crie-o com as permissões 600 e adicione um bloco Host por servidor:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Agora ssh web1 substitui ssh -p 22 matt@10.0.0.10, e o mesmo nome curto funciona em scp, rsync e git, porque todos leem este ficheiro. HostName é o endereço real, User evita escrever o nome da conta e IdentityFile fixa a chave que deve ser apresentada.

IdentitiesOnly yes merece uma explicação, porque corrige uma falha confusa. Quando o seu agente tem várias chaves, o cliente apresenta-as uma a uma, e o servidor conta cada apresentação como uma tentativa falhada. Se tiver chaves suficientes carregadas, recebe Received disconnect: Too many authentication failures antes de a chave correta ser sequer testada. IdentitiesOnly yes faz o cliente apresentar apenas a chave indicada em IdentityFile, pelo que a falha não pode ocorrer.

Frases secretas e ssh-agent

Uma frase secreta cifra o ficheiro da chave privada no disco. Sem uma frase secreta, qualquer pessoa que copie o ficheiro pode usá-lo imediatamente; com uma frase secreta, o ficheiro roubado não serve para nada até que a frase seja descoberta. Para uma chave guardada num portátil, esta é exatamente a proteção necessária, porque os portáteis podem ser roubados e as respetivas cópias de segurança podem ser divulgadas.

Na prática, uma frase secreta não tem custo adicional porque ssh-agent. O agente mantém a chave decifrada na memória. Assim, introduz a frase secreta uma vez por sessão de login e todas as ligações seguintes são imediatas. A maioria das distribuições Linux para desktop e o macOS já executam um agente automaticamente. Carregue a chave no agente com:

ssh-add ~/.ssh/id_ed25519

ssh-add -l apresenta as chaves que o agente mantém atualmente. Tenha atenção ao encaminhamento do agente (ssh -A). Esta opção permite que o servidor remoto use o seu agente para autenticar ligações seguintes enquanto estiver ligado. Ative-a apenas para servidores em que confia plenamente e mantenha-a desativada por predefinição.

Rotação e revogação: o procedimento para um portátil perdido

Revogar uma chave SSH simples consiste apenas em remover a respetiva linha de authorized_keys em todos os servidores que a tenham. Não existe uma autoridade de certificação para notificar nem uma data de expiração a aguardar. Assim que a linha é removida, novos logins com essa chave falham.

Execute agora o procedimento, enquanto não é uma emergência. Escolha um servidor, abra ~/.ssh/authorized_keys e encontre a chave pelo comentário. Elimine a linha com um editor ou filtre-a pelo comentário:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

Depois, confirme a partir do dispositivo cuja chave acabou de revogar que o login agora falha e, a partir de outro dispositivo, que o login continua a funcionar. Tenha em atenção um detalhe: remover uma chave não encerra sessões que já estejam abertas, porque a chave só é verificada no login. Se estiver a revogar a chave de um dispositivo roubado, verifique também who no servidor e encerre qualquer sessão que não reconheça.

A rotação é a mesma operação numa ordem diferente: gere uma chave nova no dispositivo, instale-a com ssh-copy-id, confirme que a chave nova permite fazer login e, depois, elimine a linha antiga. Faça isto quando um dispositivo mudar de mãos, quando uma chave possa ter sido exposta ou quando alguém sair de uma equipa. Fazer isto manualmente em dois servidores é aceitável; em vinte servidores, é uma tarefa para automação, e gerir vários servidores Linux mostra como distribuir o mesmo estado authorized_keys por toda a frota.

O que não fazer

• Não partilhe a mesma chave privada entre todos os seus dispositivos. Isso impede revogar um único dispositivo roubado sem substituir a chave em todo o lado.

• Não faça commit de uma chave privada num repositório git, mesmo que seja privado. Os scanners automatizados monitorizam repositórios públicos e tentam usar chaves expostas poucos minutos depois de um push. Além disso, um repositório que se torne público posteriormente expõe todo o seu histórico.

• Não carregue a chave privada do seu portátil para um servidor para permitir que esse servidor aceda a outro servidor. Gere uma chave separada no próprio servidor e autorize essa chave exatamente onde for necessária.

• Não cole uma chave privada numa conversa, num email ou num ticket. A chave pública, o ficheiro .pub, é a única parte que deve ser partilhada.

Depois de a sua chave permitir iniciar sessão de forma fiável, desative a autenticação por palavra-passe. Assim, as tentativas constantes de adivinhar a palavra-passe do servidor não poderão ter sucesso. A configuração drop-in para isso está em Reforço da segurança do SSH num VPS.

FAQ

Como funcionam as chaves SSH sem enviar uma palavra-passe?

O servidor guarda a sua chave pública em ~/.ssh/authorized_keys. No início do login, envia um desafio; o cliente assina o desafio com a chave privada, e o servidor verifica a assinatura com a chave pública. A chave privada nunca sai do seu dispositivo, por isso não há nada para intercetar durante o trânsito nem algo reutilizável para roubar do servidor. Um servidor comprometido divulga apenas chaves públicas, que não podem ser usadas para iniciar sessão em nenhum local.

Devo usar a mesma chave SSH em todos os meus servidores?

Usar uma chave em vários servidores é correto, desde que essa chave permaneça num único dispositivo. A regra é uma chave por dispositivo, não uma chave por servidor: a chave pública do seu portátil deve ser colocada em todos os servidores de que o portátil precisa, e o seu computador de secretária deve ter a sua própria chave. Isto simplifica a revogação, porque perder um dispositivo significa remover uma única linha identificável de cada servidor, enquanto os outros dispositivos continuam a funcionar.

Que permissões deve ter o diretório .ssh e authorized_keys?

Defina 700 em ~/.ssh e 600 em authorized_keys e em todas as chaves privadas, pertencentes à conta que as utiliza. O sshd é executado com StrictModes yes por predefinição, por isso um ficheiro ou diretório pessoal que possa ser escrito por qualquer pessoa além de si faz com que a sua chave seja ignorada silenciosamente. O único registo é Authentication refused: bad ownership or modes no log ou journal de autenticação do servidor.

Como removo uma chave SSH de um servidor?

Elimine a linha da chave de ~/.ssh/authorized_keys na conta para a qual foi autorizada. Encontre a linha correta pelo comentário, que é o rótulo depois do material da chave. Novos logins com essa chave falham imediatamente, mas as sessões que já estão abertas permanecem abertas. Por isso, se o dispositivo tiver sido roubado, termine também qualquer sessão ativa desse dispositivo. Repita o procedimento em todos os servidores para os quais a chave foi copiada.

Preciso de uma frase-passe na minha chave SSH?

Para uma chave num portátil ou computador de secretária, sim. A frase-passe cifra o ficheiro da chave, por isso uma cópia roubada ou divulgada é inútil por si só, e ssh-agent significa que só precisa de a introduzir uma vez por sessão, em vez de a introduzir em cada ligação. As chaves usadas por processos de automação não supervisionados num servidor normalmente não têm frase-passe, porque não há uma pessoa presente para a introduzir. Proteja essas chaves restringindo as ações que a conta de destino pode executar.