Como configurar chaves SSH no Ubuntu: guia prático

Digitar uma senha a cada conexão remota é uma rotina conhecida por quem começa a administrar servidores. Mas você pode configurar chaves SSH no Ubuntu e organizar esse acesso com mais clareza: uma chave pública autorizada no servidor e uma chave privada protegida no seu computador. O processo fica mais simples quando você entende qual arquivo pertence a cada lado e como testar o resultado.

Este guia acompanha um laboratório em rede privada com um computador cliente e um servidor Ubuntu. Você precisa administrar o servidor, conhecer seu endereço e ter uma conta de acesso válida. Não vamos alterar o acesso de um servidor de produção nem desativar a autenticação por senha durante o exercício. Primeiro, vamos construir uma conexão verificável e um procedimento de recuperação.

A chave não transforma qualquer conexão em uma situação automaticamente segura. Você ainda precisa confirmar a identidade do servidor, manter o sistema atualizado, proteger a chave privada e retirar autorizações antigas. O objetivo é terminar sabendo gerar a chave, instalar a parte pública, selecionar a identidade e investigar os erros mais comuns, sem confundir mensagens de rede com falhas de autenticação.

Entenda cliente, servidor e usuário remoto

O cliente inicia a conexão. O servidor recebe essa conexão por meio de um serviço SSH. O usuário remoto define a conta em que os comandos serão executados. Uma pessoa pode usar Ubuntu nos dois lados, mas as tarefas continuam diferentes. Gerar a chave acontece no cliente; autorizar a chave pública acontece na conta de destino do servidor.

Desenhe essa relação em uma anotação simples: qual máquina você está usando agora, qual máquina quer acessar, qual endereço alcança o destino e qual conta será utilizada. Isso evita instalar o serviço no computador errado ou copiar a chave para uma conta que não participa do acesso. Em ambientes profissionais, confirme também a autorização e o procedimento adotado pelo time.

Se a rede ainda não está funcionando, consulte nosso conteúdo sobre configuração de rede no Ubuntu. Ele complementa o contexto, mas as ferramentas de rede podem variar entre versões e instalações. Para uma visão de servidor, há também o artigo sobre Ubuntu Server e redes, voltado à versão apresentada naquele material.

Prepare o serviço no servidor Ubuntu

No servidor de laboratório, instale o OpenSSH Server pelos repositórios configurados. Leia o resumo do APT antes de confirmar a instalação. O cliente precisa de ferramentas de conexão, enquanto o destino precisa do serviço que aceita conexões. Não instale um serviço de acesso remoto em máquinas que não precisam recebê-lo apenas porque o pacote aparece em um tutorial.

sudo apt update
sudo apt install openssh-server
systemctl status ssh.service

O status ajuda a conferir o serviço, mas não é sozinho uma prova de conectividade. Dependendo da instalação, a ativação por socket também pode participar do funcionamento. Consulte a documentação oficial do OpenSSH no Ubuntu para os detalhes da sua versão. Neste exercício, mantenha as configurações originais até obter uma conexão funcional e entender o caminho do acesso.

Se houver firewall, permita somente o tráfego necessário da rede de laboratório conforme a política existente. Não desative o firewall inteiro para testar uma hipótese pequena. Em uma máquina virtual, confira se o modo de rede permite alcançar o endereço usado. Porta bloqueada, endereço incorreto e serviço parado podem produzir sintomas parecidos para quem vê apenas a mensagem final do cliente.

Teste uma conexão inicial e confira a identidade do servidor

O comando abaixo usa marcadores. Substitua usuario pelo nome real da conta e servidor.exemplo pelo endereço ou nome do seu servidor. Esse endereço não é um destino público que você deva acessar. Ao conectar pela primeira vez, o cliente pode pedir confirmação da chave de identificação do servidor. Essa chave do host é diferente da chave de usuário que criaremos depois.

ssh usuario@servidor.exemplo

Confirme a impressão digital por um canal confiável, como o console da máquina ou a informação fornecida pelo administrador. No console do servidor, se a chave de host Ed25519 estiver presente, o comando seguinte permite consultar sua impressão digital. Não considere a própria mensagem da conexão suficiente para provar a identidade: um endereço digitado incorretamente pode levar a outro destino.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Depois de conferir o host e autenticar, execute um comando simples, como whoami, para identificar a conta remota. Saia usando exit. Se essa etapa falhar, resolva a rede, o serviço ou as credenciais iniciais antes de adicionar chaves. Assim, você não mistura problemas de transporte com problemas de autorização, e cada diagnóstico parte de uma etapa que já funcionou.

Gere uma chave de usuário no computador cliente

Escolha um nome específico para a identidade de laboratório. Ele ajuda a distinguir a chave usada nesse exercício de outras chaves pessoais ou profissionais. Confira se o arquivo não existe antes de gerar, para não substituir uma identidade em uso. A ferramenta pode avisar sobre sobrescrita; leia o aviso e não confirme automaticamente. Uma chave privada substituída pode impedir acessos que dependiam dela.

