Comando ssh: acesso remoto seguro e scp no Linux

Praticamente tudo o que se faz num servidor Linux passa por uma ligação SSH: administrar, instalar, investigar um incidente, copiar ficheiros. O ssh cria um canal cifrado e autenticado entre a sua máquina e o servidor; o scp aproveita esse mesmo canal para transferir ficheiros. Juntos substituíram há muito os protocolos que enviavam credenciais em texto claro — e são, ao mesmo tempo, uma das superfícies de ataque mais marteladas da Internet: qualquer servidor com o porto 22 exposto acumula milhares de tentativas de login por dia.

Neste artigo percorremos o essencial dos dois comandos — da primeira ligação à autenticação por chaves, das cópias de ficheiros aos túneis — e terminamos com um simulador interativo onde pode praticar o ciclo completo sem precisar de um servidor.

O que fazem o ssh e o scp

O ssh (secure shell) abre uma sessão de terminal remota sobre um canal cifrado: tudo o que escreve corre no servidor como se estivesse sentado à frente dele. Antes de qualquer autenticação, o protocolo garante duas coisas: a confidencialidade (a cifra negociada entre as duas máquinas) e a identidade do servidor, verificada através da fingerprint da chave de anfitrião. O scp (secure copy) usa exatamente a mesma infraestrutura — mesmas chaves, mesmo known_hosts, mesma cifra — mas em vez de abrir uma shell copia ficheiros entre as duas máquinas.

ssh [opções] utilizador@anfitrião [comando]
scp [opções] origem destino        # o lado remoto escreve-se utilizador@anfitrião:caminho

Na primeira ligação a um servidor desconhecido, o ssh mostra a fingerprint da chave do anfitrião e pergunta se confia nela. É o modelo TOFU (trust on first use): aceite uma vez, a fingerprint fica guardada em ~/.ssh/known_hosts e as ligações seguintes são silenciosas. Se ela mudar sem aviso, o ssh recusa-se a ligar — pode ser uma reinstalação legítima do servidor, mas também pode ser alguém no meio do caminho.

As opções que interessam

Ligar

• ssh utilizador@anfitrião — a forma básica. Sem utilizador explícito, usa o nome de utilizador local.
• -p PORTA — liga a uma porta alternativa. Detalhe que engana muita gente: o known_hosts guarda a entrada como [anfitrião]:porta, por isso a fingerprint volta a ser pedida mesmo num servidor já conhecido na porta 22.
• -i FICHEIRO — escolhe a chave privada a usar, útil quando mantém chaves separadas por cliente ou por função.
• -J anfitrião — ProxyJump: chega a um servidor interno atravessando um bastião, com o tráfego cifrado ponta a ponta.
• -v (ou -vvv) — mostra a negociação e a autenticação passo a passo; é a primeira ferramenta de diagnóstico quando uma ligação falha.

Tudo isto pode — e deve — ser fixado no ficheiro ~/.ssh/config, um bloco por servidor, para que o comando do dia a dia volte a ser curto:

Host producao
    HostName 198.51.100.10
    User aluno
    IdentityFile ~/.ssh/id_ed25519
    ProxyJump bastiao.exemplo.pt

Chaves em vez de passwords

A autenticação por chave pública é mais forte e mais cómoda do que qualquer password. O fluxo tem três passos e faz-se uma única vez por máquina:

# 1. gerar o par de chaves (a privada nunca sai da sua máquina)
ssh-keygen -t ed25519 -C "aluno@hjfr"

# 2. instalar a chave pública no servidor (a última password que escreve)
ssh-copy-id -i ~/.ssh/id_ed25519.pub aluno@198.51.100.10

# 3. a partir daqui, entra sem password
ssh aluno@198.51.100.10

• ssh-keygen -t ed25519 — gera o par recomendado atualmente: chaves curtas, rápidas e sem os problemas históricos de parâmetros fracos. Proteja a chave privada com passphrase.
• ssh-copy-id — acrescenta a chave pública ao ~/.ssh/authorized_keys do servidor, tratando das permissões corretas.
• ssh-agent / ssh-add — guardam a chave decifrada durante a sessão, para escrever a passphrase apenas uma vez.
• -A (agent forwarding) — reencaminha o seu agente para o servidor remoto. Evite: qualquer processo com privilégios de root nesse servidor passa a poder autenticar-se como você noutras máquinas.

Copiar ficheiros com o scp

# enviar um ficheiro para o servidor
scp relatorio.pdf aluno@198.51.100.10:~/uploads/

# trazer um ficheiro do servidor para a pasta atual
scp aluno@198.51.100.10:/var/backups/backup.tar.gz .

# pastas inteiras, recursivamente
scp -r dados/ aluno@198.51.100.10:~/uploads/

• -r — copia diretórios recursivamente.
• -P PORTA — porta alternativa. Atenção à armadilha clássica: no scp a porta é -P maiúsculo; o -p minúsculo preserva datas de modificação e permissões.
• sftp — sessão interativa de transferência (ls, get, put) sobre o mesmo protocolo.
• rsync -e ssh — para sincronizações repetidas ou volumes grandes: só transfere as diferenças e retoma onde ficou.

Túneis

