Blindando o servidor SSH na VPS e EC2 contra bots

Você acabou de criar uma VPS ou uma instância EC2 na AWS. Ainda nem configurou direito o servidor e, pasme, já existem bots tentando invadir. Não é exagero. Em menos de 15 minutos após ligar uma máquina na nuvem, os primeiros acessos suspeitos começam a aparecer no log do SSH.

Bots varrem a internet o tempo todo. Eles testam combinações de root, ubuntu, admin, debian com senhas fracas na esperança de encontrar uma porta aberta e mal configurada. Se você criar uma instância Ubuntu na EC2, o nome de usuário padrão é ubuntu, e os bots sabem disso. Se for um Debian, tentam admin ou debian. Eles têm listas, e elas são enormes.

A boa notícia? Com 5 configurações básicas você reduz quase que totalmente o risco de acesso indevido. Vamos a elas.

As 5 camadas de proteção

1. Criar um usuário administrador: nunca use o usuário padrão da distro.
2. Autenticação por chave SSH: sem senha, sem risco de força bruta.
3. Desabilitar login como root: o alvo favorito dos bots.
4. Desabilitar login por senha: se não aceita senha, não adianta chutar.
5. Firewall + Fail2Ban: bloqueia quem insiste.

Antes de começar: EC2 × VPS

Se for EC2 (AWS): Quando você cria a instância EC2 na AWS já gera um par de chaves (pública/privada) no console ou via AWS CLI no momento da criação da instância. Você não precisa gerar uma nova chave, mas precisa pular a etapa de gerar e copiar a chave. As demais configurações (criar usuário, desabilitar root, firewall, fail2ban) ainda são necessárias.

Se for VPS: você vai precisar gerar a chave SSH manualmente, copiá-la para o servidor e configurar tudo do zero. O artigo cobre os dois cenários.

1. Atualizar o sistema

Sempre comece com o sistema atualizado. Pacotes desatualizados podem conter brechas conhecidas.

apt update
apt upgrade -y

2. Criar um usuário administrador

O nome de usuário padrão da sua distro (ubuntu, admin, debian etc.) é público. Os bots sabem qual é. Por isso a primeira coisa é criar um usuário só seu, com um nome que só você conhece.

adduser seu-usuario
usermod -aG sudo seu-usuario

Teste se o grupo sudo foi atribuído corretamente:

groups seu-usuario

Se aparecer sudo na lista, seu usuário tem privilégios administrativos. ✅

3. Gerar e configurar chave SSH

A chave SSH é como uma chave de casa: muito mais segura que uma senha. Enquanto senhas podem ser chutadas ou descobertas, a chave criptográfica é praticamente impossível de forjar.

🔹 Gerar a chave (Windows, Linux, macOS)

ssh-keygen -t ed25519 -C "seu-email@exemplo.com"

O comando acima cria um par de chaves usando o algoritmo Ed25519 (moderno, rápido e seguro). Você pode escolher onde salvar, o padrão ~/.ssh/id_ed25519 funciona bem.

Visualizar a chave pública (Linux e macOS)

cat ~/.ssh/id_ed25519.pub

Copie o texto que aparece. É a sua chave pública — pode compartilhá-la. A privada (id_ed25519 sem .pub) jamais deve sair da sua máquina.

Copiar a chave para o servidor (VPS)

Se for uma VPS comum, use o atalho:

ssh-copy-id -i ~/.ssh/nome-da-chave.pub seu-usuario@IP_DO_SERVIDOR

Esse comando instala sua chave pública no arquivo ~/.ssh/authorized_keys do servidor, e você já consegue conectar sem digitar senha.

Conectar ao servidor

ssh seu-usuario@IP_DO_SERVIDOR

Se tudo deu certo, você entra direto, sem pedir senha. 🎉

4. Endurecer a configuração do SSH

Agora vamos ajustar o coração da segurança: o arquivo de configuração do servidor SSH.

sudo nano /etc/ssh/sshd_config

Altere ou adicione as seguintes linhas:

# Desabilita login como root (os bots adoram tentar root)
PermitRootLogin no

# Permite autenticação por chave (é o que você acabou de configurar)
PubkeyAuthentication yes