mkdir -p "$HOME/.ssh"
chmod 700 "$HOME/.ssh"
ssh-keygen -t ed25519 -f "$HOME/.ssh/id_ed25519_lab" -C "laboratorio-ubuntu"

Quando solicitado, informe uma frase secreta forte para proteger a chave privada. Ela será pedida ao usar a identidade, a menos que um agente a mantenha disponível na sessão. O comentário serve para identificação e não substitui um inventário de acesso. O manual oficial do ssh-keygen detalha as opções e os formatos suportados pela ferramenta.

Você terá dois arquivos. id_ed25519_lab é a chave privada: mantenha-a no cliente e protegida. id_ed25519_lab.pub é a chave pública: ela pode ser autorizada no servidor. Não envie a chave privada por mensagem nem cole seu conteúdo em um formulário de suporte. Para compartilhar a autorização, use a parte pública, e confirme para qual conta ela está sendo cadastrada.

Autorize a chave pública na conta correta

Uma forma prática é usar ssh-copy-id, quando a ferramenta está disponível e você tem um método inicial de autenticação aceito pelo servidor. A opção -i informa o arquivo público específico. Isso evita depender de uma seleção automática de chaves que você talvez não conheça. Substitua novamente os marcadores pela conta e pelo destino do laboratório.

ssh-copy-id -i "$HOME/.ssh/id_ed25519_lab.pub" usuario@servidor.exemplo

Esse processo autoriza a chave pública na conta remota. Se o ambiente usa uma política diferente para distribuição de chaves, siga esse procedimento em vez de modificar arquivos por conta própria. Em servidores gerenciados, configurações podem ser reconstruídas automaticamente. Uma alteração manual pode desaparecer ou contrariar o controle de acesso definido pelo administrador.

Na configuração comum, a conta usa um arquivo authorized_keys dentro de .ssh. Se você precisar conferir permissões no servidor de laboratório, faça isso autenticado como a conta correta. O diretório e o arquivo devem pertencer ao usuário esperado e ter acesso restrito. Os comandos abaixo pressupõem que o arquivo existe e que essa localização é a utilizada pela configuração do serviço.

chmod 700 "$HOME/.ssh"
chmod 600 "$HOME/.ssh/authorized_keys"
ls -ld "$HOME/.ssh"
ls -l "$HOME/.ssh/authorized_keys"

Teste a identidade de forma explícita

Abra uma segunda sessão no cliente e selecione a chave privada com -i. Use IdentitiesOnly para limitar as identidades oferecidas conforme a configuração selecionada, reduzindo confusão com muitas chaves disponíveis no agente. Para verificar que o teste utiliza chave pública, o exemplo restringe os métodos de autenticação. A frase secreta local da chave ainda pode ser solicitada.

ssh -i "$HOME/.ssh/id_ed25519_lab" \
  -o IdentitiesOnly=yes \
  -o PreferredAuthentications=publickey \
  -o PasswordAuthentication=no \
  -o KbdInteractiveAuthentication=no \
  usuario@servidor.exemplo

Quando a sessão abrir, confira a conta com whoami e o computador com hostname. A frase secreta da chave não é a senha da conta remota. Essa diferença importa: uma pessoa pode acreditar que o servidor ainda está pedindo a senha, quando o cliente está apenas desbloqueando a chave privada. Leia o texto do pedido antes de decidir qual credencial informar.

Mantenha a sessão inicial aberta enquanto realiza o teste em outra janela. Esse hábito oferece uma referência funcional durante mudanças de acesso. Para o laboratório, não precisamos editar sshd_config nem desligar métodos de autenticação. Quando houver uma necessidade real de alterar a política do servidor, faça um procedimento separado com validação, acesso ao console e plano de recuperação.

Use um alias para reduzir erros de digitação

Depois de confirmar a conexão, você pode criar uma entrada no arquivo de configuração do cliente. Abra ~/.ssh/config pelo editor e adicione uma configuração como a seguinte, adaptando os valores. Preserve entradas existentes e evite repetir um alias já utilizado. O objetivo é registrar escolhas que antes precisavam ser digitadas em toda conexão.

Host ubuntu-lab
    HostName servidor.exemplo
    User usuario
    IdentityFile ~/.ssh/id_ed25519_lab
    IdentitiesOnly yes

Restrinja o arquivo a sua conta com chmod 600 ~/.ssh/config. Então use ssh ubuntu-lab. O alias é um nome local; não altera o nome do servidor na rede. Se precisar conferir a configuração resolvida, ssh -G ubuntu-lab mostra parâmetros sem iniciar a conexão. Revise os campos importantes antes de depender do alias em uma automação.

Evite compartilhar seu arquivo inteiro se ele contiver nomes de ambientes internos ou outras informações operacionais. Para pedir ajuda, recorte a entrada relevante e substitua dados sensíveis por marcadores consistentes. O manual oficial do cliente ssh explica opções de conexão, configuração e diagnóstico. Consulte também o manual instalado no seu sistema para diferenças de versão.

Investigue os erros pela etapa em que acontecem

