SSH via Tor onion sem abrir portas no VPS

O que muda ao usar SSH através de um serviço onion do Tor

O SSH através de um serviço onion do Tor permite administrar um VPS que não aceita ligações de entrada em nenhuma porta. O servidor inicia uma ligação à rede Tor e mantém essa ligação aberta. A sua sessão SSH regressa por essa ligação, pelo que nada precisa de escutar no endereço IP público.

O efeito nos logs é imediato. Um servidor com uma porta SSH pública recebe milhares de tentativas de palavra-passe falhadas por dia, feitas por scanners. Ao colocar sshd atrás de um serviço onion e bloquear o tráfego de entrada na firewall, /var/log/auth.log passa a registar apenas as sessões que iniciou.

O custo é que tor fica no caminho de todas as sessões de administração. É um daemon em userspace que tem de arrancar e estabelecer a ligação depois de cada reboot, antes de poder iniciar sessão. Planeie essa situação antes de fechar a porta, porque uma falha neste ponto pode causar a perda de acesso a uma máquina à qual não pode chegar fisicamente.

Obtenha um caminho de recuperação antes de alterar qualquer coisa

Não comece até ter um caminho de recuperação que não use SSH.

Abra agora a consola do seu fornecedor, a consola VNC ou serial no painel de controlo, e inicie sessão através dela. Se não souber a palavra-passe de root, reponha primeiro a palavra-passe de root no painel e confirme que funciona. Uma consola que nunca testou não é um caminho de recuperação.

A ordem abaixo é importante. Cada passo é validado antes de o seguinte ser executado, e a porta 22 permanece aberta até a rota onion funcionar.

1. Instale tor e confirme que conclui o bootstrap.
2. Defina o serviço onion e leia o endereço.
3. Ligue-se através da onion enquanto a porta 22 ainda estiver aberta.
4. Adicione a autorização do cliente e ligue-se novamente.
5. Faça o bind de sshd ao loopback e feche a porta 22.
6. Reinicie o sistema e ligue-se novamente através da onion.

Mantenha a sessão SSH atual aberta durante todo o processo. Uma sessão estabelecida continua ativa mesmo que uma alteração da firewall impeça novas ligações, por isso é a sua primeira linha de recuperação.

Instalar o tor no servidor

O Ubuntu inclui o tor no seu próprio repositório, mas essa versão costuma estar desatualizada. O repositório do Tor Project disponibiliza a versão descrita na documentação do projeto. Adicione-o com os comandos do guia do repositório apt.

sudo apt update
sudo apt install -y apt-transport-https wget gpg
wget -qO- https://deb.torproject.org/torproject.org/A3C4F0F979CAA22CDBA8F512EE8CBC9E886DDD89.asc | gpg --dearmor | sudo tee /usr/share/keyrings/deb.torproject.org-keyring.gpg >/dev/null

Escreva /etc/apt/sources.list.d/tor.sources. Suites usa o nome de código da sua versão, que lsb_release -cs apresenta (noble no Ubuntu 24.04).

Types: deb deb-src
URIs: https://deb.torproject.org/torproject.org/
Suites: noble
Components: main
Signed-By: /usr/share/keyrings/deb.torproject.org-keyring.gpg

sudo apt update
sudo apt install -y tor deb.torproject.org-keyring
sudo journalctl -u tor@default -n 20 --no-pager

O log deve terminar com Bootstrapped 100% (done). Se ficar parado antes disso, o tor não consegue alcançar a rede. Quase sempre, isso deve-se a uma regra de firewall para tráfego de saída ou a um relógio com uma hora muito incorreta.

O nome da unidade é uma armadilha. systemctl status tor apresenta Active: active (exited) mesmo quando tudo está a funcionar corretamente, porque o Debian e o Ubuntu empacotam o tor como uma unidade mestre de várias instâncias, cuja única função é carregar a instância real. O daemon é executado como tor@default.service. Use esse nome em status e em journalctl. Iniciar, parar e recarregar tor também alcança a instância, por isso sudo systemctl reload tor funciona como esperado.

