Por el equipo de HushVPS · Actualizado 2026 · 8 min de lectura
Compraste un servidor anónimo, pagado en Monero, y te saltaste la verificación de identidad. Luego te conectas por SSH desde tu IP de casa a través de internet abierto — y entregas silenciosamente a tu ISP, a la red de tránsito y a cualquiera que observe la máquina una línea clara que va de tu cara a la máquina. Si quieres gestionar un servidor a través de Tor, el objetivo es simple: nunca dejes que un paquete de clearnet conecte tu ubicación real con la máquina que administras. Esta guía cubre las formas prácticas de alcanzar y ejecutar un VPS enteramente a través de la red Tor, y las fugas que lo deshacen silenciosamente.
Tor te da dos primitivas útiles para la administración. Puedes enrutar tu SSH saliente a través de Tor como cliente, para que tu IP real nunca toque el servidor. O puedes publicar el propio demonio SSH como un servicio onion, de modo que la máquina no tenga ningún puerto de administración expuesto en clearnet. La mayoría de los operadores cuidadosos terminan usando ambos juntos. Construiremos desde la configuración más simple hasta la más fuerte.
El aprovisionamiento anónimo solo cubre la puerta de entrada. Si te registras sin KYC y pagas con un VPS sin KYC facturado en Monero, el proveedor no tiene nombre ni tarjeta vinculados a tu cuenta, pero en el momento en que inicias sesión desde tu conexión doméstica, creas un rastro de papel nuevo y continuo. Tu ISP ve conexiones repetidas a una IP específica del centro de datos. Los logs de autenticación del propio servidor registran la dirección de origen de cada sesión. Correlaciona ambos y la anonimidad por la que pagaste se evapora.
Enrutar el tráfico de gestión a través de Tor cierra esa brecha. Tu ISP solo ve que usaste Tor; no puede ver a qué servidor llegaste. El VPS ve una salida de Tor (o un punto de encuentro, para SSH onion), nunca tu dirección. La identidad que mantuviste fuera del formulario de registro permanece fuera de la red, sesión tras sesión.
Tor protege la ruta de red. No sanitiza la máquina, la cuenta ni tus hábitos operativos. Antes de empezar, ten claro contra qué te estás defendiendo realmente: un observador pasivo en tu red local, la capacidad del proveedor para correlacionar tu IP de gestión con la máquina y los registros que sobreviven a la sesión. Tor aborda los tres. No te protege si pegas tu hostname real en una configuración, reutilizas una clave SSH que ya está vinculada a tu nombre en otro lugar o ejecutas una herramienta con fugas que resuelve DNS fuera del túnel. Mantén el modelo honesto y tomarás las decisiones correctas a continuación.
La forma más rápida de tunelizar un solo comando a través de Tor es torsocks, un envoltorio que fuerza las llamadas de red de un programa a través del proxy SOCKS local de Tor (generalmente 127.0.0.1:9050). Instala el cliente de Tor en tu estación de trabajo, asegúrate de que el daemon esté ejecutándose y luego antepone tu comando SSH:
torsocks ssh [email protected]El detalle crucial es el DNS. Un ssh hostname ingenuo resuelve el nombre en tu máquina primero, a través de tu resolver normal: una fuga clásica que le dice a tu ISP exactamente a qué proveedor te vas a conectar, antes de que Tor vea la conexión. torsocks intercepta getaddrinfo y empuja la resolución a través de Tor también, por lo que la búsqueda nunca llega a tu resolver local. Conectarse a una IP cruda evita por completo la búsqueda de nombre y es el hábito más seguro. De cualquier manera, verifica: si ves una consulta DNS para el nombre de host de tu servidor en tu propia red, el túnel no está haciendo su trabajo.
Para cualquier cosa que hagas más de una vez, integra Tor en ~/.ssh/config para que no puedas olvidar el envoltorio. Usando netcat con un proxy SOCKS, un bloque por proveedor se ve así:
Host ghost
HostName 203.0.113.10
User admin
ProxyCommand nc -x 127.0.0.1:9050 -X 5 %h %p
IdentitiesOnly yes
IdentityFile ~/.ssh/ghost_ed25519Ahora ssh ghost siempre se conecta a través del puerto SOCKS5 de Tor, y %h/%p se entregan al proxy, por lo que la resolución de nombres ocurre en la salida, no en tu máquina. Establece IdentitiesOnly yes para que tu cliente no envíe todas las claves de tu agente al servidor (lo que es tanto una huella como una pequeña fuga). Dale a cada máquina anónima su propia clave dedicada que no esté asociada con tu identidad real en ningún otro lugar, y deshabilita la autenticación por contraseña en el servidor para que una credencial adivinada no valga nada.
Una peculiaridad que vale la pena conocer: Tor añade latencia y cada nuevo circuito es una salida fresca y aleatoria, por lo que escribir interactivamente puede sentirse lento y las sesiones de larga duración ocasionalmente se caen cuando un circuito rota. Ejecutar tu trabajo dentro de tmux o screen en el servidor significa que un circuito caído te cuesta una reconexión, no tu sesión.
La postura más fuerte elimina el puerto de gestión en clearnet por completo. En lugar de exponer el puerto 22 a internet y protegerlo con firewall, ejecutas un servicio onion de Tor en el VPS que reenvía a 127.0.0.1:22. El daemon SSH entonces se vincula solo a localhost; nada responde en la IP pública. Lo alcanzas en una dirección .onion, a través de Tor, de extremo a extremo.
En el servidor, agrega un servicio onion a tu torrc apuntando al puerto SSH local:
HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22Reinicia Tor, lee el archivo hostname generado para tu .onion v3 y conéctate desde un cliente que enrute a través de Tor:
torsocks ssh [email protected]Esto tiene dos grandes ventajas. Primero, no hay un puerto SSH expuesto para que internet escanee, fuerce por fuerza bruta o tome huellas: los ataques automatizados contra el puerto 22 simplemente no tienen nada a lo que golpear. Segundo, la ubicación de la máquina está oculta del cliente y la ubicación del cliente está oculta de la máquina; el encuentro ocurre dentro de Tor. Sigue la configuración actual y autorizada de la documentación de servicios onion del Proyecto Tor en lugar de un blog antiguo, porque las directivas torrc exactas y los formatos de clave cambian entre versiones. Para un panel de administración, un panel privado o un remoto Git, el mismo patrón se aplica: publica el puerto localhost como un onion y alcánzalo a través de Tor. Nuestro tutorial sobre cómo ejecutar un servicio oculto de Tor en un VPS anónimo profundiza en ese aspecto.
Una dirección onion simple es imposible de adivinar pero no verdaderamente privada: cualquiera que aprenda el .onion puede llegar al prompt de inicio de sesión. Tor soporta autorización de cliente, donde el onion ni siquiera completará un handshake a menos que el cliente que se conecta presente una clave precompartida. Agrega la clave pública de tu cliente al directorio authorized_clients del servicio y el onion se vuelve invisible para todos los demás: sin clave, sin conexión, sin prompt. Para un endpoint de gestión que solo tú tocas, esto convierte la "seguridad a través de una dirección imposible de adivinar" en una puerta criptográfica real.
La forma más común en que las personas se filtran mientras creen que son anónimas es el DNS. Si cualquier parte de tu flujo de trabajo resuelve el nombre del servidor fuera de Tor, has anunciado tu objetivo. Prefiere conectarte por IP o .onion; cuando debas usar un hostname, asegúrate de que la resolución esté proxyada (torsocks, un ProxyCommand, o una configuración SOCKS a nivel de aplicación con DNS remoto habilitado). El explicador de la EFF sobre lo que Tor oculta y no oculta es una buena verificación de la realidad sobre dónde termina la protección.
Algunas trampas más que vale la pena nombrar:
La anonimidad no es una configuración única; es una disciplina que mantienes sesión tras sesión. La cadena solo se sostiene si cada eslabón se sostiene: registro anónimo sin KYC, pago en Monero para que no haya un libro mayor de tarjetas, una clave SSH dedicada que no esté vinculada a tu nombre, DNS que nunca escape del túnel y administración exclusivamente a través de Tor o un onion autenticado. Rompe cualquier eslabón y los demás no pueden salvarte. Mantenlos todos y simplemente no hay ningún punto en el pipeline donde tu identidad real y tu servidor se encuentren.
Root completo, sin KYC, facturación en Monero, sin logs por defecto. Trae tu propia clave, publica un onion y adminístralo sin que tu identidad toque el cable.
HushVPS es legal en una jurisdicción extraterritorial y minimiza datos, no es un territorio sin ley. Gestionar tu propia máquina a través de Tor es una práctica de privacidad normal; nuestra política de uso aceptable sigue prohibiendo CSAM, malware e infraestructura de botnets, spam y DDoS.