# Desabilita login por senha (força bruta depende de senha)
PasswordAuthentication no

# Desabilita interação com senha (camada extra)
KbdInteractiveAuthentication no

# Opcional: alterar a porta SSH (fugir do padrão 22)
Port 2222

💡 Atenção para EC2 e VPS: em instâncias Ubuntu da AWS e VPS, existe o arquivo /etc/ssh/sshd_config.d/50-cloud-init.conf que sobrescreve as configurações do sshd_config. Você precisa editar também esse arquivo:

sudo nano /etc/ssh/sshd_config.d/50-cloud-init.conf

E adicionar:

PasswordAuthentication no
PermitRootLogin no
PubkeyAuthentication yes

Depois de salvar, reinicie o serviço SSH:

sudo systemctl restart ssh

Pronto. A partir de agora, não é mais possível fazer login com root ou com senha. Só entra quem tem a chave privada correta.

5. Firewall com UFW

O UFW (Uncomplicated Firewall) é um firewall simples e direto. Vamos liberar apenas o essencial.

sudo apt install ufw -y

# Bloquear toda conexão que entra (ninguém de fora se conecta sem sua autorização)
sudo ufw default deny incoming

# Liberar toda conexão que sai (você pode baixar pacotes, acessar sites etc.)
sudo ufw default allow outgoing

# Liberar SSH (porta padrão 22)
sudo ufw allow 22/tcp

# Se você alterou a porta SSH, libere a nova porta substituindo pela 22

# Liberar HTTP e HTTPS (para sites e APIs)
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Ativar o firewall
sudo ufw enable

Verifique as regras ativas:

sudo ufw status

O UFW agora funciona na seguinte lógica: tudo que chega do exterior é bloqueado por padrão, a menos que você explicitamente libere (como fez com SSH, HTTP e HTTPS). Já tudo que sai do servidor é permitido, você consegue fazer atualizações, acessar APIs, baixar pacotes, tudo normal.

É o princípio do menor privilégio aplicado à rede: nada de fora entra sem permissão, mas o servidor pode se comunicar livremente com o mundo.

6. Fail2Ban o segurança do SSH

O Fail2Ban monitora os logs do sistema e bloqueia temporariamente (por meio do firewall) IPs que fazem muitas tentativas de login com falha. É como um segurança na porta da balada: "já errou a senha 5 vezes? Pode ir embora."

sudo apt install fail2ban -y

# Habilitar para iniciar com o sistema
sudo systemctl enable fail2ban

# Iniciar agora
sudo systemctl start fail2ban

# Verificar se está rodando

sudo systemctl status fail2ban

7. (Bônus) Atualizações automáticas de segurança

Manter o sistema atualizado é fundamental. As atualizações automáticas instalam correções de segurança sem você precisar lembrar.

sudo apt install unattended-upgrades -y
sudo dpkg-reconfigure unattended-upgrades

Na tela que aparecer, selecione Sim.

Facilitando a conexão: o arquivo de configuração do SSH

Digitar ssh usuario@IP -p 2222 toda vez é chato. Crie um atalho no arquivo ~/.ssh/config da sua máquina local:

nano ~/.ssh/config

Adicione algo como:

Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/id_rsa
    IdentitiesOnly yes

Host vps_ou_ec2
    HostName IP_DA_SUA_VPS
    User seu-usuario
    IdentityFile ~/.ssh/id_ed25519
    Port 2222
    ServerAliveInterval 60
    ServerAliveCountMax 3

Agora, para conectar, basta digitar:

ssh vps_ou_ec2

E para testar a conexão com GitHub:

ssh -T git@github.com

Se tudo estiver certo, o GitHub responde algo como:

Hi seu-usuario! You've successfully authenticated, but GitHub does not provide shell access.

Investigando: como ver quem está tentando entrar

Quer ver os bots em ação? Esses comandos mostram em tempo real as tentativas de acesso no seu servidor:

# Ver tentativas de login em tempo real
sudo tail -f /var/log/auth.log

# Ver bloqueios do Fail2Ban
sudo tail -f /var/log/fail2ban.log

# Status detalhado do Fail2Ban para o SSH
sudo fail2ban-client status sshd

