Cómo Conectar con tu VPS a Través de Tor

Anonymity · 8 min de lectura

Respuesta rápida: Puedes enrutar SSH a través de Tor en dos direcciones: apuntar tu cliente al proxy SOCKS local de Tor para ocultar tu propia IP al servidor, o publicar el puerto SSH del VPS como servicio onion de Tor para que el propio servidor nunca tenga un puerto SSH accesible en la red pública. Las dos técnicas se pueden combinar para que ningún extremo de la sesión toque nunca la internet abierta. Espera una latencia notablemente mayor que con una conexión directa, así que trata esto como una técnica de acceso administrativo para trabajo interactivo en shell, no como un transporte para transferencias grandes de archivos.

Dos problemas distintos, ambos llamados «SSH sobre Tor»

Quienes buscan acceso a un VPS a través de Tor suelen intentar resolver uno de dos problemas distintos, y la configuración cambia según cuál sea. El primero es del lado del cliente: quieres ocultar tu propia dirección IP al servidor, a cualquiera que esté observando tu red local, y a cualquiera que más adelante cite judicialmente los registros de conexión del proveedor VPS. El segundo es del lado del servidor: quieres que el propio VPS no tenga ningún puerto SSH accesible desde la internet pública, para que no pueda ser localizado por un escáner de puertos, atacado por un bot de relleno de credenciales ni geolocalizado por su servicio en escucha.

Estos dos problemas no se excluyen entre sí. Buena parte de la confusión en foros sobre SSH a través de Tor viene de mezclar «quiero ocultar quién se conecta» con «quiero ocultar a qué me estoy conectando». Esta guía cubre ambos, empezando por la configuración más sencilla del lado del cliente, después el enfoque de servicio onion para el servidor, y luego cómo reforzar el resultado y qué rendimiento esperar en realidad.

Anonimato del lado del cliente: tu cliente SSH pasa por Tor, así que el servidor (y quien registre sus conexiones entrantes) ve un nodo de salida o relé de Tor, no tu IP real
Anonimato del lado del servidor: sshd solo es accesible a través de una dirección onion de Tor, así que no existe ninguna IP:puerto público para SSH

Método 1: enrutar tu cliente SSH a través del proxy SOCKS de Tor

Un cliente Tor en ejecución (el demonio Tor, no necesariamente Tor Browser) expone un proxy SOCKS5 local, por defecto en 127.0.0.1:9050. Cualquier aplicación compatible con SOCKS puede apuntarse a él, y SSH en sí no habla SOCKS de forma nativa, así que hace falta un pequeño puente. Los dos enfoques habituales son torsocks, que envuelve un comando y fuerza sus conexiones TCP a través del proxy, y una entrada ProxyCommand en tu configuración SSH que canaliza la conexión a través de un netcat compatible con SOCKS.

La prueba más rápida es simplemente: instalar tor, confirmar que está en ejecución y luego lanzar torsocks ssh usuario@ip-de-tu-vps. Si conecta, tu sesión SSH ya está enrutada a través de un circuito Tor de tres saltos. Para algo que uses a diario, añade un bloque Host a ~/.ssh/config en lugar de escribir torsocks cada vez, usando una línea ProxyCommand como nc -X 5 -x 127.0.0.1:9050 %h %p (con netcat de OpenBSD) o connect -S 127.0.0.1:9050 %h %p (con la herramienta connect-proxy). Así, un simple ssh mihost funciona y pasa siempre por Tor sin que tengas que recordar el envoltorio.

Verifica que Tor esté realmente en ejecución y escuchando en el puerto 9050 antes de diagnosticar el propio SSH
torsocks ssh usuario@host es la forma más rápida de probarlo; un ProxyCommand en ~/.ssh/config es la forma duradera de usarlo día a día
Este método oculta tu IP al VPS y a quien lea sus registros de autenticación, pero el propio puerto SSH sigue abierto a la internet pública

Método 2: publicar SSH como servicio onion de Tor en el VPS

