Ligar ao servidor por SSH: Windows, macOS e Linux

Um servidor acabado de encomendar chega sem ecrã e sem teclado. O único caminho para dentro passa pelo SSH, o protocolo Secure Shell. Este artigo acompanha a primeira ligação a partir de três sistemas operativos, explica a pergunta sobre a impressão digital (que quase todos os principiantes despacham sem sequer ler) e mostra como transferir ficheiros. No fim vem a parte que a maioria dos guias deixa de fora: o que fazer quando não resulta, e como perceber que resultou mesmo.

Todas as indicações foram verificadas em Debian 13, Debian 12, Ubuntu 24.04 LTS e Ubuntu 22.04 LTS. Onde os quatro divergem, isso está dito de forma expressa. Os comandos no servidor correm como root. No seu próprio computador, pelo contrário, trabalha com uma conta de utilizador normal, e por isso aparece um sudo antes de cada comando que altera o sistema.

O que precisa antes da primeira ligação

Bastam três dados: o endereço IP do servidor, o nome de utilizador e a palavra-passe ou a chave privada. Na KernelHost encontra o IP e as credenciais na área de cliente, assim que o servidor estiver disponível. Num servidor KVM root ou num servidor dedicado acabado de instalar, o utilizador predefinido é, por regra, root.

Como quarto dado entra a porta. A predefinição é 22. Só precisa de um número diferente se a tiver alterado ou se a imagem a tiver mudado de sítio. Guarde já uma armadilha que lhe poupa tempo mais tarde: o ssh escreve a porta em minúscula (-p), o scp escreve-a em maiúscula (-P).

Nos exemplos aparece sempre 203.0.113.10. Este endereço está oficialmente reservado para documentação e não existe. Substitua-o pelo IP do seu servidor.

A primeira ligação no Linux e no macOS

Os dois sistemas já trazem o cliente OpenSSH incluído. No macOS abre o Terminal (na pasta Utilitários), no Linux qualquer janela de terminal. O comando é idêntico em ambos:

ssh root@203.0.113.10

Se o SSH correr noutra porta:

ssh -p 2222 root@203.0.113.10

Se o seu sistema não conhecer o ssh, o que acontece em instalações mínimas ou de contentor muito reduzidas, verifica e instala assim:

ssh -V
sudo apt update
apt-cache policy openssh-client
sudo apt install -y openssh-client

A ordem foi escolhida de propósito. O ssh -V é o comando de verificação e não uma prova de sucesso: se a shell responder bash: ssh: command not found, falta o pacote openssh-client e instala-o a seguir com sudo apt install -y openssh-client. O sudo apt update vem antes de apt-cache policy openssh-client, porque sem as listas de pacotes lidas este comando fica vazio ou indica apenas Installed: (none). E o sudo não é enfeite: sem direitos de administrador, o apt aborta com Could not open lock file /var/lib/apt/lists/lock.

O ssh -V escreve a versão na saída de erro, não na saída padrão. Isso não é um defeito, sempre foi assim. No Debian 13 vê OpenSSH_10.0p2, no Debian 12 OpenSSH_9.2p1, no Ubuntu 24.04 OpenSSH_9.6p1 e no Ubuntu 22.04 OpenSSH_8.9p1. Estes números fazem falta mais à frente, porque o comportamento do scp mudou exatamente entre estas versões.

A impressão digital, e porque não a deve confirmar às cegas

Logo na primeira tentativa de ligação, o SSH pergunta:

The authenticity of host '203.0.113.10 (203.0.113.10)' can't be established.
ED25519 key fingerprint is SHA256:qWU2Zx9mF7hLtHkQ4gRXn0aVbC3sYpJ8dKe1TmNoPU.
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

O que se passa aqui: cada servidor SSH gera na instalação um par de chaves próprio, a chamada host key. A impressão digital é uma soma de verificação curta da parte pública. O seu cliente ainda não conhece este servidor e por isso não consegue garantir que do outro lado está mesmo o seu servidor e não alguém que se meteu pelo meio.

