Acesso SSH: O Guia Técnico Completo para Gerenciamento Seguro de Servidores Remotos

SSH (Secure Shell) é um protocolo de rede criptográfico que estabelece um túnel encriptado entre dois hosts em rede, permitindo execução autenticada de comandos, transferência de ficheiros e encaminhamento de portas em redes não confiáveis. Opera na porta TCP 22 por padrão e substitui os predecessores em texto simples — Telnet, rsh e FTP — com um protocolo que fornece confidencialidade, integridade e autenticação mútua num único handshake.

Para qualquer administrador que gere um VPS ou servidor dedicado, o SSH não é infraestrutura opcional — é o plano de controlo principal. Cada decisão de configuração que toma em torno do SSH afeta diretamente a superfície de ataque do seu servidor, a fiabilidade operacional e a postura de conformidade.

Como Funciona o SSH: A Arquitetura do Protocolo

Compreender o SSH ao nível do protocolo é o que separa os administradores que o configuram corretamente daqueles que deixam lacunas exploráveis.

O Modelo de Três Camadas

O SSH é definido pelo RFC 4251–4254 e opera em três subcamadas distintas empilhadas sobre TCP:

• Protocolo de Camada de Transporte SSH — trata da autenticação do servidor, troca de chaves, negociação de encriptação e configuração de MAC (código de autenticação de mensagem). É aqui que ocorre o handshake criptográfico.
• Protocolo de Autenticação de Utilizador SSH — corre sobre a camada de transporte e trata da autenticação cliente-para-servidor usando métodos como publickey, password, keyboard-interactive ou gssapi-with-mic.
• Protocolo de Ligação SSH — multiplexa o túnel encriptado em canais lógicos, cada um transportando uma sessão de shell, um subsistema SFTP, uma porta encaminhada ou uma ligação de agente.

O Handshake em Detalhe

Quando executa ssh user@host, a seguinte sequência é executada antes de ver uma linha de comandos:

1. A ligação TCP é estabelecida ao servidor na porta configurada.
2. Troca de versão — cliente e servidor trocam strings de versão do protocolo (SSH-2.0-OpenSSH_9.x).
3. Negociação de algoritmos (SSH_MSG_KEXINIT) — ambos os lados anunciam algoritmos de troca de chaves suportados, tipos de chaves de host, cifras, MACs e métodos de compressão. A primeira opção mutuamente suportada em cada lista vence.
4. Troca de chaves (KEX) — tipicamente Diffie-Hellman ou Elliptic Curve Diffie-Hellman (ECDH). Ambos os lados derivam um segredo partilhado sem o transmitir. Isto produz chaves de sessão.
5. Verificação da chave de host do servidor — o servidor assina um valor com a sua chave de host privada. O cliente verifica esta assinatura contra o seu ficheiro ~/.ssh/known_hosts. Uma incompatibilidade aciona um aviso e bloqueia a ligação por padrão.
6. Encriptação ativada — todo o tráfego subsequente é encriptado e protegido por integridade usando a cifra negociada (por exemplo, chacha20-poly1305) e MAC.
7. Autenticação do utilizador — o cliente tenta autenticação usando o método negociado. Com autenticação publickey, o cliente assina um desafio com a sua chave privada; o servidor verifica usando a chave pública armazenada.
8. Canal aberto — um canal de shell, subsistema SFTP ou exec é aberto e a sessão começa.

Todo este processo normalmente completa em menos de 100 milissegundos numa rede local.

Criptografia Simétrica vs. Assimétrica no SSH

Um equívoco comum é que o SSH “usa encriptação de chave pública” para todo o tráfego. Não usa. Os papéis são distintos:

SSH vs. Protocolos de Acesso Remoto Legados

Gerar Pares de Chaves SSH

Os pares de chaves SSH são a base do acesso seguro e escalável a servidores. A autenticação por palavra-passe é vulnerável a ataques de força bruta e preenchimento de credenciais; a autenticação baseada em chaves não é.

Escolher o Algoritmo de Chave Correto

Ed25519 é a melhor prática atual. Usa criptografia de curva elíptica Curve25519, produz chaves compactas de 256 bits, é mais rápido que RSA em níveis de segurança equivalentes, e é suportado pelo OpenSSH 6.5+ (lançado em 2014).

ssh-keygen -t ed25519 -C "admin@yourhost.example.com"

Use RSA apenas quando precisar de compatibilidade com sistemas legados que não suportam Ed25519:

ssh-keygen -t rsa -b 4096 -C "admin@yourhost.example.com"

Não use DSA (limitado a 1024 bits, comprometido) ou ECDSA com curvas NIST (preocupações sobre a proveniência dos parâmetros de curva NIST). Ed25519 é a escolha inequívoca para novas implementações.

Guia de Geração de Chaves

ssh-keygen -t ed25519 -C "ops-team-key-2025"

Ser-lhe-á solicitado:

• Localização do ficheiro — o padrão é ~/.ssh/id_ed25519. Aceite o padrão ou especifique um caminho personalizado para ambientes com múltiplas chaves.
• Frase-passe — defina sempre uma. Uma frase-passe encripta a chave privada em repouso usando AES-256-CBC (ou bcrypt com OpenSSH mais recente). Se o seu ficheiro de chave privada for roubado, a frase-passe é a última linha de defesa.

Isto produz dois ficheiros:

~/.ssh/id_ed25519 — a chave privada. Nunca partilhe isto. As permissões devem ser 600.
~/.ssh/id_ed25519.pub — a chave pública. É isto que distribui aos servidores.

Gerir Múltiplas Chaves com ~/.ssh/config
Ao gerir múltiplos servidores ou contas, use um ficheiro de configuração SSH para evitar especificar flags em cada ligação:
# ~/.ssh/config

Host prod-web
    HostName 203.0.113.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    Port 2222

Host staging
    HostName 203.0.113.20
    User ubuntu
    IdentityFile ~/.ssh/id_ed25519_staging
Com isto em vigor, ssh prod-web expande-se automaticamente para os parâmetros de ligação completos.
Implementar a Sua Chave Pública num Servidor
Método 1: ssh-copy-id (Recomendado para Configuração Inicial)
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@your_server_ip
Isto acrescenta a chave pública a ~/.ssh/authorized_keys no host remoto e define as permissões corretas automaticamente.
Método 2: Implementação Manual (Quando ssh-copy-id Não Está Disponível)
cat ~/.ssh/id_ed25519.pub | ssh user@your_server_ip 
  "mkdir -p ~/.ssh && chmod 700 ~/.ssh && 
   cat >> ~/.ssh/authorized_keys && 
   chmod 600 ~/.ssh/authorized_keys"
Método 3: Consola ou API do Fornecedor de Nuvem
A maioria dos fornecedores de nuvem e painéis de controlo de alojamento permitem injetar chaves públicas durante o aprovisionamento de instâncias. Esta é a abordagem correta para infraestrutura automatizada — a chave está presente antes do arranque da instância, eliminando o problema do ovo e da galinha de precisar de SSH para implementar chaves SSH.
O Formato do Ficheiro authorized_keys
Cada linha em ~/.ssh/authorized_keys é uma chave pública, opcionalmente prefixada com opções:
restrict,command="/usr/local/bin/backup.sh" ssh-ed25519 AAAA... backup-key
from="192.168.1.0/24" ssh-ed25519 AAAA... ops-key
A opção restrict desativa o encaminhamento de portas, encaminhamento de agente e alocação de PTY para essa chave — útil para chaves de implementação ou contas de automação de backup que não devem ter acesso interativo à shell.
Fortalecer o Servidor SSH: /etc/ssh/sshd_config
Uma instalação padrão do OpenSSH é funcional mas não reforçada. A configuração seguinte representa uma linha de base de nível de produção. Aplique as alterações a /etc/ssh/sshd_config, depois valide e recarregue:
sshd -t && systemctl reload sshd
Execute sempre sshd -t antes de recarregar — um erro de sintaxe em sshd_config não irá bloquear o daemon em execução, mas impedirá que reinicie após um reboot, bloqueando o seu acesso.
Bloco de Reforço Recomendado para sshd_config
# /etc/ssh/sshd_config - Production hardening baseline

Port 2222
AddressFamily inet
ListenAddress 0.0.0.0

# Host keys - prefer Ed25519
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key

# Cryptographic hardening
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

# Authentication
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication no
PermitEmptyPasswords no
ChallengeResponseAuthentication no
UsePAM yes

# Session hardening
LoginGraceTime 30
MaxAuthTries 3
MaxSessions 5
ClientAliveInterval 300
ClientAliveCountMax 2
TCPKeepAlive no

# Disable unused features
X11Forwarding no
AllowAgentForwarding no
AllowTcpForwarding no
PermitTunnel no
GatewayPorts no