Si el objetivo es mantener la propia dirección IP del VPS completamente fuera del acceso administrativo, el servidor necesita ejecutar Tor y exponer sshd únicamente como servicio oculto. Instala tor en el VPS y añade dos líneas a torrc: HiddenServiceDir, apuntando a un directorio en el que Tor pueda escribir, y HiddenServicePort 22 127.0.0.1:22, que le indica a Tor que reenvíe las conexiones que lleguen al puerto 22 de la dirección onion hacia el sshd que escucha localmente. Reinicia Tor, y generará un nombre de host .onion largo y aleatorio en ese directorio la primera vez que arranque.

Es crucial que este paso solo elimina la exposición si además le indicas a sshd que se vincule a 127.0.0.1 en lugar de a la interfaz pública del VPS (ListenAddress 127.0.0.1 en sshd_config, y luego reiniciar sshd). Saltarte ese paso deja SSH accesible tanto a través de la dirección onion como directamente en la IP pública, lo que anula el propósito. Una vez hecho, conéctate desde el cliente con torsocks ssh [email protected]; ninguna dirección IPv4 o IPv6 pública para SSH aparecerá jamás en un escaneo de puertos del VPS.

Añade HiddenServiceDir y HiddenServicePort 22 127.0.0.1:22 a torrc, y luego reinicia Tor
Vincula el propio sshd solo a 127.0.0.1: un servicio onion delante de un puerto que sigue siendo público no oculta nada
Lee el archivo hostname generado dentro de HiddenServiceDir para obtener la dirección .onion a la que conectarte
Conéctate con torsocks ssh [email protected]; una IP a secas dejará de funcionar por completo para SSH

Blindar la autenticación una vez que SSH solo responde en .onion

Ocultar el puerto no sustituye reforzar el inicio de sesión. Usa pares de claves ed25519, desactiva por completo la autenticación por contraseña (PasswordAuthentication no) y desactiva el inicio de sesión de root por SSH (PermitRootLogin no). Si la clave que usas para llegar a este VPS es la misma que usas para tus cuentas cotidianas, el anonimato ganado con el servicio onion se anula en el momento en que la huella de esa clave aparece en una filtración de datos o en un escaneo de Shodan/Censys ligado a tu nombre en otro sitio; genera una clave dedicada para infraestructura anónima.

Hay algo que deja de funcionar silenciosamente en esta configuración: las herramientas basadas en IP como fail2ban. Como las conexiones llegan a sshd a través del proceso Tor local, la dirección de origen que registra sshd es 127.0.0.1 para cada intento de inicio de sesión, con éxito o sin él; no hay IP de atacante que bloquear. No es un hueco que necesites tapar con un workaround: la autenticación solo con clave y sin contraseña de respaldo ya elimina el riesgo de fuerza bruta que fail2ban existe para mitigar. Simplemente no esperes que sus registros signifiquen algo en esta configuración.

Autenticación solo con clave, ed25519, sin respaldo por contraseña
Un par de claves dedicado por cada servidor anónimo, nunca reutilizado de una máquina personal
PermitRootLogin no, y una cuenta sin privilegios de root con sudo para el trabajo real
No dependas de fail2ban ni de listas blancas de IP una vez que el tráfico llega a través de Tor: la IP de origen en los registros siempre es loopback

Cómo es el rendimiento en la práctica

Un circuito Tor estándar tiene tres relés, y una conexión a un servicio onion apila dos circuitos de tres saltos de extremo a extremo (uno del cliente hacia la red Tor, otro de la red Tor hasta el servicio oculto), así que la latencia de ida y vuelta suele situarse entre unos pocos cientos de milisegundos y un par de segundos, con picos ocasionales cuando se reconstruye un circuito. El trabajo interactivo, editar archivos de configuración, revisar registros, reiniciar un servicio, resulta perfectamente usable con esa latencia. Ajusta ServerAliveInterval en tu configuración SSH para que las sesiones inactivas no se corten por el salto adicional, y espera algún bloqueo ocasional mientras Tor elige un nuevo circuito.

Lo que no funciona bien es el rendimiento de transferencia. scp, rsync o cualquier cosa que mueva gigabytes irá a paso de tortuga comparado con una conexión directa, porque los circuitos de Tor están optimizados para interactividad de baja latencia en muchos flujos cortos, no para ancho de banda sostenido. Para la transferencia de datos real, copias de seguridad, subidas grandes, usa un canal cifrado directo (SSH/rsync normal sobre la IP pública, o un túnel WireGuard) y reserva la ruta Tor específicamente para el acceso administrativo por shell, donde ocultar la conexión importa más que la velocidad.