Se escrever yes, a impressão digital fica guardada em ~/.ssh/known_hosts. A partir daí, o seu cliente verifica em silêncio, em cada ligação seguinte, se o servidor apresenta a mesma chave. Esta única pergunta é, portanto, o momento em que todo o modelo de confiança se constrói. Depois disso ninguém volta a perguntar.

Verificá-la a sério só é possível por uma segunda via, independente. Num servidor KVM, a consola na área de cliente serve na perfeição: aí inicia sessão localmente, sem rede nenhuma pelo meio, e manda mostrar a impressão digital.

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

A saída tem este aspeto:

256 SHA256:qWU2Zx9mF7hLtHkQ4gRXn0aVbC3sYpJ8dKe1TmNoPU root@server (ED25519)

Se a parte a seguir a SHA256: coincidir com aquilo que o seu cliente mostra, está tudo em ordem. Se quiser experimentar o formato sem qualquer risco, gere localmente uma chave descartável:

ssh-keygen -t ed25519 -f /tmp/demo -N "" -C demo
ssh-keygen -lf /tmp/demo.pub

Duas notas da prática. Primeira: um servidor tem quase sempre várias host keys (ED25519, ECDSA, RSA). O que aparece é normalmente a chave ED25519, porque os clientes modernos lhe dão preferência. Se comparar por engano com ssh_host_rsa_key.pub, nada bate certo, apesar de estar tudo correto. Segunda: StrictHostKeyChecking=no desliga a verificação por completo e não é uma solução, é desligar a função de segurança. Se precisar de automatização, a escolha certa é -o StrictHostKeyChecking=accept-new: aceita servidores desconhecidos automaticamente, mas continua a avisar quando a chave muda.

Windows: o cliente OpenSSH integrado

Desde o Windows 10 versão 1809 que a Microsoft fornece o mesmo cliente OpenSSH que o Linux e o macOS utilizam. Já não precisa de nenhum programa adicional. Abra o PowerShell, a linha de comandos ou o Windows Terminal e escreva o mesmo comando de cima:

ssh root@203.0.113.10

No Windows 10 e no Windows 11, o cliente é um componente opcional que na maioria das instalações já está ativo. Se não estiver, verifica-o e instala-o numa PowerShell com direitos de administrador:

Get-WindowsCapability -Online -Name OpenSSH.Client*
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Em alternativa, através de Definições, Sistema, Funcionalidades opcionais. Os programas ficam depois em C:\Windows\System32\OpenSSH\, a sua configuração e as host keys conhecidas em %USERPROFILE%\.ssh\, ou seja, tipicamente em C:\Users\Name\.ssh\known_hosts.

A versão do Windows anda atrás da versão do Linux. Em instalações atuais do Windows 11, o ssh -V indica quase sempre OpenSSH_for_Windows_9.5p2. Para o dia a dia chega perfeitamente.

Mesmo assim há uma particularidade: as permissões de ficheiro do Windows. Se guardar uma chave privada que outras contas também possam ler, o SSH recusa o serviço com Permissions for 'C:\Users\Name\.ssh\id_ed25519' are too open. Corrige-se assim:

icacls "$env:USERPROFILE\.ssh\id_ed25519" /inheritance:r /grant:r "$($env:USERNAME):(R)"

Windows: PuTTY

O PuTTY foi durante anos o caminho normal no Windows e para muita gente continua a sê-lo. A versão atual é a 0.84, de maio de 2026. Descarregue-a exclusivamente da página do autor (chiark.greenend.org.uk) e não de portais de download, porque já houve várias vezes versões falsificadas do PuTTY com roubo de palavras-passe incorporado.

O procedimento: em Host Name (or IP address) introduz o IP, em Port o 22, tipo de ligação SSH, depois Open. Se quiser guardar a ligação, escreve antes um nome em Saved Sessions e clica em Save. O nome de utilizador só é pedido pelo PuTTY já dentro da janela, ou pode deixá-lo gravado em Connection, Data, Auto-login username.

No primeiro estabelecimento de ligação aparece a janela PuTTY Security Alert com o aviso de que a host key não está em cache. Mostra a mesma impressão digital SHA256 que o OpenSSH mostra, pelo que pode comparar as duas uma a uma. O Accept guarda a chave de forma permanente, o Connect Once liga apenas desta vez sem guardar, o Cancel cancela.