# Restrict access
AllowUsers deploy ops-user
Banner /etc/ssh/banner.txt
Decisões Críticas de Reforço Explicadas
PermitRootLogin no — O login de root via SSH é um alvo de alto valor. Use um utilizador regular e escale com sudo. Se absolutamente precisar de acesso equivalente a root via uma chave específica (por exemplo, para automação), use PermitRootLogin prohibit-password para permitir login de root apenas por chave enquanto bloqueia tentativas por palavra-passe.
AllowTcpForwarding no — Se o seu servidor não é um bastion ou host de salto, desative o encaminhamento TCP. Um atacante com uma sessão SSH válida poderia de outra forma usar o seu servidor como proxy para alcançar recursos de rede interna.
TCPKeepAlive no com ClientAliveInterval — TCPKeepAlive opera na camada TCP e é visível para intermediários de rede. ClientAliveInterval envia mensagens de keepalive através do canal SSH encriptado, o que é simultaneamente mais fiável e mais privado.
LoginGraceTime 30 — Reduz a janela durante a qual uma ligação não autenticada ocupa um slot do servidor. O padrão de 120 segundos é excessivo.
AllowUsers — Coloque na lista branca apenas as contas que legitimamente precisam de acesso SSH. Esta é uma barreira rígida que opera antes de qualquer tentativa de autenticação.
Alterar a Porta SSH Padrão
Mover o SSH da porta 22 não melhora a segurança contra um atacante direcionado — qualquer varredura de portas irá encontrá-lo. O que faz é eliminar o enorme volume de bots automatizados e oportunistas de força bruta que atacam exclusivamente a porta 22. Isto reduz significativamente o ruído de registos e a carga do servidor.
# In /etc/ssh/sshd_config
Port 2222
Antes de recarregar, abra a nova porta na sua firewall:
# UFW
ufw allow 2222/tcp
ufw delete allow 22/tcp

# firewalld
firewall-cmd --permanent --add-port=2222/tcp
firewall-cmd --permanent --remove-service=ssh
firewall-cmd --reload

# iptables
iptables -A INPUT -p tcp --dport 2222 -j ACCEPT
iptables -D INPUT -p tcp --dport 22 -j ACCEPT
Se o seu servidor executa SELinux, deve também atualizar o contexto de porta SELinux:
semanage port -a -t ssh_port_t -p tcp 2222
Ligar a um Servidor
Ligação Básica
ssh user@your_server_ip
Ligar a uma Porta Não Padrão
ssh -p 2222 user@your_server_ip
Ligar com uma Chave Específica
ssh -i ~/.ssh/id_ed25519_prod user@your_server_ip
Modo Verboso para Depuração
ssh -vvv user@your_server_ip
A flag -vvv imprime cada passo do handshake, tentativa de autenticação e negociação de canal. É a primeira ferramenta a usar quando uma ligação falha inesperadamente.
Transferências Seguras de Ficheiros via SSH
SCP (Protocolo de Cópia Segura)
SCP é uma ferramenta simples e não interativa de cópia de ficheiros. É rápida e amplamente disponível, mas não tem capacidade de retoma e tratamento de erros limitado.
Copiar um ficheiro local para um servidor remoto:
scp -P 2222 /local/path/file.tar.gz user@your_server_ip:/remote/path/
Copiar um ficheiro remoto para local:
scp -P 2222 user@your_server_ip:/remote/path/file.tar.gz /local/path/
Cópia recursiva de diretório:
scp -rp -P 2222 /local/directory/ user@your_server_ip:/remote/directory/
Nota: O projeto OpenSSH descontinuou o protocolo SCP legado no OpenSSH 9.0. O scp moderno agora usa o protocolo SFTP por baixo por padrão. A interface de comandos permanece a mesma, mas o transporte subjacente é mais robusto.
SFTP (Protocolo de Transferência de Ficheiros SSH)
SFTP é um subsistema de transferência de ficheiros completo com listagem de diretórios, gestão de permissões e suporte de retoma. É a escolha correta para gestão interativa de ficheiros.
sftp -P 2222 user@your_server_ip
Comandos SFTP comuns dentro da sessão interativa:
sftp> ls -la                          # List remote directory
sftp> lls                             # List local directory
sftp> put localfile.txt /remote/path/ # Upload file
sftp> get /remote/file.txt ./         # Download file
sftp> mput *.log /remote/logs/        # Upload multiple files
sftp> mkdir /remote/newdir            # Create remote directory
sftp> chmod 640 /remote/file.txt      # Change remote permissions
sftp> bye                             # Exit
rsync via SSH (Recomendação de Produção)
Para sincronizar diretórios, backups incrementais ou grandes conjuntos de dados, rsync via SSH é significativamente mais eficiente que SCP ou SFTP. Transfere apenas blocos alterados, não ficheiros inteiros.
rsync -avz --progress -e "ssh -p 2222 -i ~/.ssh/id_ed25519" 
  /local/data/ user@your_server_ip:/remote/data/
