Ativar SSH no Ubuntu: instalar o OpenSSH e proteger

Ativar o SSH no Ubuntu: instalar, iniciar e abrir a firewall

No Ubuntu, o SSH vem do pacote openssh-server. O Ubuntu Server propõe instalá-lo durante a configuração e quase todas as imagens de cloud ou VPS já o trazem à escuta; o Ubuntu Desktop não o instala de todo.

1. Instalar o openssh-server

sudo apt update
sudo apt install -y openssh-server

Se o pacote já estiver presente, o apt indica-o e nada é alterado. A instalação também regista um perfil de aplicação do UFW chamado OpenSSH, usado no passo 3.

2. Ativar e iniciar o serviço

sudo systemctl enable --now ssh
systemctl status ssh

No Ubuntu a unidade chama-se ssh; sshd é um alias. O enable --now inicia o daemon imediatamente e em cada arranque. Desde o Ubuntu 22.10 o sshd é ativado por socket: o ssh.socket detém a porta 22 e arranca o ssh.service na primeira ligação recebida, por isso um estado inactive (dead) com TriggeredBy: ssh.socket logo após a instalação é normal. A porta está aberta. Para uma visão mais ampla, veja como listar serviços com o systemctl.

3. Permitir o SSH na firewall UFW

O Ubuntu vem com o UFW desativado. Se o ativar, permita o SSH primeiro; ligar a firewall antes de a regra existir é a forma clássica de ficar bloqueado fora de uma máquina remota.

sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status

O ufw allow OpenSSH usa o perfil de aplicação e abre a 22/tcp. Se mais tarde mudar o sshd de porta, autorize a nova com sudo ufw allow 2222/tcp e apague a regra antiga. Descubra o endereço do servidor com hostname -I.

Ligar a partir de Windows, macOS ou Linux

Todos os sistemas operativos de secretária atuais incluem um cliente OpenSSH, e a sintaxe é idêntica em todos:

ssh username@SERVER_IP
ssh -p 2222 username@SERVER_IP      # non-default port

• Windows 10 e 11: abra o PowerShell ou o Windows Terminal e escreva o comando; o cliente OpenSSH acompanha o Windows desde 2018 (versão 1809). Se o ssh não for reconhecido, adicione-o em Definições > Aplicações > Funcionalidades opcionais.
• macOS: Terminal, o mesmo comando.
• Linux: qualquer terminal; o openssh-client está instalado por omissão no Ubuntu.

Na primeira ligação, aceite a impressão digital da chave do servidor com yes; fica guardada em ~/.ssh/known_hosts e será avisado se alguma vez mudar. Depois escreva a palavra-passe da conta. A secção seguinte substitui-a por uma chave.

Passar para a autenticação por chave

Os logins por palavra-passe são o alvo permanente das botnets; as chaves tornam essas tentativas inúteis. Gere um par de chaves Ed25519 no seu próprio computador, nunca no servidor:

ssh-keygen -t ed25519 -C "laptop-2026"

Aceite o caminho por omissão (~/.ssh/id_ed25519) e defina uma passphrase; ela cifra a chave privada em disco, e um agente SSH faz com que só a escreva uma vez por sessão. Apenas o ficheiro .pub sai da sua máquina.

Copiar a chave pública para o servidor

No macOS e no Linux, o ssh-copy-id faz isso num só passo, usando a sua palavra-passe uma última vez:

ssh-copy-id -i ~/.ssh/id_ed25519.pub username@SERVER_IP

A versão do OpenSSH para Windows não inclui o ssh-copy-id; envie a chave a partir do PowerShell:

type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh username@SERVER_IP "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

Ambos os métodos acrescentam a chave ao ~/.ssh/authorized_keys desse utilizador. As permissões contam: o sshd ignora o ficheiro em silêncio quando ~/.ssh não está em modo 700 ou quando o authorized_keys pode ser escrito por alguém além do dono. A partir de um novo terminal, ssh username@SERVER_IP deve agora autenticá-lo sem a palavra-passe da conta. Não avance para a secção seguinte enquanto isso não acontecer.

Endurecer o sshd_config: sem palavras-passe, sem root, utilizadores em lista branca