O canal SSH transporta mais do que shells e ficheiros. Com -L, um porto local passa a apontar para um serviço alcançável a partir do servidor — a forma correta de administrar uma base de dados que nunca deve ter porta aberta para a rede:

ssh -N -L 9090:127.0.0.1:3306 aluno@198.51.100.10
# noutro terminal: mysql -h 127.0.0.1 -P 9090  (fala com o MariaDB interno do servidor)

• -L local:host:porta — túnel local, como no exemplo acima.
• -R — túnel inverso: expõe um serviço da sua máquina num porto do servidor.
• -D PORTA — proxy SOCKS dinâmico: o tráfego de aplicações inteiras sai pelo servidor.
• -N — não abre shell; o processo fica apenas a manter o túnel.

ssh em cibersegurança

Hardening do serviço. O SSH é o alvo número um dos ataques de força bruta automatizados. As três linhas de defesa com melhor relação custo-benefício estão no /etc/ssh/sshd_config: PasswordAuthentication no (só chaves — as tentativas de adivinhar passwords passam a ser inúteis), PermitRootLogin no (o root nunca entra diretamente) e AllowUsers ou AllowGroups (lista fechada de quem pode ligar). A ordem das operações importa: instale e teste a sua chave antes de desligar a autenticação por password, ou fecha-se fora do próprio servidor.

Fingerprints e man-in-the-middle. O aviso de fingerprint alterada — remote host identification has changed — nunca deve ser silenciado por reflexo. Se o servidor não foi reinstalado, alguém pode estar a intercetar a ligação. Em ambientes geridos, a validação por outro canal (ou certificados SSH emitidos por uma autoridade interna) elimina a incerteza do TOFU.

Bastiões e serviços internos. Com -J e -L, a arquitetura segura torna-se prática: os servidores internos não expõem portas à Internet, todo o acesso passa por um bastião auditado, e as bases de dados e painéis de administração só são alcançáveis por túnel. Menos superfície exposta, menos alertas para triar.

Deteção e resposta. Do lado defensivo, os logs de autenticação do SSH são dos primeiros a analisar num incidente: tentativas falhadas em rajada denunciam força bruta, e um login por chave de origem invulgar pode indicar uma chave privada roubada. Vale também a pena auditar os authorized_keys de todas as contas com regularidade — uma chave pública acrescentada por um atacante é uma porta das traseiras persistente e discreta.

Experimente no simulador interativo

A simulação abaixo recria dois anfitriões fictícios — o seu portátil e um servidor — e mostra, de cada lado, o estado real do que o SSH usa: chaves em ~/.ssh/, o known_hosts, o authorized_keys e a configuração do serviço. Escolha o comando a executar (ligação, ssh-keygen, ssh-copy-id, cópias com scp, salto por bastião, túnel) e combine os estados do laboratório para ver o efeito de cada um: a primeira ligação pede a fingerprint, a chave instalada dispensa a password, o PasswordAuthentication no barra quem não tem chave. Use Demonstrar tudo para seguir a sequência guiada completa — da password à chave e ao túnel — ou navegue com Anterior e Seguinte.

Erros comuns e boas práticas

• Aceitar fingerprints por reflexo — o yes automático anula a única proteção contra man-in-the-middle que o TOFU oferece. Na primeira ligação a um servidor importante, confirme o valor por outro canal.
• Desligar a password antes de testar a chave — PasswordAuthentication no sem uma chave instalada e testada é a receita para se trancar fora do servidor. Mantenha uma sessão aberta enquanto valida a alteração.
• Chave privada com permissões abertas — o ssh recusa usar uma chave legível por outros (unprotected private key file). O correto é chmod 600 ~/.ssh/id_ed25519.
• Confundir -p e -P — porta alternativa é -p no ssh mas -P no scp; o -p do scp preserva atributos dos ficheiros.
• Chave privada sem passphrase — se o portátil for comprometido, a chave é utilizável de imediato. Passphrase forte + ssh-agent dão segurança sem sacrificar a comodidade.
• Agent forwarding por omissão — só ative -A quando é mesmo necessário e apenas para servidores em que confia; um administrador malicioso do lado remoto pode usar o seu agente.
• Esquecer os authorized_keys nas auditorias — reveja periodicamente que chaves têm acesso a cada conta e remova as de colaboradores e máquinas que já não existem.

---

Conclusão

O ssh e o scp são a espinha dorsal da administração remota em Linux: um canal cifrado que transporta sessões, ficheiros e túneis, com um modelo de autenticação que — bem configurado — elimina as passwords da equação. O ciclo ssh-keygen → ssh-copy-id → PasswordAuthentication no é provavelmente o hardening com melhor retorno que pode fazer num servidor. Se está a montar contas de utilizador para esse servidor, veja também o nosso artigo sobre o useradd.

Quer aprofundar estas competências ou precisa de apoio especializado em segurança e administração de sistemas? Conheça os serviços de formação e consultoria da HJFR no nosso catálogo de serviços — desenhamos percursos práticos para equipas técnicas e programas à medida para empresas.

Este artigo faz parte da série «Comandos Linux, um a um» do blog HJFR — fique atento aos próximos comandos.