Errores que echan por tierra el anonimato sin que lo notes

La mayoría de los fallos aquí no son exóticos: son pequeños huecos de configuración que dejan una puerta trasera abierta. Vigila estos antes de confiar en la configuración:

Ninguno de ellos requiere herramientas avanzadas para evitarlos; solo requieren comprobar una vez los puertos realmente en escucha y el comportamiento del DNS, en lugar de asumir que la configuración de Tor por sí sola hizo el trabajo.

sshd sigue vinculado a la interfaz pública además del servicio onion, así que el puerto «oculto» también es localizable con un simple escaneo de puertos
Resolver nombres de host fuera de Tor (una consulta DNS perdida, o una aplicación que ignora el proxy SOCKS para el DNS) filtra a qué host estás a punto de conectarte antes incluso de que empiece la conexión Tor
Un ProxyCommand que vuelve silenciosamente a una conexión directa si Tor no está en ejecución; configúralo para que falle cerrado, no abierto, de modo que un demonio Tor caído signifique que no hay conexión en lugar de una conexión accidental por la red pública
Reutilizar una clave SSH, un prompt de terminal o un historial de shell que vincula esta sesión a una identidad no anónima en otro sitio

Comparativa de métodos de acceso SSH
Método	Qué oculta	Latencia añadida típica	Esfuerzo de configuración
SSH directo por la red pública	Nada más allá del propio cifrado de SSH	Ninguna	Ninguno
Cliente enrutado por el proxy SOCKS de Tor	Tu dirección IP, frente al servidor y sus registros	Moderada, aproximadamente un circuito Tor, ~300 ms-1 s	Baja, torsocks o una línea ProxyCommand
SSH publicado como servicio onion de Tor	La IP pública del VPS; ningún puerto SSH abierto en internet	Moderada a alta, se añade un circuito del lado del servidor	Media, cambios en torrc y sshd_config
Ambos combinados: cliente por Tor, servidor como servicio onion	Ningún extremo de la conexión toca la red pública	La más alta, dos circuitos independientes de 3 saltos	Media

Preguntas frecuentes

¿SSH sobre Tor debilita el cifrado de SSH?+

No. SSH negocia su propio canal cifrado de extremo a extremo con independencia del transporte que lo lleva. Tor añade su propia capa de cifrado de circuito por encima, así que el tráfico queda cifrado dos veces, no una sola vez con algo más débil.

¿Es SSH sobre Tor demasiado lento para trabajo de administración real?+

Para sesiones de shell interactivas, editar archivos, revisar registros, reiniciar servicios, la latencia añadida se nota pero es manejable. Para transferencias masivas como copias de seguridad o subidas grandes, usa una conexión directa o WireGuard y reserva la ruta Tor para el acceso administrativo.

¿Puedo seguir usando fail2ban si SSH solo es accesible a través de un servicio onion?+

No de forma significativa. Las conexiones llegan a sshd desde el proceso local de Tor, así que cada intento de inicio de sesión queda registrado como proveniente de 127.0.0.1. Confía en la autenticación solo con clave y sin respaldo por contraseña, ya que eso elimina el riesgo de fuerza bruta que fail2ban está pensado para abordar.

¿Necesito además una VPN además de Tor para acceder al VPS?+

Normalmente no. Encadenar una VPN comercial delante de Tor sobre todo traslada la confianza al proveedor de la VPN sin añadir protección real para este caso de uso. Tor por sí solo para la sesión SSH, o un túnel WireGuard cuando la latencia importa más que enrutar a través de la red Tor, cubre los casos prácticos.

¿Necesitan los dos extremos ejecutar Tor, o solo mi portátil?+

Solo tu cliente necesita tener Tor en ejecución para ocultar tu propia IP al servidor (Método 1). Ocultar también la IP del servidor requiere que el VPS ejecute Tor asimismo, con sshd publicado como servicio onion (Método 2); ambas configuraciones son independientes y pueden usarse por separado o combinadas.

¿Listo para ir offshore?

Sin KYC, sin correo electrónico: solo una clave anónima y cripto. Despliega en ~55 segundos.

Configura tu VPS →