SSH sem passwords repetidas: do Windows ao Linux com chaves

A password outra vez?

Quando usamos um servidor Linux com frequência, abrir uma ligação SSH torna-se um gesto habitual: abrir o terminal, indicar o utilizador e o endereço do servidor, introduzir a password e começar a trabalhar.

Funciona. Mas repetir a mesma sequência várias vezes por dia é uma boa razão para melhorar o processo.

Em agosto de 2026, configurei o acesso por chaves ao meu HomeLab a partir do Windows. O cliente era o OpenSSH, usado no PowerShell, e o servidor corria Ubuntu. O objetivo era simplificar as ligações sem abdicar da autenticação.

Neste artigo vamos seguir esse cenário, com o utilizador dgarcia, o endereço 192.168.1.75 e o nome homelab. São os dados da configuração de referência: quem seguir o tutorial deve substituí-los pelos do seu ambiente.

Há uma distinção que convém fazer logo: deixar de escrever a password do servidor não significa deixar a chave privada desprotegida. Podemos usar uma passphrase e um agente de autenticação para combinar proteção com comodidade.

O que precisamos antes de começar

O SSH, de Secure Shell, permite abrir uma sessão de terminal remoto através de uma ligação cifrada. No nosso caso, o Windows inicia a ligação e o Ubuntu recebe-a.

No Windows, precisamos do cliente OpenSSH, que inclui os comandos ssh, ssh-keygen e ssh-add. Podemos confirmar que o cliente responde no PowerShell:

ssh -V

Se o comando não existir, consultar a instalação oficial do OpenSSH no Windows. Para iniciar ligações do Windows ao Ubuntu, basta o componente cliente no Windows.

No Ubuntu, o servidor OpenSSH deve estar instalado, ativo e acessível pela rede, com uma conta à qual já conseguimos aceder. Vamos assumir a porta predefinida, 22, e uma configuração que permite autenticação por chave pública. A documentação do Ubuntu explica a preparação do servidor.

Este tutorial parte de uma ligação SSH já disponível na rede local. Não exige publicar a porta SSH na Internet. Se nem conseguimos comunicar com o servidor, precisamos de resolver primeiro a conectividade; o artigo sobre diagnosticar uma ligação Wi-Fi sem Internet ajuda a compreender parte desse percurso.

1. Fazer a primeira ligação e confirmar o servidor

No PowerShell do Windows:

ssh dgarcia@192.168.1.75

ssh inicia o cliente, dgarcia é o utilizador no Ubuntu e o endereço depois de @ identifica o servidor.

Na primeira ligação, é habitual surgir um pedido para confirmar a identidade do servidor, acompanhado por uma fingerprint: um resumo identificador da sua chave pública.

Antes de aceitar, comparar essa fingerprint com a obtida por um canal de confiança, como a consola local do Ubuntu ou a consola de gestão do servidor. Para consultar a fingerprint da chave de servidor Ed25519, nessa consola:

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

É necessário comparar a mesma chave e o mesmo algoritmo que aparecem no aviso. Se a ligação apresentar uma chave RSA ou ECDSA, deve ser consultado o ficheiro público correspondente.

Só depois de confirmar a correspondência devemos aceitar. O cliente guarda essa identidade em known_hosts, para a reconhecer nas ligações seguintes. Se mais tarde surgir um aviso de identidade alterada, devemos investigar antes de o contornar. O manual de ssh explica esta verificação.

O servidor pode então pedir a password da conta dgarcia. Ao escrevê-la, o terminal pode não apresentar caracteres nem asteriscos; isso é normal.

Depois de entrar, manter esta sessão aberta. Vamos utilizá-la para preparar o Ubuntu, enquanto executamos outros passos num segundo terminal do Windows.

2. Criar o par de chaves no Windows

Num segundo PowerShell, ainda no Windows, executar:

ssh-keygen -t ed25519