O log do auth.log vai mostrar dezenas (ou centenas) de tentativas de login vindo de IPs do mundo inteiro. O fail2ban.log vai mostrar os IPs que foram bloqueados. É assustador e ao mesmo tempo satisfatório saber que o Fail2Ban está fazendo o trabalho dele.

Testando a blindagem

Depois de aplicar todas as configurações, é hora de confirmar que está tudo funcionando. O teste é simples: tente conectar sem usar a chave SSH.

Na sua máquina local, tente conectar como root:

ssh root@IP_DO_SERVIDOR

Você deve receber algo como:

root@IP_DO_SERVIDOR: Permission denied (publickey).

Agora tente com o usuário que você criou, também sem informar a chave:

ssh seu-usuario@IP_DO_SERVIDOR

O resultado é o mesmo:

seu-usuario@IP_DO_SERVIDOR: Permission denied (publickey).

✅ Isso é bom! A mensagem Permission denied (publickey) significa que o servidor rejeitou a conexão porque você não apresentou uma chave válida. O servidor nem sequer pediu senha, porque a autenticação por senha está desabilitada. Exatamente o que queremos.

Agora faça o teste com a chave para confirmar que o acesso legítimo continua funcionando:

ssh -i ~/.ssh/sua-chave.pub seu-usuario@IP_DO_SERVIDOR

Se entrou sem pedir nada, parabéns! 🎉 Sua VPS ou EC2 está blindada contra bots, força bruta e hackers metidos a cracker.

Recapitulando

Com esses passos, seu servidor passa de "porta escancarada" para "cofre blindado". Veja o resumo:

Configuração	Protege contra
Usuário personalizado	Bots que tentam nomes de usuário padrão
Chave SSH	Força bruta de senha
Root desabilitado	Ataques direcionados ao root
Senha desabilitada	Qualquer ataque baseado em senha
UFW + Fail2Ban	Varreduras e múltiplas tentativas

Considerações finais

Configurar segurança no SSH não é frescura, é responsabilidade de quem coloca um servidor na internet. Os bots não dormem. Enquanto você lê este artigo, centenas de scripts automatizados estão escaneando IPs atrás de uma porta 22 aberta com PermitRootLogin yes e senha fraca.

Gaste 15 minutos aplicando essas configurações. Sua VPS/EC2 com seus dados, agradecem.

Feito!

Guia Definitivo de Chaves SSH: Segurança Máxima e Conexões Práticas na sua VPS

No universo da administração de servidores, o acesso remoto via SSH (Secure Shell) é uma das ferramentas mais triviais e indispensáveis. Contudo, há uma linha tênue entre a facilidade de acesso e a vulnerabilidade do sistema. Depender exclusivamente de logins por senha deixa seus servidores expostos a ataques automatizados de força bruta de escala global.

A solução definitiva para este problema reside na implementação de autenticação por chaves SSH. Neste artigo, vamos explorar minuciosamente o conceito de par de chaves, como realizar o endurecimento de segurança (hardening) do serviço no servidor remoto, automatizar a cópia das credenciais e estruturar atalhos para otimizar drasticamente o seu fluxo de trabalho diário.

1. O Conceito Fundamental: Chave e Fechadura

Para entender chaves SSH de forma definitiva, podemos utilizar a analogia clássica de uma chave física e sua respectiva fechadura criptográfica:

• Chave Privada (Sua Chave): Permanece exclusivamente na sua máquina local. Ela nunca, sob hipótese alguma, deve ser compartilhada, transmitida ou exposta a terceiros. Ela atua como o segredo necessário para assinar as solicitações de acesso.
• Chave Pública (A Fechadura): É instalada nos servidores remotos (VPS) aos quais você deseja obter acesso. Por ser um componente público, o conhecimento dela por terceiros não compromete o sistema, uma vez que ela é matematicamente inútil se não estiver associada à chave privada correspondente.

Quando você solicita uma conexão, o cliente local e o servidor remoto utilizam conceitos de criptografia assimétrica para validar a autenticidade da sessão sem que a sua chave privada precise trafegar pela rede.

2. Gerando o Par de Chaves Criptográficas