Defina o serviço onion para a porta 22

Adicione duas linhas a /etc/tor/torrc.

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22

A segunda linha instrui o tor a aceitar a porta virtual 22 no endereço onion e a ligar-se a 127.0.0.1:22 no servidor. O tor alcança o sshd através do loopback. É exatamente por isso que o sshd pode deixar de escutar no endereço público mais tarde. Aponte essa segunda linha para um servidor Web em 127.0.0.1:80 e as mesmas duas diretivas publicam um site num endereço onion, o que é um segundo serviço útil para executar depois de instalar o tor.

sudo systemctl reload tor
sudo cat /var/lib/tor/ssh/hostname

Isto apresenta 56 caracteres base32 seguidos de .onion. Esses caracteres são a chave pública do serviço em formato codificado. Não existe uma autoridade de certificação nem qualquer registo de nome neste processo.

Deixe o tor criar /var/lib/tor/ssh/. Se o criar manualmente com o proprietário errado ou com um modo mais permissivo que 0700, o tor recusa-se a utilizá-lo e o journal indica que o diretório tem permissões demasiado permissivas. Os ficheiros no interior são a identidade do serviço: hs_ed25519_secret_key é o endereço. Faça uma cópia de segurança desse diretório com o modo 600 e mantenha a cópia fora do servidor, porque a sua perda implica um novo endereço e uma alteração de configuração em todos os clientes.

Conecte-se a partir da sua estação de trabalho

A sua estação de trabalho precisa de um cliente Tor, que não requer qualquer configuração. No Debian ou Ubuntu, o pacote é sudo apt install -y tor netcat-openbsd. O Tor passa então a escutar em 127.0.0.1:9050 como um proxy SOCKS5. SOCKS é um protocolo de proxy genérico. A versão 5 pode transportar um nome de host em vez de um endereço IP. É essa capacidade que importa aqui.

O OpenSSH não inclui um cliente SOCKS próprio. Por isso, um programa auxiliar faz a ligação. Adicione isto a ~/.ssh/config.

Host myvps
  HostName xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.onion
  User admin
  ProxyCommand /usr/bin/nc -X 5 -x 127.0.0.1:9050 %h %p
  ServerAliveInterval 30

-X 5 seleciona SOCKS5 e -x 127.0.0.1:9050 aponta para o Tor local. %h envia o nome onion para o Tor como um nome, para que o Tor o resolva dentro da rede. Este comando tem de ser o netcat do OpenBSD. O netcat GNU não tem a opção -X e termina com nc: invalid option -- 'X'.

ssh myvps

A primeira ligação é lenta porque o Tor cria um circuito antes de qualquer outra operação. Aceite a impressão digital da chave do host como faria em qualquer outro caso. A partir daqui, o procedimento habitual de gestão de chaves SSH aplica-se sem alterações. O transporte mudou. A autenticação não.

Para uma utilização pontual, pode ignorar a entrada de configuração: torsocks ssh admin@xxxxx.onion faz o mesmo.

Adicionar autorização de cliente v3

No estado atual, qualquer pessoa que descubra o endereço pode alcançar o banner SSH e começar a tentar adivinhar credenciais. Os endereços Onion não podem ser enumerados pelo sistema de diretórios, por isso o endereço funciona como um segredo, mas pode vazar de formas comuns: no histórico do shell e em ficheiros de configuração enviados para um repositório git. A autorização de cliente elimina essa falha. O serviço publica o seu descritor encriptado para uma chave de cliente, por isso alguém que tenha apenas o endereço, sem a chave, nem sequer consegue localizar o serviço.

Gere um par de chaves x25519 no cliente. Este é o pipeline do guia de autorização de cliente do Tor Project, com uma alteração.