O comando cria um par de chaves com o algoritmo Ed25519. Quando perguntar onde guardar, o caminho habitual é a pasta .ssh do utilizador Windows.

Se já existir uma chave nesse caminho, não a substituir sem saber onde é utilizada. Podemos reutilizar um par adequado ou escolher outro nome para o novo. Nesse caso, precisamos de ajustar os caminhos nos exemplos seguintes.

Aceitando o nome habitual, obtemos:

Ficheiro no Windows	Função
C:\Users\<utilizador>\.ssh\id_ed25519	Chave privada: deve permanecer protegida no cliente.
C:\Users\<utilizador>\.ssh\id_ed25519.pub	Chave pública: será autorizada no servidor.

Os ficheiros são matematicamente relacionados. Durante a autenticação, o cliente demonstra que consegue usar a chave privada correspondente à chave pública autorizada, através de uma assinatura digital, como descreve o protocolo de autenticação SSH. A chave privada não precisa de ser enviada para o Ubuntu.

O ssh-keygen pede também uma passphrase, uma frase ou palavra-passe que protege o ficheiro da chave privada. Recomendo defini-la: se alguém copiar o ficheiro, esta proteção acrescenta uma barreira ao seu uso.

A passphrase é local e não tem de coincidir com a password da conta Linux. Se a perdermos, não existe um botão para a recuperar; precisamos de outro acesso para autorizar um novo par. O manual de ssh-keygen descreve a geração e proteção das chaves.

3. Preparar as permissões no Ubuntu

Voltar à sessão SSH já aberta no Ubuntu, autenticada como dgarcia, e executar:

umask 077
mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
echo >> ~/.ssh/authorized_keys

Aqui, ~ corresponde à pasta pessoal de dgarcia no Ubuntu. No Windows, a pasta pessoal é outra, apesar de podermos encontrar uma notação semelhante.

Se algum comando apresentar um erro, corrigir a causa antes de continuar para o envio da chave.

mkdir -p cria a pasta se ainda não existir. touch cria authorized_keys se estiver em falta, sem apagar o conteúdo de um ficheiro existente. A última linha garante uma separação antes da chave que vamos acrescentar, mesmo que a última linha existente não termine com uma mudança de linha.

umask 077 restringe as permissões dos ficheiros que forem criados nessa sessão. chmod 700 reserva o acesso à pasta ao seu proprietário; chmod 600 permite ao proprietário ler e escrever o ficheiro, retirando acesso ao grupo e aos restantes utilizadores.

Estamos a preparar os ficheiros do utilizador remoto, pelo que estes comandos não precisam de sudo. Se os ficheiros existentes pertencerem a outra conta, é necessário corrigir essa situação com o administrador, em vez de contornar o problema abrindo as permissões.

O manual de sshd explica as permissões recomendadas e porque o servidor pode rejeitar ficheiros que outros utilizadores consigam alterar. Também é importante que a pasta pessoal não seja gravável por terceiros.

4. Enviar apenas a chave pública

No segundo PowerShell do Windows:

Get-Content -LiteralPath "$env:USERPROFILE\.ssh\id_ed25519.pub" |
    ssh dgarcia@192.168.1.75 'cat >> ~/.ssh/authorized_keys'

Este comando conserva a lógica usada na configuração de referência, onde type lia o ficheiro público. No PowerShell, type é um alias de Get-Content; aqui usamos o nome completo para tornar a operação mais clara.

$env:USERPROFILE identifica a pasta do utilizador Windows. O conteúdo do ficheiro .pub passa pelo operador | para o cliente SSH. Depois de autenticar a ligação, o comando remoto cat recebe esse conteúdo e acrescenta-o ao authorized_keys de dgarcia.

O operador >> acrescenta. Usar apenas > substituiria o ficheiro e poderia remover outras chaves autorizadas.

