SSH no Linux para iniciantes: o guia completo para acessar máquinas remotas com segurança

Existe um comando que separa quem "usa o Linux" de quem realmente administra máquinas Linux, e ele tem só três letras: SSH. É com ele que se acessa um servidor a milhares de quilômetros como se você estivesse sentado na frente dele, que se configura aquele Raspberry Pi esquecido numa gaveta, que se gerencia uma VPS na nuvem sem nunca tocar no hardware. E a melhor parte: apesar da fama de "coisa de administrador de sistemas", SSH no Linux é surpreendentemente simples de começar a usar. Este guia parte do zero — o que é, como conectar pela primeira vez, como trocar a senha por chaves (muito mais seguras) e como blindar o acesso para dormir tranquilo. Ao fim, você vai olhar para um terminal e ver não uma máquina, mas todas as que puder alcançar.

O que é SSH e para que serve

SSH significa Secure Shell ("shell seguro"), e é o protocolo padrão para acessar o terminal de outro computador pela rede de forma criptografada de ponta a ponta. Na prática, você digita um comando na sua máquina e passa a controlar o terminal de outra — rodar programas, editar arquivos, instalar pacotes, reiniciar serviços — exatamente como se estivesse fisicamente diante dela. Toda a comunicação vai cifrada, então mesmo que alguém intercepte o tráfego, só verá um amontoado ilegível.

A implementação que praticamente todo o mundo usa se chama OpenSSH. Curiosidade: ela nasceu no projeto OpenBSD, não no Linux, mas se tornou tão universal que hoje vem instalada (ou a um comando de distância) em qualquer distribuição. O OpenSSH não é um programa só; são vários, e para começar você precisa entender a divisão mais importante de todas:

• O cliente é o que você usa para se conectar a outra máquina. É o comando ssh. Ter o cliente instalado não abre nenhuma porta no seu computador — ele só faz chamadas para fora.
• O servidor (chamado sshd — o "d" final é de daemon, um programa que fica rodando em segundo plano) é o que escuta conexões e permite que alguém entre na máquina. Só quem tem o servidor rodando pode ser acessado por SSH.

Guarde essa distinção, porque ela reaparece o tempo todo: seu notebook quase sempre é o cliente; o servidor, a VPS ou o Raspberry Pi que você quer controlar rodam o servidor. Por padrão, toda essa conversa acontece na porta 22. E enquanto o Linux e o macOS já trazem o cliente ssh de fábrica, no Windows moderno ele também já vem embutido no terminal — ou você usa o velho PuTTY.

Instalando o servidor SSH

Para se conectar a algo, você não precisa instalar nada: o cliente já está aí (confirme com which ssh, que deve responder /usr/bin/ssh). O que talvez falte é o servidor, caso você queira que a sua máquina aceite conexões. Em Ubuntu, Debian e derivados, instale com:

sudo apt install openssh-server

Terminada a instalação, confira se o serviço está de pé:

systemctl status ssh

Se aparecer inactive (dead), é só ligar. E aqui vai um detalhe que pega muita gente: iniciar o serviço agora e habilitá-lo para subir sozinho a cada reinicialização são duas coisas diferentes. Faça as duas:

sudo systemctl start ssh
sudo systemctl enable ssh

O start liga agora; o enable garante que ele volte automaticamente depois de um reboot. Sem o segundo, você reinicia o servidor e descobre, frustrado, que o SSH "sumiu". (Nota sobre nomes: no Ubuntu e no Debian o serviço se chama ssh; em outras distribuições, sshd. São dois nomes para a mesma coisa.)

Sua primeira conexão

Chegou a hora. A sintaxe do comando é uma daquelas que você nunca mais esquece:

ssh usuario@ip

Ou seja: o nome do usuário que existe na máquina remota, um @ (que aqui significa "em/no") e o endereço IP dela. Um exemplo real seria ssh joao@192.168.1.20. Mas e se você não sabe o IP do servidor? Rode, na máquina que vai receber a conexão, um dos comandos:

ip a

Ele lista as interfaces de rede e seus endereços — numa rede doméstica, procure algo como 192.168.x.x ou 10.0.x.x. Em uma VPS de provedores como Linode, DigitalOcean ou Hostinger, o IP aparece direto no painel de controle.

Na primeiríssima conexão a um servidor, o SSH exibe uma mensagem perguntando se você confia na "autenticidade do host", mostrando uma longa impressão digital (fingerprint). Não pule isso com o piloto automático: essa é a defesa do SSH contra um ataque conhecido como man-in-the-middle, em que alguém no meio da rede se faz passar pelo servidor que você quer acessar. Cada servidor tem uma identidade única, e você está confirmando que é ele mesmo. Digite yes e siga.

A partir daí, o SSH pede a senha daquele usuário no servidor remoto. Digite (a senha não aparece na tela, nem em asteriscos — é normal) e pronto: seu prompt muda, e agora cada comando que você digita roda na outra máquina. Faça o teste com sudo apt update e veja o servidor remoto trabalhar. A fingerprint que você aceitou fica guardada em ~/.ssh/known_hosts, e é por isso que nas próximas vezes ele não pergunta mais. Para encerrar a sessão e voltar à sua máquina, digite exit (ou aperte Ctrl+D).