openssl genpkey -algorithm x25519 -out /tmp/k1.prv.pem
grep -v " PRIVATE KEY" /tmp/k1.prv.pem | base64 -d | tail --bytes=32 | base32 | sed 's/=//g' > /tmp/k1.prv.key
openssl pkey -in /tmp/k1.prv.pem -pubout | grep -v " PUBLIC KEY" | base64 -d | tail --bytes=32 | base32 | sed 's/=//g' > /tmp/k1.pub.key

A versão publicada dessas linhas usa base64pem -d, que uma instalação normal do Ubuntu não inclui. O comando termina então com base64pem: command not found. O GNU base64 -d descodifica o mesmo corpo PEM, por isso use-o.

No servidor, instale a chave pública.

sudo install -d -m 700 -o debian-tor -g debian-tor /var/lib/tor/ssh/authorized_clients
echo "descriptor:x25519:PASTE_PUBLIC_KEY_HERE" | sudo tee /var/lib/tor/ssh/authorized_clients/laptop.auth >/dev/null
sudo chown debian-tor:debian-tor /var/lib/tor/ssh/authorized_clients/laptop.auth
sudo systemctl reload tor

Só são lidos os ficheiros que terminam em .auth. Guarde-a como laptop.auth.txt; o tor ignora o ficheiro sem apresentar qualquer erro, e o serviço continua silenciosamente aberto a qualquer pessoa que tenha o endereço.

No cliente, instale a chave privada. No Ubuntu, o daemon tor é executado como o utilizador debian-tor e não consegue ler ficheiros no seu diretório pessoal. Por isso, mantenha o diretório num local acessível a esse utilizador.

sudo install -d -m 700 -o debian-tor -g debian-tor /var/lib/tor/onion_auth
echo "ADDRESS_WITHOUT_DOT_ONION:descriptor:x25519:PASTE_PRIVATE_KEY_HERE" | sudo tee /var/lib/tor/onion_auth/myvps.auth_private >/dev/null
sudo chown debian-tor:debian-tor /var/lib/tor/onion_auth/myvps.auth_private
sudo chmod 600 /var/lib/tor/onion_auth/myvps.auth_private

Adicione ClientOnionAuthDir /var/lib/tor/onion_auth ao /etc/tor/torrc do cliente e recarregue o tor. Se executar o tor com o seu próprio utilizador, por exemplo, através da compilação do Homebrew no macOS, aponte ClientOnionAuthDir para ~/.tor/onion_auth com o modo 0700.

O endereço dentro desse ficheiro tem 56 caracteres sem o sufixo .onion. Elimine /tmp/k1.prv.pem e /tmp/k1.prv.key quando terminar.

Agora teste as duas direções. ssh myvps ainda deve estabelecer ligação. A partir de uma máquina que não tenha a chave, o mesmo endereço deve falhar. Essa falha confirma que a autorização está ativa.

Feche a porta 22, nesta ordem

Configure primeiro uma rede de segurança. Este comando desfaz ambas as alterações abaixo após quinze minutos se perder o acesso ao servidor.

sudo systemd-run --on-active=15m --unit=ssh-rescue \
  /bin/sh -c 'ufw allow 22/tcp; rm -f /etc/systemd/system/ssh.socket.d/override.conf; systemctl daemon-reload; systemctl restart ssh.socket'

Cancele-a com sudo systemctl stop ssh-rescue.timer depois de confirmar que a rota onion continua a funcionar.

Em seguida, faça o sshd deixar de escutar no endereço público. O Ubuntu 24.04 ativa o SSH através de uma unidade de socket, por isso ListenAddress em sshd_config é ignorado: ssh.socket controla o socket de escuta, não o sshd. Verifique em que situação está.

systemctl is-enabled ssh.socket

Se o comando mostrar enabled, execute sudo systemctl edit ssh.socket e adicione isto.

[Socket]
ListenStream=
ListenStream=127.0.0.1:22

O ListenStream= vazio limpa o valor herdado da unidade fornecida pelo pacote. Se omitir essa linha, adicionará um segundo listener e manterá o público, que é a forma mais comum de esta etapa falhar sem indicar o motivo.

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
ss -tlnp | grep ':22'

