Como Conectar Seu VPS Via Tor

Anonymity · 8 min de leitura

Resposta rápida: Você pode rotear o SSH pelo Tor em duas direções: apontar seu cliente para o proxy SOCKS local do Tor para esconder seu próprio IP do servidor, ou publicar a porta SSH do VPS como um serviço onion do Tor para que o próprio servidor nunca tenha uma porta SSH alcançável na clearnet. As duas podem ser combinadas para que nenhuma das pontas da sessão toque a internet aberta. Espere uma latência bem mais alta do que em uma conexão direta, então trate isso como uma técnica de acesso administrativo para trabalho interativo em shell, não como um transporte para grandes transferências de arquivos.

Dois problemas diferentes, ambos chamados de 'SSH sobre Tor'

Quem busca acesso a vps via tor geralmente está tentando resolver um de dois problemas distintos, e a configuração muda dependendo de qual se aplica. O primeiro é do lado do cliente: você quer esconder seu próprio endereço IP do servidor, de quem estiver observando sua rede local e de quem futuramente intimar os logs de conexão do provedor do VPS. O segundo é do lado do servidor: você quer que o próprio VPS não tenha nenhuma porta SSH alcançável pela internet pública, para que não possa ser encontrado por um scanner de portas, alvo de um bot de credential-stuffing ou geolocalizado pelo seu serviço em escuta.

Esses objetivos não são mutuamente excludentes. Boa parte da confusão em fóruns sobre ssh sobre tor vem de misturar 'quero esconder quem está se conectando' com 'quero esconder a que estou me conectando'. Este guia cobre os dois casos, começando pela configuração mais simples do lado do cliente, depois a abordagem de serviço onion para o servidor, e então como reforçar o resultado e qual desempenho esperar de fato.

Anonimato do lado do cliente: seu cliente SSH passa pelo Tor, então o servidor (e quem registrar suas conexões de entrada) vê um relay ou nó de saída do Tor, não seu IP real
Anonimato do lado do servidor: o sshd só é alcançável por um endereço onion do Tor, então não existe IP:porta público para SSH algum

Método 1: roteie seu cliente SSH pelo proxy SOCKS do Tor

Um cliente Tor em execução (o daemon Tor, não necessariamente o Tor Browser) expõe um proxy SOCKS5 local, por padrão em 127.0.0.1:9050. Qualquer aplicação compatível com SOCKS pode ser apontada para ele, e o SSH em si não fala SOCKS nativamente, então você precisa de uma pequena ponte. As duas abordagens comuns são o torsocks, que encapsula um comando e força suas conexões TCP pelo proxy, e uma entrada ProxyCommand na sua configuração de SSH que encaminha a conexão por um netcat compatível com SOCKS.

O teste mais rápido é simplesmente: instale o tor, confirme que está rodando e execute torsocks ssh usuario@ip-do-seu-vps. Se conectar, sua sessão SSH agora está roteada por um circuito Tor de três saltos. Para algo que você vai usar diariamente, adicione um bloco Host ao ~/.ssh/config em vez de digitar torsocks toda vez, usando uma linha ProxyCommand como nc -X 5 -x 127.0.0.1:9050 %h %p (com o netcat do OpenBSD) ou connect -S 127.0.0.1:9050 %h %p (com a ferramenta connect-proxy). Assim, um simples ssh meuhost funciona e sempre passa pelo Tor, sem que você precise lembrar do wrapper.

Verifique se o Tor está realmente rodando e escutando na porta 9050 antes de investigar o próprio SSH
torsocks ssh usuario@host é a forma mais rápida de testar; um ProxyCommand no ~/.ssh/config é a forma durável de usar isso no dia a dia
Esse método esconde seu IP do VPS e de quem ler seus logs de autenticação, mas a própria porta SSH continua aberta para a internet pública

Método 2: publique o SSH como um serviço onion do Tor no VPS