Dois truques úteis desde já: se o seu usuário local tem o mesmo nome do usuário remoto, dá para omitir e escrever só ssh 192.168.1.20. E se o servidor usa uma porta diferente da 22, informe com -p minúsculo: ssh -p 2222 joao@192.168.1.20.

Chaves SSH: o jeito certo (e mais seguro) de conectar

Senha funciona, mas tem dois problemas: você precisa digitá-la toda vez, e ela é vulnerável a ataques de força bruta, em que robôs tentam milhares de combinações por segundo. A solução profissional — e mais confortável — são as chaves SSH. Este é o coração do uso sério de SSH, então vá com calma.

Uma chave SSH é, na verdade, um par de arquivos que nascem juntos e são matematicamente ligados:

• A chave privada é secreta e nunca sai da sua máquina. É a sua identidade.
• A chave pública pode ser compartilhada à vontade — você pode até colá-la num outdoor. Ela vai instalada no servidor.

A analogia clássica: a chave pública é a fechadura que você instala na porta do servidor; a chave privada é a chave que abre aquela fechadura. Sem a chave privada, a pública é inútil — qualquer um pode vê-la e nada consegue fazer. Para gerar o seu par, rode na sua máquina:

ssh-keygen -t ed25519

O -t ed25519 escolhe o tipo de chave. O ed25519 é o padrão recomendado hoje: mais seguro e mais curto que o antigo RSA. (Se precisar de RSA por compatibilidade com algum sistema antigo, use ssh-keygen -t rsa -b 4096.) O comando pergunta onde salvar — aceite o padrão, ~/.ssh/id_ed25519 — e oferece uma passphrase, uma senha que protege a própria chave privada. Vale a pena definir uma: assim, se alguém roubar o arquivo da chave, ainda não consegue usá-la sem essa senha.

Ao final, você tem dois arquivos na pasta oculta ~/.ssh/: a chave privada id_ed25519 (sem extensão, a que você jamais compartilha) e a pública id_ed25519.pub (com .pub). Agora falta instalar a pública no servidor, e há um comando que faz isso sozinho, criando as pastas e permissões corretas do outro lado:

ssh-copy-id -i ~/.ssh/id_ed25519.pub joao@192.168.1.20

Ele vai pedir a senha do servidor uma última vez e depositar a sua chave pública no arquivo ~/.ssh/authorized_keys de lá — o "chaveiro" onde o servidor guarda todas as chaves públicas autorizadas, uma por linha. Feito isso, tente conectar de novo com ssh joao@192.168.1.20: se tudo deu certo, você entra sem digitar senha nenhuma (ou digitando apenas a passphrase da chave, se você definiu uma). O SSH comparou sua chave privada local com a pública do servidor, elas bateram, e a porta se abriu.

E a passphrase, você digita a cada conexão? Não precisa. Existe o ssh-agent, um programa que guarda a chave destrancada na memória durante a sessão. Em desktops Linux com ambiente gráfico ele geralmente já roda sozinho; onde não roda, você o inicia e adiciona a chave assim:

eval "$(ssh-agent)"
ssh-add ~/.ssh/id_ed25519

Digite a passphrase uma vez, e daí em diante as conexões daquele terminal fluem sem interrupção. Uma boa prática defendida por quem trabalha com muitos servidores: gere uma chave diferente para cada servidor ou finalidade. Assim, se uma vazar, você revoga só aquela, sem deixar todo o seu reino exposto.

O arquivo ~/.ssh/config: apelidos para seus servidores

Decorar IPs, portas e nomes de usuário cansa rápido. O SSH resolve isso com um arquivo de configuração do cliente em ~/.ssh/config (ele não existe por padrão; crie com touch ~/.ssh/config). Nele você define apelidos. Um bloco de exemplo:

Host servidor
    HostName 192.168.1.20
    User joao
    Port 22
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

A partir daí, esqueça o comando longo: basta ssh servidor. O HostName é o IP (ou domínio) de verdade, User é o usuário, Port a porta, IdentityFile aponta qual chave privada usar e o IdentitiesOnly yes manda o SSH tentar somente aquela chave — detalhe importante se você tem várias, porque testar todas de uma vez pode estourar o limite de tentativas do servidor e travar seu acesso. Adicione um bloco por servidor, com o nome que quiser, e sua vida vira ssh producao, ssh casa, ssh vps.

Transferindo arquivos por SSH

SSH não serve só para digitar comandos: sobre a mesma conexão segura você copia arquivos entre as máquinas. As três ferramentas mais úteis:

• scp — cópia simples, no mesmo estilo do cp. Para enviar um arquivo local ao servidor: scp arquivo.txt joao@192.168.1.20:/home/joao/. Para baixar, inverta a ordem. Um diretório inteiro pede o -r: scp -r pasta/ joao@192.168.1.20:/destino/.
• sftp — uma sessão interativa de transferência, com comandos como put (enviar), get (baixar) e ls. Abra com sftp joao@192.168.1.20.
• rsync — o mais poderoso para sincronizar pastas, porque copia só o que mudou: rsync -avz pasta/ joao@192.168.1.20:/destino/. Perfeito para backups.