ss deve mostrar 127.0.0.1:22 e nada em 0.0.0.0:22. Se ssh.socket estiver desativado, coloque ListenAddress 127.0.0.1 em /etc/ssh/sshd_config.d/10-onion.conf, execute sudo systemctl restart ssh e verifique com a mesma linha ss. Essa saída é a prova em ambos os casos.

Depois, configure a firewall, usando a gestão normal de regras do ufw num VPS. Execute sudo ufw status numbered primeiro e elimine a regra SSH que aparecer.

sudo ufw status numbered
sudo ufw delete allow OpenSSH
sudo ufw default allow outgoing
sudo ufw default deny incoming
sudo ufw status verbose

Mantenha o tráfego de saída permitido. O Tor liga-se a relays através de portas como 443 e 9001, por isso uma política de negação de saída por predefinição impede o bootstrap do Tor e elimina, no mesmo momento, a única forma de acesso que ainda lhe resta. A maioria dos provedores também disponibiliza uma firewall de rede separada no painel de controlo. Feche a porta 22 também aí; caso contrário, a porta continuará acessível, independentemente do que o ufw indicar.

Se o Docker estiver a ser executado neste servidor, verifique as portas publicadas antes de considerar o trabalho concluído. O Docker escreve as próprias regras nas mesmas tabelas e publica diretamente as portas dos contentores, contornando o ufw, por isso uma política de negação do ufw não mostra o quadro completo.

Reinicie antes de confiar

systemctl is-enabled tor@default
sudo reboot

Se o primeiro comando não indicar o serviço como ativado, execute sudo systemctl enable tor@default antes de reiniciar. Aguarde dois minutos e execute ssh myvps. O Tor precisa de concluir o arranque depois do boot, por isso o endereço onion começa a responder algum tempo depois de a própria máquina estar operacional.

Se nunca voltar a arrancar, abra a consola e leia sudo journalctl -u tor@default -b. Um erro de sintaxe no torrc ou um problema de permissões de um diretório é apresentado aí. Também pode validar uma alteração ao torrc antes de a aplicar.

sudo -u debian-tor tor --verify-config

O custo em comparação com um túnel WireGuard

Em comparação com uma VPN WireGuard no seu próprio VPS, um serviço onion é mais lento e menos previsível. Avalie honestamente esta troca antes de o adotar.

Latência. O circuito do cliente tem três relays e o lado do serviço acrescenta mais três, por isso os seus caracteres atravessam aproximadamente seis máquinas escolhidas aleatoriamente em todo o mundo. A escrita interativa apresenta um atraso percetível e as cópias de ficheiros são lentas. O WireGuard acrescenta um salto. Meça o seu caso com time ssh myvps 'echo ok', porque o valor depende do circuito que o tor construiu e muda quando o tor constrói outro.

Um daemon em userspace no caminho crítico. O WireGuard está no kernel e inicia com a rede. O Tor é um processo que tem de iniciar, fazer bootstrap e alcançar um relay guard antes de alguma coisa funcionar. Quando falha, terá de usar a consola do fornecedor.

Precisão do relógio. Os descritores dos serviços onion são publicados com base em períodos de tempo, por isso um relógio muito incorreto impede a resolução do endereço sem apresentar uma mensagem clara. timedatectl deve apresentar System clock synchronized: yes.

O que recebe em troca é uma exposição que já não depende de uma regra de firewall estar correta. Não existe uma porta para analisar nem um banner para recolher, e o próprio endereço é uma chave pública, por isso o endpoint prova a sua identidade antes de o SSH sequer iniciar.

Na prática, a resposta costuma ser usar ambos. Execute o WireGuard como caminho diário e mantenha o serviço onion como rota que continua a funcionar quando a configuração do WireGuard está incorreta. Assim, fica aberta uma porta UDP, em vez de uma porta SSH pública. Nada disto substitui a proteção do próprio sshd: a autenticação apenas com chaves e um login que não seja root continuam a ser importantes, porque um serviço onion protege o caminho de rede e nada além dele.