Mantenha a sessão atual aberta enquanto edita; se a nova configuração partir alguma coisa, é o seu caminho de regresso. O /etc/ssh/sshd_config começa por Include /etc/ssh/sshd_config.d/*.conf, e o sshd guarda o primeiro valor que lê para cada palavra-chave, por isso um drop-in prevalece sobre tudo o que venha mais abaixo no ficheiro principal. Além disso, as imagens de cloud incluem frequentemente /etc/ssh/sshd_config.d/50-cloud-init.conf com PasswordAuthentication yes, e é por isso que editar o ficheiro principal parece tantas vezes não ter efeito. A solução é um drop-in cujo nome fique em primeiro na ordenação:

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

Cole o seguinte, substituindo username pelo seu próprio login:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no
AllowUsers username
MaxAuthTries 3
LoginGraceTime 30
X11Forwarding no
ClientAliveInterval 300
ClientAliveCountMax 2

O PermitRootLogin no pressupõe que tem uma conta sem privilégios com direitos de sudo. Se até aqui tem trabalhado como root, crie um utilizador sudo no Linux e copie a sua chave para ele antes de aplicar o ficheiro. Depois valide a sintaxe, recarregue e verifique os valores que o sshd usa realmente depois de todos os includes serem combinados, que é o que o sshd -T imprime:

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin|allowusers|port'

Abra um segundo terminal e autentique-se com a sua chave antes de fechar o primeiro. O que faz cada diretiva:

O keepalive também tem um lado cliente: ServerAliveInterval 60 em ~/.ssh/config na sua máquina impede que os routers NAT derrubem sessões inativas.

Mudar a porta do SSH não é segurança

Tirar o sshd da porta 22 é um conselho popular. O que ganha com isso são menos linhas de registo. Os scanners em massa varrem as 65 535 portas e encontram o sshd na 2222 em poucas horas; quem o tenha como alvo encontra-a em segundos com o nmap. As chaves, a proibição do login de root, uma lista branca e o fail2ban é que são segurança; a porta é cosmética. Ainda assim ajuda num servidor movimentado por manter o registo de autenticação legível — só nunca a conte como uma camada de defesa.

Se a mudar mesmo, respeite esta ordem: abra a nova porta no UFW, altere a porta, reinicie, teste a partir de um segundo terminal e só depois remova a regra antiga. Descomente #Port 22 em /etc/ssh/sshd_config, defina a nova porta e depois:

sudo ufw allow 2222/tcp
sudo sshd -t
sudo systemctl daemon-reload
sudo systemctl restart ssh.socket    # Ubuntu 22.10 and later
sudo systemctl restart ssh           # Ubuntu 22.04 and earlier

Nas versões com ativação por socket, é a unidade socket, e não o sshd, que decide qual a porta associada; o Ubuntu inclui um gerador do systemd que lê Port da configuração do sshd durante o daemon-reload e atualiza o ssh.socket. Confirme com sudo ss -tlnp | grep sshd. O guia sobre como verificar portas abertas no Linux explica o resultado. Se o sshd insistir em ficar na 22, desative a ativação por socket e deixe o serviço associar a porta ele próprio: sudo systemctl disable --now ssh.socket && sudo systemctl enable --now ssh.service. Assim que ssh -p 2222 funcionar a partir de um terminal novo, execute sudo ufw delete allow OpenSSH.

Adicionar o fail2ban e ponderar a autenticação de dois fatores

Com as palavras-passe desativadas, a força bruta não pode ter êxito, mas cada tentativa continua a custar um fork e uma linha de registo. O fail2ban vigia o registo de autenticação e bloqueia os endereços que falham repetidamente:

sudo apt install -y fail2ban
sudo nano /etc/fail2ban/jail.local

Coloque isto no ficheiro:

[sshd]
enabled = true
port = ssh
backend = systemd
maxretry = 5
findtime = 10m
bantime = 1h

sudo systemctl enable --now fail2ban
sudo fail2ban-client status sshd

Nunca edite o jail.conf; ele é substituído nas atualizações e o jail.local sobrepõe-se-lhe. O port = ssh é resolvido através de /etc/services, por isso escreva port = 2222 se mudou o daemon de porta. O backend = systemd lê o journal diretamente e funciona quer a sua imagem escreva ou não em /var/log/auth.log. O fail2ban-client status sshd lista os endereços bloqueados; sudo fail2ban-client set sshd unbanip 203.0.113.7 liberta um. Por omissão, as regras do fail2ban são avaliadas antes das do UFW, pelo que os dois coexistem.

Autenticação de dois fatores

Quando uma chave com passphrase não chega, o libpam-google-authenticator acrescenta um código temporal por cima da chave: instale-o, execute google-authenticator com o utilizador de login, acrescente auth required pam_google_authenticator.so a /etc/pam.d/sshd (e comente a linha @include common-auth), depois defina KbdInteractiveAuthentication yes e AuthenticationMethods publickey,keyboard-interactive no sshd. É um ganho real contra um portátil roubado, e mais uma coisa que pode perder: guarde os códigos de recuperação fora do servidor.

Resolução de problemas: connection refused, timed out, permission denied

Connection refused

O servidor respondeu mas nada está à escuta nessa porta: o sshd está parado, associado a outra porta, ou escreveu a porta errada. A partir da consola do fornecedor, execute systemctl status ssh e sudo ss -tlnp | grep ssh. Um erro de sintaxe impede o sshd de arrancar; o sudo sshd -t imprime a linha problemática e o journalctl -u ssh -n 50 mostra o último arranque.

Connection timed out

Os pacotes são descartados, não recusados, o que quase sempre significa uma firewall: o UFW sem a regra de autorização (sudo ufw status verbose), um grupo de segurança no painel do fornecedor, ou a sua própria rede a bloquear a saída na porta 22. Um hotspot do telemóvel exclui essa hipótese. O ssh -v username@SERVER_IP mostra onde o handshake bloqueia.

Permission denied (publickey)

O servidor está acessível e está a recusá-lo. Verifique, por esta ordem: o nome de utilizador, se o authorized_keys desse utilizador contém a chave que está a apresentar (ssh -i ~/.ssh/id_ed25519 -v força uma chave específica), as permissões de ~/.ssh, e se o login está em falta em AllowUsers. No servidor, o journalctl -u ssh -n 30 indica o motivo; Authentication refused: bad ownership or modes é o problema de permissões descrito atrás.

Aviso de chave de anfitrião

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED depois de uma reinstalação é esperado: execute ssh-keygen -R SERVER_IP e volte a ligar-se. Se não reinstalou nada, descubra porquê antes de escrever uma palavra-passe seja onde for. Ficou totalmente bloqueado? A consola do fornecedor é o caminho de regresso.

Tudo o que fica acima pressupõe uma máquina onde detém o root e pode dar-se ao luxo de partir o sshd e repará-lo a partir de uma consola. Um VPS Linux da rdp.monster é exatamente essa máquina: acesso root total, CPU e RAM dedicados, largura de banda ilimitada (fair-use), sem KYC, pagamento em cripto ou moeda fiduciária, a partir de $8.99 por mês, e o servidor fica online cerca de 10 segundos após a confirmação do pagamento, tempo de sobra para instalar as chaves antes de o primeiro scanner descobrir a porta 22.

Perguntas frequentes

O Ubuntu vem com o SSH ativado por omissão?

O Ubuntu Desktop não; o Ubuntu Server e a maioria das imagens de cloud sim.

O Ubuntu Desktop instala apenas o cliente SSH, por isso nada fica à escuta na porta 22 até executar sudo apt install openssh-server. O Ubuntu Server pergunta durante a instalação se quer instalar o servidor OpenSSH e pode importar as suas chaves do GitHub ou do Launchpad ao mesmo tempo. As imagens de cloud e de VPS quase sempre trazem o openssh-server instalado, ativado e a aceitar ligações, porque é a única forma de o fornecedor lhe entregar a máquina. Verifique com systemctl status ssh.

Como verifico se o SSH está a correr no Ubuntu?

Execute systemctl status ssh e depois confirme com o ss que a porta 22 está à escuta.

O systemctl status ssh diz-lhe se o serviço está ativo ou ativado no arranque. Como o Ubuntu 22.10 e posteriores usam ativação por socket, o serviço pode legitimamente aparecer como inactive (dead) com TriggeredBy: ssh.socket quando ninguém está ligado, por isso o teste mais fiável é sudo ss -tlnp | grep ssh: uma linha com 0.0.0.0:22 ou [::]:22 significa que o SSH está à escuta. A partir de outra máquina, ssh -v username@SERVER_IP confirma-o de ponta a ponta.

É seguro deixar o SSH na porta 22?

Sim, desde que as palavras-passe estejam desativadas e se usem chaves; o número da porta não acrescenta proteção.

A porta 22 atrai tentativas de login automatizadas constantes, mas essas tentativas não podem ter êxito contra um servidor com PasswordAuthentication no e um par de chaves, e o fail2ban elimina a maior parte do ruído. Mudar o sshd para 2222 ou 22222 esconde-o apenas dos scanners mais preguiçosos; scanners de portas como o nmap e o masscan encontram-no em minutos, e os índices à escala da internet listam-no de qualquer forma. Trate uma porta não predefinida como uma medida de higiene dos registos, não como um controlo de segurança, e nunca dispense as chaves por ter mudado a porta.

Qual é a diferença entre ssh e sshd no Ubuntu?

ssh é o programa cliente; sshd é o daemon do servidor, cuja unidade no Ubuntu se chama ssh, com sshd como alias.

O ssh é o cliente que executa no seu portátil para abrir uma ligação; vem do pacote openssh-client. O sshd é o daemon que responde no servidor, do openssh-server, configurado em /etc/ssh/sshd_config (o cliente lê o ssh_config). O Ubuntu e o Debian chamam ssh.service à unidade systemd e declaram sshd.service como alias, pelo que systemctl restart ssh e systemctl restart sshd fazem o mesmo; no Fedora, RHEL e Arch a unidade chama-se simplesmente sshd.