A flag -z ativa a compressão em trânsito. Para dados já comprimidos (arquivos, imagens), omita-a — a compressão de dados já comprimidos desperdiça CPU sem reduzir o tamanho da transferência.
Encaminhamento de Portas SSH e Tunelamento
O encaminhamento de portas é uma das capacidades mais poderosas e subutilizadas do SSH. Permite-lhe aceder de forma segura a serviços que não estão diretamente expostos à internet.
Encaminhamento de Porta Local
Encaminhar uma porta local para um serviço remoto. Exemplo: aceder a uma instância MySQL remota (porta 3306) que está vinculada ao localhost no servidor:
ssh -L 3307:127.0.0.1:3306 user@your_server_ip -N
Agora mysql -h 127.0.0.1 -P 3307 na sua máquina local liga-se através do túnel encriptado ao MySQL remoto.
Encaminhamento de Porta Remota
Expor um serviço local ao servidor remoto. Útil para testar webhooks ou partilhar um servidor de desenvolvimento local:
ssh -R 8080:127.0.0.1:3000 user@your_server_ip -N
Encaminhamento de Porta Dinâmico (Proxy SOCKS)
Transformar a ligação SSH num proxy SOCKS5, encaminhando tráfego TCP arbitrário através do servidor:
ssh -D 1080 user@your_server_ip -N
Configure o seu browser ou aplicação para usar SOCKS5 127.0.0.1:1080.
Agente SSH e Encaminhamento de Agente
ssh-agent mantém chaves privadas desencriptadas em memória para que não tenha de reinserir a sua frase-passe em cada ligação.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
O encaminhamento de agente (ssh -A) permite que um servidor remoto use o seu agente local para autenticar num terceiro servidor. Isto é útil para arquiteturas de host bastion, mas acarreta risco: um utilizador root no servidor intermediário pode usar o seu socket de agente encaminhado. Prefira ProxyJump em alternativa:
ssh -J bastion.example.com user@internal-server.example.com
ProxyJump encaminha a ligação TCP através do bastion sem expor o seu agente ao mesmo.
Resolução de Problemas Comuns de SSH
Ligação Recusada (ssh: connect to host ... port 22: Connection refused)
Diagnóstico sistemático:

Verificar se o daemon SSH está em execução: systemctl status sshd

• Confirmar a porta em escuta: ss -tlnp | grep sshd
• Verificar regras de firewall: ufw status ou iptables -L -n | grep 22
• Verificar se o servidor é acessível ao nível da rede: ping your_server_ip
• Se usar um fornecedor de nuvem, verificar as regras de grupo de segurança ou ACL de rede na consola do fornecedor.

Permissão Negada (publickey)

Este é o erro SSH mais comum. Percorra esta lista de verificação:

# On the server, check authorized_keys permissions
ls -la ~/.ssh/
stat ~/.ssh/authorized_keys

# Fix permissions if wrong
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R $USER:$USER ~/.ssh

# Verify the public key is actually present
cat ~/.ssh/authorized_keys

# Check sshd logs for the specific rejection reason
journalctl -u sshd -n 50 --no-pager
# or
tail -50 /var/log/auth.log

Causas comuns além das permissões:

• O ficheiro authorized_keys contém a chave errada (por exemplo, copiou a chave privada em vez do ficheiro .pub).

StrictModes yes em sshd_config (o padrão) rejeita ligações se as permissões do diretório home forem demasiado abertas — chmod 755 ~ é o máximo permitido.
AllowUsers ou AllowGroups em sshd_config exclui o utilizador que se liga.
SELinux está a bloquear o acesso a ~/.ssh/ — verifique ausearch -m avc -ts recent.

Timeout de Ligação SSH
# In /etc/ssh/sshd_config (server side)
ClientAliveInterval 60
ClientAliveCountMax 3