Connection timed out normalmente indica que a conexão não foi concluída no prazo, e pode envolver rota, firewall ou destino inacessível. Connection refused indica uma recusa no destino ou no caminho, e pode ocorrer quando não há serviço ouvindo na porta esperada. Essas mensagens não apontam diretamente para uma chave inválida. Primeiro, confirme endereço, porta e disponibilidade do serviço.

Permission denied aparece quando a autenticação não foi aceita. Confira o usuário remoto, a chave selecionada, a presença da parte pública e as permissões esperadas. Uma chave corretamente instalada para a conta ana não autoriza automaticamente a conta bruno. Se muitas identidades forem oferecidas, selecione explicitamente a desejada para tornar a investigação mais objetiva.

Use ssh -v ubuntu-lab para obter diagnóstico adicional e revise a saída antes de compartilhá-la. Ela pode expor nomes, caminhos e informações de infraestrutura. No servidor, os registros do serviço ajudam a entender recusas de autenticação; sua localização depende da configuração de logs. Compare os horários do cliente e do servidor para investigar a mesma tentativa, em vez de misturar eventos diferentes.

Uma mudança na chave do host pede verificação

Se o cliente avisar que a identificação do servidor mudou, não apague o registro antigo apenas para eliminar a mensagem. Uma reinstalação pode explicar a mudança, mas também é possível que você esteja alcançando outro equipamento. Confirme o destino e a nova impressão digital por um canal confiável. Somente depois atualize o registro que o cliente usa para reconhecer o host.

Esse cuidado não é burocracia: é parte da finalidade do mecanismo de identificação. A autenticação da sua conta e a identificação do destino protegem relações diferentes. Se você só verificar que possui uma chave válida, ainda pode tentar usá-la no destino errado. Para ambientes reconstruídos com frequência, documente como confirmar a identidade após uma reinstalação.

Planeje retirada de acesso e recuperação

Uma chave pública autorizada deve ter um responsável e uma finalidade conhecidos. Ao encerrar o laboratório ou trocar de equipamento, retire a autorização que não precisa mais existir. Não presuma que excluir a chave do seu computador a remove do servidor. A autorização permanece na conta remota até que seja revogada pelo procedimento apropriado àquela instalação.

Se a chave privada for comprometida, trate a identidade como comprometida e retire suas autorizações. Uma frase secreta ajuda a proteger o arquivo, mas não é justificativa para manter uma chave exposta em uso indefinidamente. Guarde cópias de recuperação somente em local seguro e de acordo com a política do ambiente. Documente também quem consegue acessar o console quando o acesso remoto falha.

Não copie uma identidade pessoal para todos os servidores apenas para facilitar tarefas automáticas. A automação deve ter permissões e responsabilidade definidas. Em um laboratório simples, comece por acesso interativo e testes explícitos. Quando a rotina crescer, avalie gestão centralizada de acesso, duração das autorizações e mecanismos adequados ao contexto, em vez de acumular chaves sem inventário.

Exercício: explique seu próprio acesso

Escreva um README com cinco informações: qual máquina é cliente, qual é servidor, qual conta remota é usada, onde está a chave privada e como a chave pública foi autorizada. Acrescente o comando de teste e a forma de confirmar a impressão digital do host. Não inclua senhas ou o conteúdo da chave privada nesse documento.

Depois, feche a conexão e repita o acesso em um novo terminal. Confira que o alias seleciona a conta certa. Execute um comando simples, saia e descreva a diferença entre um problema de rede e uma recusa de autenticação. Esse exercício vale mais do que decorar um comando longo, porque mostra que você consegue localizar cada responsabilidade quando aparecer uma falha.

Perguntas frequentes sobre chaves SSH no Ubuntu

A chave pública precisa ficar secreta?

Ela é a parte destinada a autorizar o acesso no servidor. A chave privada é que precisa ser protegida. Mesmo a chave pública pode conter um comentário com informações pessoais, então revise o que compartilha. Não confunda o arquivo terminado em .pub com o arquivo privado de mesmo nome. Essa distinção evita um dos erros mais graves para quem começa.

Posso conectar sem ativar um agente SSH?

Sim, você pode selecionar diretamente a identidade com -i e informar sua frase secreta quando necessário. Um agente pode facilitar o uso durante a sessão, mas não é uma exigência para o primeiro acesso. Introduza esse recurso quando entender como ele participa da autenticação e quais identidades estão disponíveis, sem transformar conveniência em confusão sobre a chave selecionada.

Este guia desativa o acesso por senha?

O teste do cliente restringe os métodos usados naquela tentativa; ele não muda a política do servidor. Alterar essa política exige verificar outros usuários, procedimentos de recuperação e configuração efetiva do serviço. Para o aprendizado inicial, confirme primeiro a conexão com chave e mantenha um caminho de acesso conhecido. Depois, trate mudanças administrativas como uma etapa própria.

Ao configurar chaves SSH no Ubuntu, seu melhor resultado é um acesso que você consegue explicar, testar e revogar. Gere a identidade no cliente, autorize apenas a parte pública na conta correta, confirme o host e documente o procedimento. Essa base torna o trabalho remoto mais previsível e prepara você para administrar ambientes com responsabilidades claras.