Diferença importante em relação ao OpenSSH: o PuTTY não tem ficheiro known_hosts. As chaves vão parar ao registo, em HKEY_CURRENT_USER\Software\SimonTatham\PuTTY\SshHostKeys. Quem quiser fazer limpeza aí depois de reinstalar o servidor abre o regedit e apaga a entrada correspondente. E ainda outra armadilha: o PuTTY usa um formato de chave próprio (.ppk). Uma chave OpenSSH tem de ser convertida no PuTTYgen através de Conversions, Import key antes de o PuTTY a conseguir usar.

Transferir ficheiros com scp e sftp

O scp copia ficheiros como o cp, só que através da rede. Enviar um ficheiro:

scp backup.tar.gz root@203.0.113.10:/root/

Descarregar um ficheiro (o ponto no fim significa: para o diretório atual):

scp root@203.0.113.10:/var/log/syslog .

Um diretório inteiro, e com uma porta diferente:

scp -r website root@203.0.113.10:/var/www/
scp -P 2222 backup.tar.gz root@203.0.113.10:/root/

O sftp é a variante interativa e dá jeito quando quer primeiro ver o que está onde:

sftp root@203.0.113.10

A partir daí trabalha com ls, cd, get ficheiro, put ficheiro do lado remoto e com lls, lcd no seu próprio computador. O bye termina a sessão. Os dois programas existem também no Windows, fazem parte da mesma instalação. O PuTTY traz equivalentes próprios com pscp e psftp; quem quiser uma interface gráfica usa o WinSCP.

E aqui está a diferença que faz muita gente tropeçar: desde o OpenSSH 9.0 que o scp já não transfere internamente através do antigo protocolo SCP, mas sim por SFTP. Isso afeta o Debian 13, o Debian 12 e o Ubuntu 24.04. O Ubuntu 22.04, com OpenSSH 8.9, ainda usa o método antigo. Na prática nota-se em dois pontos. Os caracteres universais como *.log num caminho remoto passam a ser interpretados de outra forma, e quando o outro lado não oferece SFTP (por exemplo equipamentos de rede ou um chroot restrito), a transferência aborta com:

subsystem request failed on channel 0
scp: Connection closed

A solução de recurso para isso é o scp -O, que força o protocolo antigo. A solução limpa é ativar no servidor a linha Subsystem sftp /usr/lib/openssh/sftp-server em /etc/ssh/sshd_config. No Debian e no Ubuntu, o pacote necessário openssh-sftp-server é instalado como dependência do openssh-server, por isso só falta em instalações montadas de forma muito peculiar.

O aviso de known_hosts depois de uma reinstalação

Reinstala o servidor, liga-se, e em vez da linha de comandos aparece uma parede de pontos de exclamação:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!      @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
Offending ED25519 key in /home/tom/.ssh/known_hosts:7
Host key for 203.0.113.10 has changed and you have requested strict checking.
Host key verification failed.

Isto não é um erro, é exatamente a função para a qual escreveu yes da primeira vez. Numa reinstalação, o servidor gera host keys novas e a entrada antiga deixa de bater certo. A mesma mensagem aparece, aliás, quando o mesmo endereço IP foi entregue a outro cliente ou quando arrancou uma cópia do servidor.

Antes de apagar a entrada, pense um momento: acabou mesmo de reinstalar? Se sim, remova a linha antiga:

ssh-keygen -R 203.0.113.10

Com uma porta diferente, a entrada vai entre parênteses retos, senão o comando não encontra nada:

ssh-keygen -R "[203.0.113.10]:2222"

Se existe sequer alguma entrada, isso di-lo o ssh-keygen -F 203.0.113.10. Consultar com um editor de texto adianta pouco, porque o Debian e o Ubuntu guardam por predefinição os nomes de host em known_hosts sob a forma de hash. Procurar ali não é possível, e daí os dois comandos acima.

Na tentativa de ligação seguinte, o SSH volta a perguntar pela impressão digital. Esse é o momento para a confrontar outra vez com a consola na área de cliente, em vez de escrever yes por reflexo. É precisamente esta segunda oportunidade o sentido de todo o aviso.