Como tudo trafega dentro do túnel do SSH, essas transferências herdam a mesma criptografia — nada de FTP em texto puro por aqui.

Blindando o servidor: o arquivo sshd_config

Um servidor com SSH aberto na internet começa a receber tentativas automáticas de invasão em minutos. A boa notícia é que endurecer a segurança ("hardening") leva cinco minutos e mora todo num arquivo só: /etc/ssh/sshd_config (repare no d — este é o do servidor). Edite com sudo nano /etc/ssh/sshd_config. Linhas que começam com # estão desativadas; para ligar uma opção, remova o # e ajuste o valor. Os ajustes que mais importam:

• Desligue o login por senha. Depois de confirmar que suas chaves funcionam, mude para PasswordAuthentication no. Esta é, disparado, a mudança de segurança mais importante: sem senha, os robôs de força bruta simplesmente não têm o que tentar.
• Bloqueie o login direto do root. Troque para PermitRootLogin no. Você passa a entrar com um usuário comum e usa sudo para tarefas administrativas — assim, um atacante precisaria acertar usuário e senha/chave, não só a senha do onipotente root.
• Considere trocar a porta. Mude Port 22 para algo como Port 2222. Não é uma blindagem de verdade (quem faz uma varredura acha), mas afasta a enxurrada de bots que só batem na porta 22 — menos ruído nos logs. Lembre de reconectar depois com -p 2222.
• Reduza a superfície. Diretivas como PermitEmptyPasswords no, X11Forwarding no (se não usa aplicativos gráficos remotos), MaxAuthTries 4 (menos chances por conexão) e ClientAliveInterval 300 (desconecta sessões ociosas) fecham brechas pequenas que somam.

Depois de editar, aplique com sudo systemctl restart sshd. E aqui vai o conselho que evita o pânico de ficar trancado para fora do próprio servidor: não feche a sua conexão atual. Abra um segundo terminal e teste se ainda consegue entrar com as novas regras. Se algo deu errado, você ainda tem a primeira sessão aberta para corrigir. Só encerre a original quando a nova estiver comprovadamente funcionando.

Erros comuns e como resolver

Alguns perrengues clássicos de quem está começando, e o que eles querem dizer:

• "Connection refused": não há nada escutando na porta que você usou. Ou o serviço sshd está parado no servidor, ou você trocou a porta e esqueceu o -p, ou um firewall está bloqueando. Confira o serviço com systemctl status ssh.
• "Permission denied (publickey)": o servidor recusou sua chave e o login por senha está desativado. Verifique se a chave pública certa está no authorized_keys do servidor e se você está apontando para a chave privada correta com -i.
• A conexão simplesmente "trava" (timeout): quase sempre é firewall bloqueando a porta em algum ponto do caminho, ou o IP está errado.
• Aviso de que "a chave do host mudou": o SSH está te protegendo. Isso acontece se o servidor foi reinstalado/clonado — ou, no pior caso, se alguém está se passando por ele. Se você sabe que o servidor mudou legitimamente, remova a entrada antiga de ~/.ssh/known_hosts e reconecte.
• Erros de permissão nas chaves: o SSH é rigoroso e recusa chaves com permissões frouxas. A pasta ~/.ssh deve ser 700 e a chave privada, 600. Ajuste com chmod 700 ~/.ssh e chmod 600 ~/.ssh/id_ed25519.

Quando nada disso resolver, o diagnóstico definitivo vem de dois lugares. No cliente, adicione -v ao comando (ssh -v joao@192.168.1.20) para ver, passo a passo, o que o SSH tenta e onde falha. No servidor, acompanhe o log de autenticação em tempo real com sudo journalctl -fu ssh (ou tail -f /var/log/auth.log no Ubuntu/Debian) enquanto tenta conectar de outro terminal — a razão exata da recusa aparece ali, escrita.

Conclusão

SSH é uma daquelas ferramentas que parecem intimidantes de longe e óbvias depois que você usa. O caminho é sempre o mesmo: instale o servidor com openssh-server, conecte com ssh usuario@ip, troque a senha por um par de chaves geradas com ssh-keygen e instaladas com ssh-copy-id, organize seus acessos no ~/.ssh/config e, por fim, feche as portas erradas no sshd_config. Com esses cinco passos, você domina 90% do que se faz com SSH no dia a dia — e o outro passo, testar sempre em um segundo terminal antes de fechar o primeiro, é o que separa o administrador tranquilo do que perdeu o acesso ao próprio servidor.

Daqui para a frente, o mundo abre: túneis para acessar serviços internos, encaminhamento de portas, automação com scripts que rodam comandos remotos. Mas nada disso importa sem a base que você acabou de construir. Escolha uma máquina — uma VPS barata, um Raspberry Pi, até uma máquina virtual no seu próprio PC — e pratique. É digitando ssh e vendo o prompt de outra máquina responder que a ficha cai: o terminal deixou de ser uma janela e virou uma porta. Boas conexões!