# In ~/.ssh/config (client side)
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
ClientAliveInterval envia um pacote nulo através do canal SSH encriptado a cada 60 segundos. Após ClientAliveCountMax respostas consecutivas em falta, o servidor termina a ligação. Isto impede que sessões zombie se acumulem.
Verificação de Chave de Host Falhou
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
Este aviso significa que a chave de host do servidor já não corresponde ao que está armazenado em ~/.ssh/known_hosts. Causas legítimas incluem reinstalação do servidor ou reatribuição de endereço IP. Causas maliciosas incluem um ataque man-in-the-middle. Investigue antes de prosseguir.
Se confirmou que o servidor foi legitimamente reinstalado:
ssh-keygen -R your_server_ip
Depois reconecte e verifique a impressão digital da nova chave de host contra a consola do servidor ou painel do fornecedor antes de a aceitar.
Autenticação Multi-Fator para SSH
A autenticação baseada em chaves é forte, mas adicionar um segundo fator TOTP (Palavra-passe de Uso Único Baseada em Tempo) cria defesa em profundidade. Mesmo que uma chave privada e a sua frase-passe sejam comprometidas, um atacante não pode autenticar sem o token TOTP.
Instalar e configurar libpam-google-authenticator no servidor:
apt install libpam-google-authenticator
google-authenticator
Depois configure PAM e sshd_config:
# /etc/pam.d/sshd - add this line
auth required pam_google_authenticator.so

# /etc/ssh/sshd_config
UsePAM yes
ChallengeResponseAuthentication yes
AuthenticationMethods publickey,keyboard-interactive
Com AuthenticationMethods publickey,keyboard-interactive, um utilizador deve fornecer uma chave válida E um código TOTP. Esta é a configuração de produção correta para servidores de alto valor.
Autoridade de Certificação SSH: Escalar a Gestão de Chaves
Em ambientes com dezenas de servidores e múltiplos administradores, gerir entradas individuais de authorized_keys torna-se operacionalmente insustentável. Os certificados SSH resolvem isto.
Uma Autoridade de Certificação (CA) SSH assina chaves de utilizador e de host. Os servidores confiam na chave pública da CA em vez de chaves de utilizador individuais. Adicionar um novo administrador requer apenas assinar a sua chave pública — sem alterações ao ficheiro authorized_keys de nenhum servidor.
# Create a CA key pair (store the private key offline or in a secrets manager)
ssh-keygen -t ed25519 -f /etc/ssh/ca_key -C "infrastructure-ca-2025"

# Sign a user's public key, valid for 7 days, for specific principals
ssh-keygen -s /etc/ssh/ca_key 
  -I "alice-ops-cert" 
  -n alice,deploy 
  -V +7d 
  ~/.ssh/id_ed25519.pub
Em cada servidor, configure a confiança na CA:
# /etc/ssh/sshd_config
TrustedUserCAKeys /etc/ssh/ca_key.pub
É assim que a infraestrutura em grande escala (incluindo fornecedores de nuvem e empresas) gere o acesso SSH sem gestão de chaves por servidor.
Matriz de Decisão Prática: Configuração SSH por Caso de Uso



Caso de Uso
Tipo de Chave
Porta
Autenticação por Palavra-passe
Login Root
Encaminhamento
MFA








—
—
—
—
—
—
—








VPS pessoal
Ed25519
2222+
Desativada
Proibido
Desativado
Opcional








Servidor web de produção
Ed25519
Não padrão
Desativada
Não
Desativado
Obrigatório








Bastion / host de salto
Ed25519
22 ou personalizado
Desativada
Não
Controlado
Obrigatório








Automação CI/CD
Ed25519 (chave de implementação)
Não padrão
Desativada
Não
Desativado
Não (apenas chave)








Servidor de base de dados
Ed25519
Não padrão
Desativada
Não
Apenas local
Obrigatório








Servidor de desenvolvimento
Ed25519
Padrão ou personalizado
Opcional
Não
Opcional
Opcional





Configurar SSH na Infraestrutura AlexHost
Quando aprovisiona um VPS ou servidor dedicado através da AlexHost, o acesso SSH é configurado por padrão. A palavra-passe root inicial é entregue via email de aprovisionamento, e a primeira ação recomendada é:

Iniciar sessão como root, criar um utilizador administrativo não-root e adicionar a sua chave pública ao ~/.ssh/authorized_keys desse utilizador.
Aplicar a linha de base de reforço sshd_config documentada acima.
Desativar a autenticação por palavra-passe e o login root.
Configurar a sua firewall para restringir o acesso SSH a intervalos de IP conhecidos onde operacionalmente viável.

