SSD Nodes Learn 🎉 VPS desde $5.50/mês
Guias Matt ConnorPor Matt Connor · Atualizado 2026-08-13

SSH por serviço onion do Tor sem abrir portas

Configure o sshd atrás de um serviço onion do Tor, com autorização de cliente v3 e a ordem correta para evitar bloqueio ao fechar a porta pública.

O que muda ao usar SSH por 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 estabelece uma ligação de saída para a rede Tor e mantém essa ligação aberta. A 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 provenientes de scanners. Coloque sshd atrás de um serviço onion e bloqueie o tráfego de entrada na firewall. Depois disso, /var/log/auth.log regista apenas as sessões que iniciou.

O custo é que tor fica no percurso de todas as sessões de administração. É um daemon em espaço de utilizador que tem de arrancar e concluir o bootstrap depois de cada reboot, antes de poder iniciar sessão. Planeie esta dependência antes de fechar a porta, porque, neste caso, uma falha pode causar a perda de acesso a uma máquina à qual não consegue aceder fisicamente.

Obtenha uma forma de voltar a entrar antes de alterar qualquer coisa

Não avance até ter um caminho de recuperação que não utilize SSH.

Abra agora a consola do seu fornecedor, a consola VNC ou série 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 arranque.
  2. Defina o serviço onion e leia o endereço.
  3. Ligue-se através da onion enquanto a porta 22 ainda está 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 e ligue-se novamente através da onion.