Se o objetivo é manter o próprio endereço IP do VPS totalmente fora da equação para acesso administrativo, o servidor precisa rodar o Tor e expor o sshd apenas como um serviço oculto. Instale o tor no VPS e adicione duas linhas ao torrc: HiddenServiceDir apontando para um diretório em que o Tor possa escrever, e HiddenServicePort 22 127.0.0.1:22, que diz ao Tor para encaminhar as conexões que chegam na porta 22 do endereço onion para o sshd escutando localmente. Reinicie o Tor, e ele gera um hostname .onion longo e aleatório nesse diretório na primeira vez que iniciar.

Crucialmente, esse passo só elimina a exposição se o sshd também for configurado para escutar em 127.0.0.1 em vez da interface pública do VPS (ListenAddress 127.0.0.1 no sshd_config, depois reinicie o sshd). Pular essa etapa deixa o SSH alcançável tanto pelo endereço onion quanto diretamente pelo IP público, o que anula o propósito. Feito isso, conecte pelo lado do cliente com torsocks ssh [email protected] — nenhum endereço IPv4 ou IPv6 público para SSH aparecerá em uma varredura de portas do VPS.

Adicione HiddenServiceDir e HiddenServicePort 22 127.0.0.1:22 ao torrc, depois reinicie o Tor
Configure o próprio sshd para escutar apenas em 127.0.0.1 — um serviço onion na frente de uma porta ainda pública não esconde nada
Leia o arquivo de hostname gerado dentro do HiddenServiceDir para obter o endereço .onion ao qual se conectar
Conecte com torsocks ssh [email protected]; um IP puro deixará de funcionar para SSH por completo

Travando a autenticação depois que o SSH só responde em .onion

Esconder a porta não substitui reforçar o login. Use pares de chaves ed25519, desative completamente a autenticação por senha (PasswordAuthentication no) e desative o login root via SSH (PermitRootLogin no). Se a chave que você usa para acessar esse VPS é a mesma que usa nas suas contas do dia a dia, o anonimato ganho pelo serviço onion é anulado no momento em que a impressão digital dessa chave aparece em um vazamento de dados ou em uma varredura do Shodan/Censys ligada ao seu nome em outro lugar — gere uma chave dedicada para infraestrutura anônima.

Uma coisa que silenciosamente para de funcionar nessa configuração: ferramentas baseadas em IP como o fail2ban. Como as conexões chegam ao sshd via o processo local do Tor, o endereço de origem que o sshd registra é 127.0.0.1 para toda tentativa de login, bem ou malsucedida — não há IP de invasor para bloquear. Isso não é uma lacuna que você precise preencher com um workaround: a autenticação apenas por chave, sem fallback de senha, já elimina o risco de força bruta que o fail2ban existe para mitigar. Apenas não espere que os logs dele sejam úteis nessa configuração.

Autenticação apenas por chave, ed25519, sem fallback de senha
Um par de chaves dedicado por servidor anônimo, nunca reutilizado de uma máquina pessoal
PermitRootLogin no, e uma conta não-root com sudo para o trabalho real
Não conte com fail2ban ou allowlisting de IP depois que o tráfego chega via Tor — o IP de origem nos logs sempre será o loopback

Como o desempenho realmente se comporta

Um circuito Tor padrão tem três relays, e uma conexão de serviço onion empilha dois circuitos de três saltos de ponta a ponta (um do cliente para dentro da rede Tor, outro da rede Tor até o serviço oculto), então a latência de ida e volta costuma ficar em algum ponto entre algumas centenas de milissegundos e alguns segundos, com picos ocasionais quando um circuito é reconstruído. Trabalho interativo — editar arquivos de configuração, checar logs, reiniciar um serviço — é totalmente utilizável nessa latência. Configure o ServerAliveInterval na sua configuração de SSH para que sessões ociosas não sejam derrubadas pelo salto extra, e espere paradas ocasionais enquanto o Tor escolhe um novo circuito.

O que não funciona bem é a vazão. scp, rsync ou qualquer coisa que mova gigabytes vai arrastar em comparação a uma conexão direta, porque os circuitos do Tor são otimizados para interatividade de baixa latência em muitos fluxos curtos, não para largura de banda sustentada. Para transferência de dados de verdade — backups, uploads grandes — use um canal criptografado direto (SSH/rsync comum pelo IP público, ou um túnel WireGuard) e reserve o caminho via Tor especificamente para acesso administrativo em shell, onde esconder a conexão importa mais do que a velocidade.