No Windows, o ssh-keygen -R funciona exatamente da mesma maneira na PowerShell. Se usar o PuTTY, apaga em vez disso a entrada do registo ou confirma na janela WARNING - POTENTIAL SECURITY BREACH! com Accept que a nova chave deve ser guardada.

As mensagens de erro à letra, e o que está por trás delas

As mensagens seguintes cobrem, pela experiência, a grande maioria dos casos.

• Connection refused: a ligação até chegou ao servidor, mas na porta não está ninguém à escuta. Ou o serviço SSH não está a correr, ou está à escuta noutra porta. Pela consola verifica com systemctl status ssh e ss -tlnp se a porta 22 está ocupada.
• Connection timed out: não veio resposta nenhuma. Típico de um IP errado, de um servidor desligado ou de uma firewall que descarta os pacotes em vez de os rejeitar. Verifique o endereço IP carácter a carácter e as regras da firewall.
• Permission denied, please try again.: o nome de utilizador ou a palavra-passe não estão certos. A causa mais frequente é um utilizador errado, por exemplo root em vez de ubuntu ou ao contrário.
• Permission denied (publickey).: o servidor não aceita palavras-passe de todo, apenas chaves. Em muitas imagens de cloud isso vem assim de origem. Ou deixa lá a sua chave pública, ou permite temporariamente PasswordAuthentication yes através da consola.
• Too many authentication failures: o seu agente oferece demasiadas chaves seguidas e o servidor corta antes disso. Solução: ssh -o IdentitiesOnly=yes -i ~/.ssh/minha_chave root@203.0.113.10.
• WARNING: UNPROTECTED PRIVATE KEY FILE! juntamente com Permissions 0644 for ... are too open: a chave privada é legível por outros e por isso é ignorada. No Linux e no macOS resolve-se com chmod 600 sobre o ficheiro da chave, no Windows com o comando icacls mais acima.
• Bad owner or permissions on ~/.ssh/config: a mesma causa, só que para o ficheiro de configuração. chmod 600 ~/.ssh/config.
• kex_exchange_identification: read: Connection reset by peer: a ligação foi cortada a meio do aperto de mão. Na prática é quase sempre um bloqueio automático depois de várias tentativas falhadas, por exemplo pelo fail2ban. Espere que o bloqueio expire ou levante-o pela consola com fail2ban-client unban ENDERECO_IP.
• no matching host key type found. Their offer: ssh-rsa: o servidor só oferece chaves RSA assinadas com SHA-1. Desde o OpenSSH 8.8 que essas são recusadas, e isso afeta enquanto cliente os quatro sistemas aqui tratados. A resposta certa é atualizar o servidor antigo, não abrandar as exigências do cliente.
• client_loop: send disconnect: Broken pipe: a sessão adormeceu e foi limpa por uma firewall ou por um router. Escreva em ~/.ssh/config a linha ServerAliveInterval 60 e a ligação mantém-se quente.

Regra de base para qualquer trabalho na configuração do SSH: deixe uma sessão a funcionar aberta enquanto testa. Reiniciar o serviço SSH não expulsa as ligações existentes. Se se trancar cá fora com uma configuração defeituosa, volta a entrar por essa segunda sessão ou pela consola na área de cliente.

Diferenças entre Debian 13, Debian 12, Ubuntu 24.04 e 22.04

Para o simples estabelecimento da ligação, os quatro comportam-se da mesma forma. Assim que altera alguma coisa no servidor, começam a divergir.

Ativação por socket em vez de serviço permanente

Desde a 22.10 que o Ubuntu já não arranca o serviço SSH de forma permanente, mas apenas na primeira ligação recebida. O responsável por isso é o ssh.socket, não o ssh.service. Isto vale para o Ubuntu 24.04 e, em sistemas acabados de instalar, também para o Debian 13. O Debian 12 ainda usa o clássico serviço permanente.

Duas consequências. Primeira: um Port 2222 em /etc/ssh/sshd_config não muda ali absolutamente nada, porque quem escuta na porta já não é o sshd, mas sim o systemd. A porta pertence então a um ficheiro complementar, que cria com systemctl edit ssh.socket, com ListenStream= para repor a predefinição e uma segunda linha ListenStream=2222. Segunda: o systemctl reload ssh pode abortar em sistemas Debian 13 acabados de instalar com fatal: Cannot bind any address. Nesse caso use systemctl restart ssh.service ou desligue por completo a ativação por socket com systemctl disable --now ssh.socket.

