SSH seguro no Ubuntu 26.04 com hardening e porta via socket activation

Ter SSH exposto com configurações padrão é um convite para varredura, tentativa de senha e erro operacional. Neste tutorial, você vai do zero até um servidor OpenSSH “production ready”, com autenticação por chave, senhas desativadas, hardening em arquivo dedicado e firewall ajustado. O ponto crítico no Ubuntu 26.04 é entender o Socket Activation, que muda a forma correta de trocar a porta.

Pré-requisitos e cenário do tutorial

Você vai precisar de:

• Ubuntu 26.04 “Resolute Raccoon”
• OpenSSH Server 9.x
• Acesso privilegiado no servidor (root ou sudo)
• Um segundo dispositivo (cliente) para testar conexões SSH

Exemplos usados (ajuste para o seu ambiente):

• Usuário: sempreupdate
• Hostname do servidor: ssh-server (pode ser IP)
• Porta SSH: 2222
• Autenticação: somente chaves (sem senha)

Entenda em 90 segundos: Socket Activation

No Ubuntu 26.04, o padrão é o Socket Activation do systemd para o SSH. Na prática:

• O ssh.socket controla em qual porta o SSH fica “escutando”.
• Se o ssh.socket estiver ativo (listening), a diretiva Port no sshd_config (incluindo arquivos em sshd_config.d/) pode ser ignorada.
• Resultado: você muda a porta no config do sshd, reinicia, e ele continua ouvindo na porta antiga, porque quem manda é o socket.

Antes de tentar trocar a porta, confirme se o socket está ativo:

systemctl status ssh.socket

Se aparecer active (listening), você vai precisar fazer override do socket com systemctl edit ssh.socket mais adiante.

Passo 1: instalação e chaves SSH (Ed25519)

1. Instale o servidor OpenSSH

Atualize o índice e instale o pacote:

sudo apt update sudo apt install openssh-server

Habilite o SSH no boot:

sudo systemctl enable ssh

Confira se o serviço está rodando:

sudo systemctl status ssh

Opcional, mas recomendado para este tutorial: verifique o socket activation:

systemctl status ssh.socket

2. Gere a chave no cliente (Ed25519)

No seu cliente, gere a chave Ed25519:

ssh-keygen -t ed25519 -C "your_email@example.com"

Aceite o caminho padrão quando solicitado. Se quiser, defina uma passphrase para proteção adicional da chave privada.

3. Copie a chave pública para o servidor

Envie a chave para o servidor com ssh-copy-id:

ssh-copy-id sempreupdate@ssh-server

Quando solicitado, informe a senha do usuário no servidor.

4. Teste login por chave antes do hardening

Teste a conexão:

ssh sempreupdate@ssh-server

Se você conectou sem digitar a senha do servidor (exceto passphrase da chave, se você definiu), pode seguir com segurança para o hardening.

Passo 2: criando a configuração de hardening

A recomendação aqui é não alterar o arquivo global padrão e, em vez disso, criar um arquivo dedicado em sshd_config.d/. Isso mantém suas regras de segurança separadas e fáceis de auditar.

1. Verifique overrides existentes em sshd_config.d/

Liste os arquivos existentes:

ls -la /etc/ssh/sshd_config.d/

Em servidores provisionados em nuvem, pode existir um arquivo (ex.: 50-cloud-init.conf) que habilita PasswordAuthentication yes. Se encontrar um override desse tipo, remova ou renomeie. Exemplo (remoção):

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

2. Crie o arquivo de hardening

Crie o arquivo:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

Adicione a configuração abaixo (ajuste o usuário em AllowUsers e a porta, se necessário):

# /etc/ssh/sshd_config.d/00-hardening.conf # SSH hardening no Ubuntu 26.04 # Controle de acesso AllowUsers sempreupdate PermitRootLogin no # Autenticação PubkeyAuthentication yes PasswordAuthentication no PermitEmptyPasswords no MaxAuthTries 3 LoginGraceTime 60 # Limites de sessão e mitigação de força bruta MaxSessions 3 MaxStartups 10:30:60 # Timeouts e keepalive ClientAliveInterval 300 ClientAliveCountMax 2 # Redução de superfície X11Forwarding no # Porta (atenção: pode ser ignorada se ssh.socket estiver ativo) Port 2222

3. Valide a sintaxe e aplique as mudanças

Valide a configuração:

sudo sshd -t

Se não houver saída, a sintaxe está ok.

Perigo: não feche sua sessão atual ainda. Mantenha este terminal aberto como plano de contingência.

Reinicie o serviço:

sudo systemctl restart ssh

Verifique em quais portas o SSH está ouvindo:

sudo ss -tlnp | grep ssh

Se aparecer :2222, a mudança de porta já está valendo. Se ainda estiver na porta :22, siga para o passo de Socket Activation.

Passo 3: configurando porta personalizada (o jeito certo)

Se o ssh.socket estiver ativo, você precisa ajustar o socket do systemd, porque ele controla a escuta da porta.

1. Crie um override do socket

Abra o editor de override:

sudo systemctl edit ssh.socket

Cole o conteúdo abaixo:

[Socket] ListenStream= ListenStream=0.0.0.0:2222 ListenStream=[::]:2222

A linha ListenStream= vazia limpa a configuração padrão antes de definir a nova porta.

2. Recarregue o systemd e reinicie o socket

Não pule o reload:

sudo systemctl daemon-reload

Reinicie o socket:

sudo systemctl restart ssh.socket

Confirme a nova porta:

sudo ss -tlnp | grep ssh

Passo 4: firewall e validação

1. Libere a porta no UFW

Permita a porta 2222/tcp:

sudo ufw allow 2222/tcp comment 'SSH custom port'

Habilite o UFW (se ainda não estiver ativo):

sudo ufw enable

Liste as regras:

sudo ufw status numbered

Se você já liberou a porta 22 anteriormente, remova a regra antiga:

sudo ufw delete allow 22/tcp

2. Teste antes de encerrar a sessão atual

Teste do cliente para o servidor usando a porta nova:

ssh -p 2222 sempreupdate@ssh-server

Confirme que senha está desativada (o teste deve falhar):

ssh -p 2222 -o PubkeyAuthentication=no sempreupdate@ssh-server

Confirme que login de root está bloqueado (o teste deve falhar):

ssh -p 2222 root@ssh-server

Confirme a porta ativa no servidor:

sudo ss -tlnp | grep ssh

Confira configurações efetivas (visão consolidada do daemon):

sudo sshd -T | grep -E "^(port|passwordauthentication|permitrootlogin|allowusers)"

Quando todos os testes estiverem corretos, aí sim você pode encerrar com segurança a sessão antiga.

Checklist final “production ready”

• Chaves configuradas e testadas com ssh (sem depender de senha).
• Hardening aplicado via /etc/ssh/sshd_config.d/00-hardening.conf.
• PasswordAuthentication no e PermitRootLogin no ativos.
• Porta 2222 em uso.
• Se ssh.socket está ativo, a porta foi trocada via systemctl edit ssh.socket, com systemctl daemon-reload.
• UFW liberando apenas 2222/tcp, sem regra antiga para 22/tcp.