Erros que silenciosamente quebram o anonimato que você buscava

A maioria das falhas aqui não é exótica — são pequenas lacunas de configuração que deixam uma porta lateral aberta. Fique atento a estas antes de confiar na configuração:

Nenhuma delas exige ferramentas avançadas para evitar; basta checar as portas realmente em escuta e o comportamento de DNS uma vez, em vez de assumir que a configuração do Tor sozinha resolveu tudo.

sshd ainda vinculado à interface pública ao lado do serviço onion, então a porta 'oculta' também é encontrável por uma varredura de portas comum
Resolver hostnames fora do Tor (uma consulta DNS avulsa, ou uma aplicação que ignora o proxy SOCKS para DNS) vaza para qual host você está prestes a se conectar antes mesmo de a conexão Tor começar
Um ProxyCommand que silenciosamente cai para uma conexão direta se o Tor não estiver rodando — configure-o para falhar fechado, não aberto, para que um daemon Tor morto signifique nenhuma conexão em vez de uma conexão acidental na clearnet
Reutilizar uma chave SSH, prompt de terminal ou histórico de shell que ligue essa sessão de volta a uma identidade não anônima em outro lugar

Comparação de métodos de acesso SSH
Método	O que esconde	Latência adicional típica	Esforço de configuração
SSH direto pela clearnet	Nada além da própria criptografia do SSH	Nenhuma	Nenhum
Cliente roteado pelo proxy SOCKS do Tor	Seu endereço IP, do servidor e de seus logs	Moderada — aproximadamente um circuito Tor, ~300ms-1s	Baixo — torsocks ou uma linha ProxyCommand
SSH publicado como serviço onion do Tor	O IP público do VPS; nenhuma porta SSH aberta na internet	Moderada a alta — circuito adicional do lado do servidor	Médio — mudanças em torrc e sshd_config
Ambos combinados: cliente via Tor, servidor como serviço onion	As duas pontas da conexão ficam totalmente fora da clearnet	A mais alta — dois circuitos independentes de 3 saltos	Médio

Perguntas frequentes

SSH sobre Tor enfraquece a criptografia do SSH?+

Não. O SSH negocia seu próprio canal de criptografia ponta a ponta independentemente do transporte que o carrega. O Tor adiciona sua própria camada de criptografia de circuito por cima, então o tráfego é criptografado duas vezes, não uma vez com algo mais fraco.

SSH sobre Tor é lento demais para trabalho de administração real?+

Para sessões interativas de shell — editar arquivos, checar logs, reiniciar serviços — a latência adicional é perceptível, mas administrável. Para transferências em massa como backups ou uploads grandes, use uma conexão direta ou WireGuard e reserve o caminho via Tor para acesso administrativo.

Ainda dá para usar fail2ban se o SSH só é alcançável via um serviço onion?+

Não de forma significativa. As conexões chegam ao sshd a partir do processo local do Tor, então toda tentativa de login é registrada como vinda de 127.0.0.1. Confie em autenticação apenas por chave, sem fallback de senha, já que isso elimina o risco de força bruta que o fail2ban deveria mitigar.

Preciso de uma VPN além do Tor para acessar o VPS?+

Geralmente não. Encadear uma VPN comercial na frente do Tor basicamente realoca a confiança para o provedor de VPN, sem adicionar proteção real para esse uso. Tor sozinho para a sessão SSH, ou um túnel WireGuard quando a latência importa mais do que rotear pela rede Tor, cobre os casos práticos.

As duas pontas precisam rodar Tor, ou só o meu notebook?+

Apenas seu cliente precisa rodar o Tor para esconder seu próprio IP do servidor (Método 1). Esconder o IP do servidor também exige que o VPS rode Tor e publique o sshd como um serviço onion (Método 2) — as duas configurações são independentes e podem ser usadas separadamente ou juntas.

Pronto para ir offshore?

Sem KYC, sem e-mail — apenas uma chave anônima e cripto. Implante em ~55 segundos.

Configure sua VPS →