Se preferir uma camada de gestão gráfica juntamente com SSH, as opções de VPS com cPanel e Painéis de Controlo VPS da AlexHost fornecem uma interface web para tarefas comuns enquanto deixam o SSH disponível para controlo administrativo total.
Para ambientes onde precisa de proteger aplicações web em execução no mesmo servidor, combinar o reforço SSH com um certificado SSL devidamente configurado cobre tanto as camadas de transporte administrativo como de aplicação.
Lista de Verificação de Pontos-Chave Técnicos
Antes de considerar a sua configuração SSH pronta para produção, verifique cada um dos seguintes:
Gestão de Chaves

As chaves privadas usam Ed25519 ou RSA-4096 no mínimo
Todas as chaves privadas estão protegidas com uma frase-passe forte
O diretório ~/.ssh/ tem permissões 700; authorized_keys tem 600

• As chaves de implementação usam as opções restrict e command= onde aplicável
• O calendário de rotação de chaves está documentado e aplicado

Configuração do Servidor

PasswordAuthentication no está definido e ativo
PermitRootLogin no ou prohibit-password está aplicado
SSH está a correr numa porta não padrão com regras de firewall atualizadas
AllowUsers ou AllowGroups restringe o acesso a contas nomeadas
LoginGraceTime está definido para 30 segundos ou menos
sshd -t passa sem erros após cada alteração de configuração

Reforço Criptográfico

KexAlgorithms exclui diffie-hellman-group1-sha1 e diffie-hellman-group14-sha1

• Ciphers exclui 3des-cbc, arcfour e blowfish-cbc
• MACs usa apenas variantes -etm (encrypt-then-MAC)

Segurança Operacional

• Os registos de autenticação SSH são monitorizados (/var/log/auth.log ou journalctl -u sshd)
• fail2ban ou equivalente está configurado para bloquear falhas de autenticação repetidas
• As impressões digitais de chaves de host estão registadas e armazenadas fora de banda para verificação
• MFA está ativado para todas as sessões de utilizador interativas em sistemas de produção
• CA SSH está em uso para ambientes com mais de cinco servidores ou três administradores

FAQ

Qual é a diferença entre chaves SSH e certificados SSH?

As chaves SSH requerem que cada servidor armazene a chave pública do utilizador em authorized_keys. Os certificados SSH são assinados por uma Autoridade de Certificação; os servidores confiam na CA em vez de chaves individuais. Os certificados escalam para grandes frotas sem gestão de chaves por servidor e suportam tempos de expiração, tornando a revogação simples.

Por que aparece Permission denied (publickey) mesmo quando a chave está correta?

As causas mais comuns são permissões incorretas de ficheiro em ~/.ssh/ (deve ser 700) ou authorized_keys (deve ser 600), um diretório home com permissão de escrita para todos (bloqueado por StrictModes), ou uma diretiva AllowUsers em sshd_config que exclui a conta que se liga. Verifique journalctl -u sshd no servidor para o motivo específico de rejeição.

Alterar a porta SSH de 22 é uma medida de segurança real?

Elimina ataques oportunistas automatizados direcionados à porta 22, o que reduz significativamente o ruído de registos e as tentativas de autenticação falhadas. Não protege contra um atacante direcionado que realiza uma varredura de portas. Deve ser combinado com fail2ban, autenticação apenas por chave e lista de permissões de IP de firewall para uma melhoria de segurança significativa.

Posso usar SSH sem um endereço IP estático no lado do cliente?

Sim. A autenticação baseada em chaves não requer um IP de cliente fixo. Se quiser restringir por IP, use a opção from= em authorized_keys ou regras de firewall. Para IPs dinâmicos, considere uma VPN para estabelecer uma identidade de rede estável antes de ligar, em vez de abrir SSH a toda a internet.

Qual é a forma mais segura de recuperar o acesso SSH se ficar bloqueado?

Aceda ao servidor através da consola fora de banda do seu fornecedor de alojamento (VNC, IPMI ou KVM over IP). A partir daí, monte o sistema de ficheiros, corrija o problema de sshd_config ou authorized_keys e reinicie o daemon SSH. Nos planos de VPS e servidor dedicado da AlexHost, a consola do fornecedor está disponível através do portal do cliente e não depende do SSH estar funcional.