Mantenha a sessão SSH atual aberta durante todo o processo. Uma sessão estabelecida sobrevive a uma alteração da firewall que bloquearia uma nova sessão, 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 codinome da sua versão, que lsb_release -cs mostra (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 aceder à rede. Quase sempre a causa é uma regra de firewall para tráfego de saída ou um relógio muito incorreto.

O nome da unidade é uma armadilha. systemctl status tor mostra 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 é iniciar a instância real. O daemon é executado como tor@default.service. Use esse nome em status e em journalctl. Os comandos de iniciar, parar e recarregar tor continuam a alcançar 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 acede ao sshd através do loopback. É precisamente por isso que o sshd pode deixar de escutar no endereço público mais tarde.

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 um registo de nome.

Deixe o tor criar /var/lib/tor/ssh/. Se o criar manualmente com o proprietário errado ou com permissões mais permissivas que 0700, o tor recusa-se a utilizá-lo e o journal indica que o diretório tem permissões demasiado permissivas. Os ficheiros nele contidos representam 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 perdê-lo significa obter um novo endereço e editar a configuração em todos os clientes.

Conectar 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, esse cliente é sudo apt install -y tor netcat-openbsd. O Tor passa então a escutar em 127.0.0.1:9050 como proxy SOCKS5. SOCKS é um protocolo de proxy genérico, e 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 tem um cliente SOCKS próprio, por isso um programa auxiliar estabelece 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 entrega o nome onion ao Tor como nome, para que o Tor o resolva dentro da rede. Tem de ser o netcat do OpenBSD. O GNU netcat 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 outra ligação. A partir daqui, a gestão habitual das chaves SSH aplica-se sem alterações. O transporte mudou. A autenticação não mudou.

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

Adicionar a autorização de clientes v3

Neste momento, 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, pelo que o endereço funciona como um segredo, mas pode ser exposto de formas comuns: no histórico da shell e em ficheiros de configuração submetidos para um repositório git. A autorização de clientes elimina essa falha. O serviço publica o seu descritor encriptado para uma chave de cliente. Assim, alguém que tenha o endereço, mas não tenha 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 clientes 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 em seu lugar.

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

Apenas são lidos os ficheiros que terminam em .auth. Guarde-a como laptop.auth.txt. Caso contrário, o tor ignora o ficheiro sem apresentar nenhum 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 como o seu próprio utilizador, por exemplo com a compilação do Homebrew no macOS, aponte ClientOnionAuthDir para ~/.tor/onion_auth com o modo 0700.

O endereço dentro desse ficheiro tem os 56 caracteres sem o sufixo .onion. Apague /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 nenhuma 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 as duas 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-o 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, portanto ListenAddress em sshd_config é ignorado: ssh.socket é responsável pelo socket de escuta, não o sshd. Verifique em que caso se encontra.

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. Esta é a forma mais comum de esta etapa falhar sem indicar o problema.

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 novamente com a mesma linha ss. Esse resultado é a prova em qualquer dos casos.

Depois, configure o firewall. Trata-se da gestão normal de regras do ufw num VPS. Execute sudo ufw status numbered primeiro e elimine a regra SSH que ele listar.

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 aos relays através de portas como 443 e 9001. Uma política de negação por predefinição para o tráfego de saída impede o bootstrap do Tor e elimina, ao mesmo tempo, a única forma restante de acesso. A maioria dos fornecedores também disponibiliza um firewall de rede separado no painel de controlo. Feche a porta 22 aí também. Caso contrário, a porta continuará acessível, independentemente do que o ufw indicar.

Se o Docker for executado neste servidor, verifique as portas publicadas antes de concluir a tarefa. O Docker escreve as próprias regras nas mesmas tabelas e publica as portas dos contentores diretamente através do ufw, portanto uma política de negação do ufw não mostra o quadro completo.

Reinicie antes de confiar nele

systemctl is-enabled tor@default
sudo reboot

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

Se o serviço 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 no diretório é apresentado nesse local. Também pode verificar 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 desvantagem antes de o adotar.

Latência. O circuito do cliente tem três relays, e o lado do serviço acrescenta mais três. Assim, os seus caracteres atravessam aproximadamente seis máquinas escolhidas aleatoriamente em todo o mundo. A introdução de texto interativa apresenta um atraso visí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 qualquer operação funcionar. Quando falha, fica dependente da 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 indicar System clock synchronized: yes.

Em contrapartida, a exposição deixa de depender de uma regra de firewall estar correta. Não existe uma porta para analisar nem um banner para recolher. Além disso, o endereço é uma chave pública, pelo que o endpoint comprova a sua identidade antes de o SSH sequer iniciar.

Na prática, normalmente a melhor opção é usar ambos. Execute o WireGuard como caminho diário e mantenha o serviço onion como rota de recurso, para continuar a funcionar quando a configuração do WireGuard estiver incorreta. Assim, mantém uma porta UDP aberta 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 use root continuam a ser importantes, porque um serviço onion protege o caminho de rede, mas não oferece proteção além dele.

Modos de falha e erros apresentados

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

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

Não é possível encontrar o descritor. O Tor devolve o erro SOCKS estendido F0, "Onion Service Descriptor Can Not be Found". O descritor ainda pode 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 se ClientOnionAuthDir está no torrc, se o diretório tem o modo 0700, se o nome do ficheiro termina em .auth_private e se 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'. Está instalado o GNU netcat em vez do OpenBSD netcat. Execute sudo apt install -y netcat-openbsd.

Could not resolve hostname. O ssh tentou usar DNS normal, que não tem resposta para .onion, por isso 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ões publickey negado e não envolva o tor na análise.

FAQ

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

Sim, depois de o sshd estar associado a 127.0.0.1 e de a firewall bloquear 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 dele. Assim, nada no servidor aceita ligações no endereço público. Confirme isso 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 ser fechado.

O endereço .onion fornece, por si só, 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, pelo que funciona como um segredo. No entanto, pode ser exposto pelo histórico da shell e por ficheiros de configuração. Adicione a autorização de cliente v3. Com essa autorização, o descritor do serviço é encriptado para a chave do cliente. Assim, alguém que tenha apenas o endereço recebe o erro prolongado 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 acesso. Por isso, a consola do fornecedor tem de ser testada antes de fechar a porta 22. O Tor também precisa de tempo para arrancar após o boot, pelo que o endereço responde mais tarde do que a máquina responde ao ping. Se nunca responder, inicie sessão através da consola e consulte sudo journalctl -u tor@default -b. Nesse ficheiro aparece 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 encriptado diretamente até ao servidor. A utilização da shell fica mais lenta e as transferências demoram mais. Uma configuração comum usa o WireGuard no trabalho diário e mantém o serviço onion como rota de emergência, capaz de funcionar mesmo quando a configuração da VPN fica danificada.