Nesta etapa, o servidor ainda pode pedir a password da conta. É precisamente essa ligação já autorizada que permite instalar a nova chave pública. Executar a cópia uma vez; repeti-la pode criar entradas duplicadas.

No Ubuntu, confirmar as permissões e listar as fingerprints das chaves autorizadas:

ls -ld ~/.ssh
ls -l ~/.ssh/authorized_keys
ssh-keygen -lf ~/.ssh/authorized_keys

Esperamos permissões drwx------ na pasta e -rw------- no ficheiro, com dgarcia como proprietário. Para comparar a fingerprint da chave pública local, no Windows:

ssh-keygen -lf "$env:USERPROFILE\.ssh\id_ed25519.pub"

Deve existir uma fingerprint correspondente no ficheiro remoto. Nunca copiar o ficheiro sem .pub para esta lista. Cada entrada autoriza uma chave pública, conforme o formato de authorized_keys.

5. Confirmar que a chave é realmente utilizada

Voltar a abrir uma ligação comum é útil, mas pode esconder um detalhe: se a chave falhar, o cliente pode tentar outro método e acabar por entrar com a password.

Para testar especificamente a autenticação por chave, no Windows:

ssh -v -i "$env:USERPROFILE\.ssh\id_ed25519" -o IdentitiesOnly=yes -o PreferredAuthentications=publickey dgarcia@192.168.1.75

-i indica o ficheiro da chave, IdentitiesOnly=yes limita as identidades às configuradas e PreferredAuthentications=publickey restringe os métodos tentados à autenticação por chave pública. O -v mostra informação de diagnóstico, incluindo o método com que a ligação foi autenticada.

Este teste não deve recorrer à password da conta Linux. Pode continuar a pedir a passphrase da chave privada, o que é esperado antes de a disponibilizarmos através do agente.

Se o servidor exigir vários fatores, uma chave isolada poderá não ser suficiente: o teste pressupõe a configuração simples descrita no início. As opções estão documentadas em ssh_config.

Se falhar, confirmar o utilizador, a chave enviada, a propriedade e as permissões dos ficheiros. Mensagens como Permission denied (publickey) apontam para a autenticação; uma ligação que nem chega ao servidor exige investigar o serviço, a rede ou a porta.

6. Usar ssh-agent sem retirar a passphrase

O ssh-agent permite disponibilizar a chave ao cliente para operações de autenticação, reduzindo a necessidade de voltar a introduzir a passphrase. É um componente do computador cliente, não uma chave que temos de copiar para o servidor.

No Windows, abrir um PowerShell como administrador e configurar o serviço:

Set-Service -Name ssh-agent -StartupType Automatic
Start-Service ssh-agent
Get-Service ssh-agent

O estado esperado é Running. Fechar essa janela e, num PowerShell normal da conta Windows que vai usar SSH, carregar a chave:

ssh-add "$env:USERPROFILE\.ssh\id_ed25519"
ssh-add -l

O primeiro comando pode pedir a passphrase. O segundo lista as fingerprints das identidades disponíveis no agente. Se indicar que não existem identidades, precisamos de carregar a chave.

A Microsoft documenta a configuração de ssh-agent no Windows; o manual de ssh-add explica o carregamento e a listagem.

Enquanto a chave estiver disponível no agente e a configuração permitir usá-la, o cliente pode autenticar sem voltar a pedir a passphrase. Isso não elimina a necessidade de proteger a sessão Windows, bloquear o computador e manter cópias de segurança protegidas da chave.

Não precisamos de ativar encaminhamento do agente para o Ubuntu para este cenário. O manual de ssh-agent distingue o agente local desse encaminhamento.

7. Trocar o endereço por um nome curto

No Windows, editar o ficheiro C:\Users\<utilizador>\.ssh\config, cuja localização é descrita na documentação da Microsoft sobre configuração OpenSSH. Se já existir, acrescentar o bloco sem apagar as restantes entradas; guardar com o nome config, sem .txt:

Host homelab
    HostName 192.168.1.75
    User dgarcia
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host define o alias local, HostName indica o endereço real, User guarda o utilizador remoto e IdentityFile seleciona a chave privada no cliente. IdentitiesOnly ajuda a evitar que o agente ofereça outras identidades desnecessariamente.

Agora, no PowerShell:

ssh homelab

O alias não altera o nome do Ubuntu nem cria um registo DNS. É uma entrada de configuração lida pelo cliente SSH. Se o IP do servidor mudar, é necessário atualizar HostName ou usar um nome que a rede consiga resolver.

Se o ficheiro tiver um bloco geral Host *, colocar a entrada específica antes dele: para muitas opções, o cliente utiliza o primeiro valor encontrado.

Também podemos reutilizar esta entrada no VS Code Remote-SSH, selecionando homelab no comando Remote-SSH: Connect to Host…, desde que a extensão utilize este mesmo ficheiro de configuração. A documentação do VS Code explica como escolher e gerir os hosts.

E se perder o computador ou quiser retirar o acesso?

Num outro acesso de confiança ao Ubuntu, identificar a chave pela fingerprint e remover apenas a respetiva linha de ~/.ssh/authorized_keys, com um editor de texto. Evitar apagar o ficheiro inteiro: pode conter acessos de outros computadores.

Uma boa prática é usar pares diferentes em computadores diferentes. Assim, podemos retirar a autorização de um dispositivo sem substituir todas as outras chaves.

Remover uma chave desta lista impede novas autenticações através dessa entrada, mas não termina sessões que já estejam abertas. Se suspeitarmos de comprometimento, é necessário também avaliar sessões existentes e outros acessos possíveis.

No Windows, remover uma identidade do agente também não apaga a autorização no servidor. São operações diferentes: uma controla o uso local da chave, a outra controla o acesso à conta remota.

Devemos desativar a autenticação por password?

Pode ser um passo posterior, mas não é necessário para começar a usar chaves. Antes de o considerar, precisamos de ter o acesso por chave testado numa nova sessão, uma cópia de segurança da configuração e uma forma alternativa de recuperação, como a consola local.

No Ubuntu, as definições podem estar em /etc/ssh/sshd_config e em ficheiros incluídos de /etc/ssh/sshd_config.d/. Alterar uma linha sem perceber a configuração efetiva pode não produzir o resultado esperado.

A opção PasswordAuthentication controla um método específico; a autenticação interativa, configurada por KbdInteractiveAuthentication, é distinta e pode participar em mecanismos adicionais. Não devemos desativar opções indiscriminadamente, sobretudo quando existe autenticação multifator. O manual de configuração do servidor descreve estas diferenças.

Depois de uma alteração planeada, validar a configuração no Ubuntu antes de aplicar a mudança ao serviço:

sudo sshd -t

Este comando verifica a configuração e a consistência das chaves de servidor; não prova que o nosso próximo login vai funcionar. A documentação do Ubuntu recomenda essa validação e alerta para o risco de perder o acesso.

Manter uma sessão aberta e confirmar uma nova ligação após aplicar qualquer alteração. Desativar a autenticação SSH por password também não elimina a password da conta nem os pedidos que o sudo possa fazer.

Um comando curto, com as peças certas por trás

No dia a dia, o resultado é simples: abrir o Windows Terminal e escrever ssh homelab.

Por trás desse comando continuam a existir várias verificações: reconhecer o servidor, selecionar a conta, apresentar uma identidade autorizada e demonstrar o acesso à chave privada. O alias evita repetir os dados da ligação; o agente ajuda a utilizar a chave protegida.

É essa combinação que torna o acesso mais cómodo. A password deixou de aparecer em cada ligação, mas a autenticação continua lá — e agora sabemos que ficheiro faz o quê, onde deve ficar e como retirar a autorização quando for necessário.