Modos de falha e erros que verá

O Tor nunca passa Bootstrapped 0%. O tráfego de saída está bloqueado ou o relógio está muito adiantado ou atrasado. Verifique a política de saída com sudo ufw status verbose e, em seguida, execute timedatectl.

systemctl status tor indica active (exited). Isto é normal no Debian e no Ubuntu. Leia tor@default.

O descritor não pode ser encontrado. O Tor devolve o erro SOCKS estendido F0, "Onion Service Descriptor Can Not be Found". O descritor pode ainda não ter sido publicado, o que demora algum tempo depois de um reload, ou o tor no servidor pode não estar em execução.

F4, "Onion Service Missing Client Authorization". O cliente não tem um .auth_private correspondente que o tor possa utilizar. Confirme que ClientOnionAuthDir está no torrc, que o diretório tem o modo 0700, que o nome do ficheiro termina em .auth_private e que debian-tor consegue lê-lo.

F5, "Onion Service Wrong Client Authorization". A chave privada não corresponde ao ficheiro .auth no servidor. Um = no final ou uma quebra de linha indevida dentro da cadeia base32 causa este erro.

nc: invalid option -- 'X'. O GNU netcat está instalado em vez da versão OpenBSD. Execute sudo apt install -y netcat-openbsd.

Could not resolve hostname. O ssh tentou usar DNS normal, que não tem resposta para .onion, pelo que ProxyCommand nunca foi executado. O padrão Host em ~/.ssh/config não corresponde ao nome que introduziu.

Permission denied (publickey). O túnel funcionou e o tor terminou. Trate isto como um problema normal de permissão denied publickey e não envolva o tor na análise.

FAQ

Um serviço onion significa realmente que não existem portas abertas no meu VPS?

Sim, depois de o sshd estar associado a 127.0.0.1 e de a firewall rejeitar o tráfego de entrada. O Tor estabelece uma ligação TCP de saída para um relay, e a sua sessão regressa através dessa ligação. Assim, nenhum serviço no sistema aceita ligações no endereço público. Confirme isto com ss -tlnp no servidor e com uma análise de portas a partir de outro local. Não se esqueça da firewall de rede do próprio fornecedor no painel de controlo. É um controlo separado do ufw e também tem de estar fechado.

O endereço .onion, por si só, oferece segurança suficiente para SSH?

Não. O endereço tem 56 caracteres e não pode ser adivinhado nem enumerado através do sistema de diretórios. Por isso, comporta-se como um segredo, mas pode ser exposto pelo histórico da shell e pelos ficheiros de configuração. Adicione a autorização de cliente v3. Com esta opção, o descritor do serviço é cifrado para a chave do seu cliente. Assim, alguém que tenha apenas o endereço recebe o erro expandido F4 e nunca chega ao sshd.

O que acontece se o tor não arrancar depois de um reboot?

Perde completamente o acesso SSH, porque o endereço onion passa a ser a única forma de entrar. Por isso, a consola do fornecedor tem de ser testada antes de fechar a porta 22. O Tor também precisa de tempo para concluir o bootstrap depois do arranque. Assim, o endereço responde mais tarde do que a máquina responde ao ping. Se nunca responder, inicie sessão na consola e leia sudo journalctl -u tor@default -b. Nesse ficheiro é apresentado um erro de sintaxe do torrc ou um problema de permissões em /var/lib/tor/ssh.

O SSH através do Tor é mais lento do que o WireGuard?

Sim, por uma margem significativa. Uma ligação a um serviço onion atravessa cerca de seis relays escolhidos aleatoriamente, enquanto o WireGuard usa um único salto cifrado diretamente para o servidor. A escrita apresenta latência e as transferências são lentas. Uma configuração comum usa o WireGuard para o trabalho diário e mantém o serviço onion como rota de emergência, que continua disponível mesmo quando uma configuração VPN fica danificada.