Una ruta de administración basada en Tor para su VPS

01Proteja tanto la administración como el proceso de compra

Pedir un servidor a través de un navegador protegido no protege automáticamente una sesión posterior de SSH. Un inicio de sesión directo puede revelar su dirección de origen al servidor y a las redes a lo largo de la ruta. Decida cómo funcionará la administración antes de la primera conexión, incluido el acceso de emergencia si falla la ruta preferida.

Tor puede ocultar la IP directa del cliente al destino, pero no es un remedio para credenciales reutilizadas, datos de configuración identificables o cualquier ataque de correlación de tráfico. También añade latencia. El objetivo útil es una ruta de administración consistente cuyo comportamiento usted entienda y pueda verificar.

02Comience con un cliente Tor local que funcione

Un demonio Tor del sistema comúnmente ofrece SOCKS en 127.0.0.1:9050, mientras que el navegador Tor comúnmente usa 9150. Verifique su configuración real en lugar de asumir cualquiera de los dos puertos. La aplicación debe enviar su conexión a través de ese proxy; abrir el navegador Tor no enruta todos los programas de la computadora.

En sistemas compatibles, torsocks envuelve aplicaciones como SSH y enruta las llamadas de red compatibles a través de Tor. Pruebe la configuración con una dirección de ejemplo solo para documentación reemplazada por la dirección real de su servidor. El siguiente comando asume un demonio Tor del sistema en ejecución y una cuenta administrativa dedicada.

torsocks ssh -i ~/.ssh/silentvps_ed25519 [email protected]

03Haga que la ruta forme parte de la configuración de SSH

Para el uso habitual, una configuración por host reduce la posibilidad de olvidar un envoltorio. El siguiente ejemplo usa una implementación de netcat con soporte de proxy SOCKS5. Las implementaciones difieren, así que confirme las opciones -x y -X en su versión instalada y verifique si la resolución de nombres de host es remota.

IdentitiesOnly limita las claves ofrecidas al servidor; combínelo con una clave nueva usada para este proyecto. Compruebe y conserve la huella de la clave de host del servidor a través de un canal de aprovisionamiento de confianza. Tor cambia la ruta de red, pero la autenticación de host de SSH sigue siendo esencial.

Host silent-admin
    HostName 203.0.113.45
    User admin
    IdentityFile ~/.ssh/silentvps_ed25519
    IdentitiesOnly yes
    ProxyCommand nc -X 5 -x 127.0.0.1:9050 %h %p

04Mueva SSH detrás de un servicio onion

Un endpoint onion permite la administración sin un puerto SSH accesible públicamente y evita usar una salida Tor para esta conexión. Instale y configure Tor en el servidor, luego asigne un puerto virtual onion al servicio SSH local. El ejemplo es una configuración inicial; las rutas de servicio y los comandos varían según la distribución.

Después de que Tor cree el directorio del servicio, obtenga su archivo de nombre de host de forma privada y pruebe una conexión a través del proxy de su cliente. Mantenga privadas las claves de identidad del servicio onion. Solo después de un inicio de sesión independiente exitoso debe restringir SSH a localhost y eliminar el acceso público. Verifique que su consola de recuperación funcione antes de hacer ese cambio.

HiddenServiceDir /var/lib/tor/silent-admin/
HiddenServicePort 22 127.0.0.1:22

05Añada autorización de cliente para un endpoint privado

Sin autorización adicional, cualquiera que conozca la dirección onion puede llegar al servicio y a su SSH prompt. Tor v3 autorización de cliente añade una puerta criptográfica separada: el servicio tiene la clave pública del cliente autorizado y el cliente posee la clave privada correspondiente.

Sigue las instrucciones actuales del Proyecto Tor para los formatos de claves y el directorio authorized_clients. Verifica que un cliente no autorizado no pueda conectarse. Mantén también la autenticación por clave SSH, y planifica cómo revocar la autorización de un dispositivo perdido sin perder tu propio acceso restante.

06Prueba DNS y evita la filtración de identidad

Una consulta de nombre de host realizada por el resolutor local puede revelar tu objetivo antes de que la conexión llegue al proxy. Usar la IP del servidor para un destino de clearnet evita esa consulta concreta; los nombres onion requieren resolución dentro de Tor. Para otros nombres de host, confirma el comportamiento remoto-DNS de la aplicación en lugar de confiar en una configuración de proxy genérica.

El sistema invitado aún puede conservar marcas de tiempo de autenticación, nombres de usuario y entradas de diario. Revisa su retención de forma intencionada en lugar de desactivar a ciegas todos los diagnósticos. Inspecciona también los nombres de host locales, los metadatos de confirmaciones y la configuración copiada en busca de detalles identificativos. Tor no elimina esos datos del tráfico de la aplicación.

• Usa una clave dedicada y un flujo de trabajo de proyecto aislado.
• Verifica el puerto SOCKS esperado y el comportamiento remoto DNS.
• Mantén el acceso de recuperación y un segundo inicio de sesión probado antes de cambiar los listeners.
• Revisa el servicio Tor y SSH después de las actualizaciones.
• Nunca compartas las claves de identidad onion ni los secretos de autorización de clientes.

07Mantén prácticas las sesiones largas y el mantenimiento futuro

Ejecuta trabajos administrativos largos dentro de tmux o screen para que una interrupción de la conexión no destruya la sesión. Los circuitos Tor y las condiciones de red pueden cambiar, así que mantén los comandos repetibles y comprende cómo reanudarlos. Una pequeña cantidad de latencia adicional es más fácil de tolerar cuando el mantenimiento está planificado.

El mismo patrón onion puede estar delante de un panel local o un servicio Git privado. Cada aplicación sigue necesitando autenticación, actualizaciones de software y una configuración cuidadosa. Sigue usando la ruta protegida para soporte, renovación y copias de seguridad donde tus requisitos de privacidad lo exijan; la consistencia importa tanto como la configuración inicial.