Algoritmos e heranças antigas

O Debian 13 traz o OpenSSH 10.0 e já não conhece de todo as chaves DSA, nem sequer através de opções de compatibilidade. Quem ainda tenha uma chave muito antiga em uso deve gerar uma nova antes. Clientes muito recentes (macOS 26.3 e superior, com OpenSSH 10.1 ou mais recente) mostram além disso um aviso quando o servidor não oferece troca de chaves resistente a computação quântica:

** WARNING: connection is not using a post-quantum key exchange algorithm.
** This session may be vulnerable to "store now, decrypt later" attacks.

Isto é um aviso, não um erro, e a ligação estabelece-se à mesma. Desaparece assim que o servidor for suficientemente recente. O Debian 12 e o Ubuntu 24.04 cumprem o requisito, o Ubuntu 22.04 com OpenSSH 8.9 na configuração predefinida não.

Uma palavra sobre versões mais antigas

O Debian 10 está sem suporte desde junho de 2024, o Ubuntu 20.04 desde maio de 2025. Nenhum dos dois recebe já atualizações de segurança para o OpenSSH. Um servidor acessível pela Internet através de SSH não deve continuar assente em nenhum deles.

Escrever menos com o ~/.ssh/config

Assim que tratar de mais do que um servidor, o ficheiro de configuração compensa. Crie-o e defina as permissões, senão o SSH recusa-o:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
touch ~/.ssh/config
chmod 600 ~/.ssh/config

Uma entrada lá dentro tem este aspeto:

Host web1
    HostName 203.0.113.10
    User root
    Port 2222
    ServerAliveInterval 60

A partir daí basta ssh web1, e também scp ficheiro web1:/root/ funciona assim. O cliente do Windows percebe o mesmo ficheiro, que ali fica em %USERPROFILE%\.ssh\config.

Não precisa de adivinhar se o seu bloco pega mesmo. O ssh -G mostra a configuração final sem estabelecer qualquer ligação:

ssh -G localhost

Substitua localhost pelo seu nome abreviado e vê preto no branco, nas linhas hostname, user e port, o que o SSH vai usar a seguir. Um erro de escrita no nome do Host salta assim à vista em dois segundos, em vez de vinte minutos à procura do problema.

Como perceber que funcionou mesmo

Uma linha de comandos que aparece ainda não prova nada. Com várias janelas abertas, já houve quem largasse um rm no servidor errado. Quatro comandos curtos dão clareza:

hostname
id
cat /etc/os-release
uptime

O hostname tem de mostrar o nome do seu servidor, não o do seu portátil. O id mostra uid=0(root) quando trabalha como root. O cat /etc/os-release indica a distribuição e a versão, por exemplo Debian GNU/Linux 13 (trixie) ou Ubuntu 24.04.3 LTS. E o uptime encaixa no tempo de funcionamento de um servidor, não no de um posto de trabalho que é desligado todas as noites.

O teste mais rápido para saber se está mesmo por SSH e não num terminal local:

echo $SSH_CONNECTION

Se aparecer uma linha com quatro valores (o seu IP, a sua porta de origem, o IP do servidor, a porta de destino), tem sessão iniciada. Se ficar vazia, está a escrever no seu próprio computador. A sessão termina com exit ou com a combinação de teclas Ctrl e D.

Como continuar

O passo seguinte com sentido é a passagem das palavras-passe para as chaves. Uma chave SSH não se adivinha e, depois disso, pode desligar por completo a autenticação por palavra-passe, o que deixa a maior parte das tentativas de ataque automatizadas a bater em nada. Como se faz está em Configurar a autenticação por chave SSH. A seguir vêm a firewall e o bloqueio automático, descritos em Proteger o servidor depois da instalação.

Para começar, vale isto: depois de entrar uma vez, de ter verificado a impressão digital e de saber como voltar a entrar depois de uma reinstalação, a parte mais difícil está feita. Todo o resto acontece numa janela que já pode abrir agora.