O primeiro passo prático consiste em gerar o par de chaves na sua máquina local. Atualmente, o padrão recomendado pela indústria em termos de segurança e performance de processamento é o algoritmo ED25519, superando os legados padrões RSA.

Abra o terminal do seu computador local e execute o comando abaixo:

ssh-keygen -t ed25519 -f ~/.ssh/id_vps_root

O parâmetro -t ed25519 especifica o algoritmo moderno desejado, enquanto o -f define o caminho e o nome customizado do arquivo de identidade (evitando sobrescrever chaves genéricas pré-existentes).

Durante o processo, o utilitário solicitará uma Passphrase (frase secreta). Trata-se de uma senha que criptografa a sua própria chave privada em disco. Caso alguém consiga roubar o arquivo da sua máquina, não poderá usá-lo sem conhecer essa senha. Para rotinas altamente automatizadas, alguns profissionais optam por deixá-la vazia, o que requer uma atenção redobrada na segurança física do dispositivo local.

Após a conclusão, dois arquivos serão gerados no diretório ~/.ssh/:

• id_vps_root: O arquivo contendo a sua chave privada (sigilo absoluto).
• id_vps_root.pub: O arquivo contendo a sua chave pública (a ser exportada).

3. Exportando a Chave Pública para a VPS

Para que o servidor remoto reconheça a sua assinatura criptográfica, precisamos armazenar o conteúdo da chave pública dentro de um arquivo específico na conta do usuário remoto, localizado por padrão em ~/.ssh/authorized_keys.

Método Automatizado (Recomendado)

A maneira mais limpa e segura de realizar esse procedimento é usando o comando nativo ssh-copy-id, passando explicitamente o arquivo público gerado:

ssh-copy-id -i ~/.ssh/id_vps_root.pub usuario@ip_do_seu_servidor

O utilitário se conectará ao servidor (solicitando a senha tradicional pela última vez), criará as pastas necessárias com as permissões corretas e inserirá a chave de maneira limpa.

Método Manual (Alternativo)

Caso o utilitário automatizado não esteja disponível, você pode exibir o conteúdo da chave na sua tela, copiá-lo e inseri-lo manualmente no servidor:

cat ~/.ssh/id_vps_root.pub

No servidor remoto, você precisará colar essa string de texto dentro do arquivo ~/.ssh/authorized_keys. É de suma importância garantir as permissões rígidas exigidas pelo serviço OpenSSH, executando na VPS:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
touch ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys

⚠️ Atenção Crucial às Permissões!

O OpenSSH possui salvaguardas rigorosas. Se o diretório .ssh ou o arquivo authorized_keys permitirem escrita ou leitura por outros grupos/usuários do sistema, o servidor ignorará a chave pública silenciosamente e bloqueará a conexão.

4. Hardening do Servidor: Ajustando o arquivo sshd_config

Apenas habilitar as chaves SSH não protege seu ambiente por completo se as vulnerabilidades de autenticação por senha padrão continuarem ativas. Precisamos reconfigurar o serviço SSH Daemon no servidor remoto.

Acesse sua VPS e abra o arquivo de configuração principal (utilize o editor de sua preferência com privilégios administrativos):

sudo nano /etc/ssh/sshd_config

Localize (ou adicione ao final do arquivo) as seguintes diretivas críticas detalhadas na tabela abaixo:

Diretiva de Configuração	Explicação Técnica e Impacto de Segurança
PubkeyAuthentication yes	Habilita oficialmente a validação e aceitação de conexões baseadas em chaves SSH assimétricas. Elemento mandatório da indústria.
PasswordAuthentication no	Desativa completamente o login por senhas tradicionais. Isso elimina 100% dos ataques automatizados baseados em dicionários e força bruta.
PermitRootLogin no	Impede que o usuário administrador máximo (root) realize login diretamente de fora. Obriga o acesso por uma conta de usuário comum, elevando privilégios apenas quando necessário via sudo.
PermitEmptyPasswords no	Mecanismo de salvaguarda explícito que impede acessos a contas locais que, por ventura ou erro, não possuam senha definida.

💡 Dica de Manutenção Proativa

Sistemas modernos baseados em Debian/Ubuntu frequentemente importam arquivos modulares localizados em /etc/ssh/sshd_config.d/*.conf. As diretivas são interpretadas de cima para baixo. Portanto, certifique-se de aplicar suas regras onde elas efetivamente se sobreponham aos padrões mais fracos.

Antes de aplicar as alterações, teste a sintaxe do arquivo de configuração para garantir que você não inseriu erros tipográficos que possam te trancar para fora do servidor de vez:

sudo sshd -t

Se nenhum erro for retornado, reinicie o daemon para aplicar as políticas ativas:

sudo systemctl restart ssh

5. Produtividade Máxima: Criando Atalhos Avançados (Aliases)

Após fixar as chaves, digitar comandos extensos definindo parâmetros de arquivos de identidade em todas as conexões compromete o fluxo produtivo. Para resolver isso, configuramos atalhos organizados diretamente na máquina local cliente.

No seu computador local, crie ou edite o arquivo de configuração do usuário cliente:

nano ~/.ssh/config

Adicione um bloco de configuração mapeando explicitamente a sua VPS:

Host meu-servidor
    HostName ip_ou_dominio_da_sua_vps
    User seu_usuario_remoto
    Port 22
    IdentityFile ~/.ssh/id_vps_root
    IdentitiesOnly yes

Entendendo as propriedades do bloco do cliente:

• Host meu-servidor: O alias ou pseudônimo que você escolheu. Você pode usar qualquer nome intuitivo aqui.
• HostName: O endereço IPv4 público ou domínio qualificado da VPS de destino.
• User: O nome exato do usuário remoto configurado para receber as chaves.
• IdentityFile: O caminho exato da chave privada local correspondente para esta conexão.
• IdentitiesOnly yes: Instrui o SSH a tentar estritamente a identidade configurada neste bloco, prevenindo que o agente teste chaves aleatórias em massa, o que dispararia gatilhos de segurança e rejeições por tentativas excessivas nos servidores mais rígidos.

Agora, o acesso à infraestrutura remota resume-se a um único e rápido comando no terminal:

ssh meu-servidor

O cliente lerá o arquivo config de forma transparente, carregará a identidade privada correta, mapeará as credenciais de IP e usuário adequadas e abrirá o terminal seguro de maneira imediata e robusta.

Considerações finais

A transição de autenticações tradicionais baseadas em senhas para pares de chaves assimétricas estruturadas via algoritmo ED25519 é o pilar inicial essencial de qualquer arquitetura de infraestrutura de rede resiliente. Ao combinar a segurança do endurecimento no arquivo sshd_config com o conforto operacional provido pelos blocos de configuração do cliente SSH, você eleva significativamente a maturidade de segurança da sua VPS ao mesmo tempo em que otimiza sua velocidade de operação diária.

Feito!

Simplificando múltiplos acessos a servidores Linux

O arquivo ~/.ssh/config é um arquivo que vale ouro que permite simplificar e automatizar o acesso a múltiplos servidores SSH. Com algumas configurações, você pode evitar a necessidade de digitar manualmente comandos longos e repetitivos.

Criação do par de chaves SSH

Antes de configurar o arquivo ~/.ssh/config, é necessário criar um par de chaves SSH (pública e privada). Execute o seguinte comando para gerar as chaves:

ssh-keygen -t rsa -b 2048 -C "seuemail@dominio.com"

Siga as instruções na tela para salvar as chaves no diretório padrão (~/.ssh/id_rsa e ~/.ssh/id_rsa.pub).

Criação do arquivo de configuração

Após criar o par de chaves, crie o arquivo de configuração se ele ainda não existir:

> ~/.ssh/config

Permissões do arquivo

Ajuste as permissões do arquivo para garantir que ele seja acessível apenas pelo usuário:

chmod 600 ~/.ssh/config

Editar o arquivo de configuração

Abra o arquivo ~/.ssh/config com seu editor de texto preferido:

vim ~/.ssh/config

Adicionar configurações de servidores

Dentro do arquivo, você pode adicionar configurações para múltiplos servidores. Aqui está um exemplo para dois servidores:

# Servidor 1
Host nomedoservidor1
    Hostname IP_ou_dominio1
    User usuario
    Port 22
    IdentityFile ~/.ssh/id_rsa
    Compression yes
    PermitLocalCommand yes
    LocalCommand echo "Login: $(whoami) na data de $(date) "

# Servidor 2
Host nomedoservidor2
    Hostname IP_ou_dominio2
    User usuario
    Port 22
    IdentityFile ~/.ssh/id_rsa
    Compression yes
    PermitLocalCommand yes
    LocalCommand echo "Login: $(whoami) na data de $(date) "

Sinta-se à vontade para adicionar quantos servidores precisar seguindo esse mesmo formato.

Utilizando as configurações

Depois de configurar o arquivo, você pode se conectar aos servidores usando apenas o nome do host definido no arquivo:

ssh nomedoservidor1

Isso elimina a necessidade de digitar o comando completo com usuário, IP, porta e caminho da chave de identidade.

Funcionalidades adicionais

Essas configurações também funcionam com outros comandos como scp e rsync. Por exemplo, para copiar um arquivo para nomedoservidor1, você pode usar:

scp /caminho/para/arquivo nomedoservidor1:/caminho/destino

Considerações finais:

Configurar o arquivo ~/.ssh/config pode economizar muito tempo e esforço, especialmente se você gerencia múltiplos servidores. A flexibilidade e simplicidade dessa configuração fazem dela uma ferramenta indispensável para administradores de sistemas e desenvolvedores.

Feito!

Configurando servidor SSH com máxima segurança

Para começar, vamos configurar o servidor SSH no seu sistema GNU/Linux Debian ou derivados. Siga os passos abaixo:

1. Atualização e instalação do OpenSSH Server

Execute os seguintes comandos no seu terminal:

$ sudo apt update

$ sudo apt install openssh-server -y


2. Configuração do OpenSSH Server

Agora, vamos configurar o arquivo de configuração do SSH:

$ sudo vim /etc/ssh/sshd_config

Dentro do arquivo, faça as seguintes alterações:

• Altere a porta padrão 22 para outra porta alta (acima de 1023).
• Habilite a autenticação por chave pública, certificando-se de que a opção PubkeyAuthentication esteja definida como yes.
• Desabilite a autenticação por senha, permitindo apenas a autenticação com chave pública.
• Não permita senhas vazias.
• Desabilite a conexão com o usuário root.

Salve as alterações e feche o editor Vim pressionando ESC + :x.

Você também pode adicionar as configurações SSH em um arquivo separado em /etc/sshd_config.d/01-ssh-config.conf.

$ sudo vim /etc/sshd_config.d/01-ssh-config.conf

Dentro do arquivo, adicione as mesmas configurações mencionadas anteriormente:

PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPassword no
PermitRootLogin no

Salve as alterações e feche o editor Vim pressionando ESC + :x.

3. Reinicie o serviço SSH

Depois de fazer as alterações, reinicie o serviço SSH:

$ sudo service ssh restart
4. Criação de usuário e par de chaves

Agora, vamos criar um usuário e um par de chaves pública e privada:

$ sudo useradd -m -s /bin/bash usuario

$ sudo passwd usuario

$ sudo ssh-keygen -t ed25519 -C "Minha Chave Principal"



Você pode definir uma senha para o par de chaves (opcional).

As chaves são salvas no diretório do usuário $HOME/.ssh, contendo os arquivos id_ed25519 (chave privada) e id_ed25519.pub (chave pública), respectivamente.

Para permitir a conexão, você precisa adicionar a chave pública ao arquivo authorized_keys do servidor.

$ sudo mkdir -p /home/usuario/.ssh

$ sudo cat ~/.ssh/id_ed25519.pub > /home/reginaldo/.ssh/authorized_keys


5. Reinicie o serviço SSH

Após adicionar a chave pública, reinicie o serviço SSH novamente: $ sudo service ssh restart

6. Teste de conexão

Agora, você pode testar a conexão SSH em outra máquina conectando ao servidor que acabou de fazer a configuração do SSH, informando o usuário e senha que foram criados:

$ ssh usuario@IPSERVIDOR

Na primeira conexão, será solicitada a senha da chave (se você a definiu). Além disso, você será notificado sobre o fingerprint, que é salvo no arquivo ~/.ssh/know_hosts.

Agora seu servidor SSH está configurado com máxima segurança.

Feito!