Configurar SSH sobre un servicio onion de Tor

Qué cambia al usar SSH sobre un servicio onion de Tor

SSH sobre un servicio onion de Tor le permite administrar un VPS que no acepta conexiones entrantes en ningún puerto. El servidor se conecta a la red Tor y mantiene esa conexión abierta. Su sesión SSH llega a través de ella, por lo que no es necesario que nada escuche en la dirección IP pública.

El efecto en el registro es inmediato. Un equipo con un puerto SSH público recibe miles de intentos fallidos de contraseña al día por parte de escáneres. Mueva sshd detrás de un servicio onion y bloquee el tráfico entrante en el firewall; /var/log/auth.log registrará entonces únicamente las sesiones que usted haya iniciado.

El inconveniente es que tor se interpone en el camino de cada sesión de administración. Es un daemon de espacio de usuario que debe iniciarse y configurarse después de cada reinicio antes de que pueda iniciar sesión. Planifique esto antes de cerrar el puerto, ya que el modo de fallo aquí es perder el acceso a una máquina a la que no puede acceder físicamente.

Obtenga una vía de acceso antes de modificar nada

No comience hasta tener una ruta de recuperación que no dependa de SSH.

Abra la consola de su proveedor ahora, ya sea la consola VNC o serie en el panel de control, e inicie sesión. Si desconoce la contraseña de root, restablezca la contraseña de root desde el panel primero y confirme que funciona. Una consola que nunca ha probado no es una ruta de recuperación válida.

El orden a continuación es importante. Cada paso debe verificarse antes de ejecutar el siguiente, y el puerto 22 debe permanecer abierto hasta que la ruta onion funcione.

1. Instale tor y confirme que se inicia correctamente.
2. Defina el servicio onion y obtenga la dirección.
3. Conéctese a través de la red onion mientras el puerto 22 sigue abierto.
4. Añada la autorización de cliente y vuelva a conectarse.
5. Vincule sshd a la interfaz loopback y cierre el puerto 22.
6. Reinicie y conéctese de nuevo a través de la red onion.

Mantenga su sesión SSH actual abierta durante todo el proceso. Una sesión establecida sobrevive a un cambio en el firewall que bloquearía una nueva conexión, por lo que es su primera línea de rescate.

Instalar tor en el servidor

Ubuntu incluye tor en su propio repositorio, pero esa versión suele estar desactualizada. El repositorio de The Tor Project contiene la versión que describe su documentación. Añádalo con los comandos de su guía de repositorios 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

Escriba /etc/apt/sources.list.d/tor.sources. Suites utiliza el nombre en clave de su versión, el cual lsb_release -cs imprime (noble en 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

El registro debería terminar con Bootstrapped 100% (done). Si se queda bloqueado antes de ese punto, significa que tor no puede acceder a la red, lo cual casi siempre se debe a una regla de firewall de salida o a un reloj mal configurado.

El nombre de la unidad es una trampa. systemctl status tor informa de Active: active (exited) incluso cuando todo funciona correctamente, porque Debian y Ubuntu empaquetan tor como una unidad maestra multi-instancia cuya única función es cargar la instancia real. El daemon en sí se ejecuta como tor@default.service. Utilice ese nombre para status y para journalctl. Las acciones de inicio, parada y recarga de tor sí llegan a la instancia, por lo que sudo systemctl reload tor funciona como usted espera.

Definir el servicio onion para el puerto 22

Añada dos líneas a /etc/tor/torrc.

HiddenServiceDir /var/lib/tor/ssh/
HiddenServicePort 22 127.0.0.1:22

La segunda línea indica a tor que acepte el puerto virtual 22 en la dirección onion y que se conecte a 127.0.0.1:22 en el equipo. Tor contacta con sshd a través de loopback, que es precisamente la razón por la que sshd puede dejar de escuchar en la dirección pública más adelante.

sudo systemctl reload tor
sudo cat /var/lib/tor/ssh/hostname

Esto imprime 56 caracteres en base32 seguidos de .onion. Dichos caracteres son la clave pública del servicio en formato codificado. No existen autoridades de certificación ni registros de nombres en este proceso.

Deje que tor cree /var/lib/tor/ssh/ por sí mismo. Si lo crea manualmente con un propietario incorrecto o con un modo menos restrictivo que 0700, tor se negará a utilizarlo y el registro (journal) informará de que el directorio tiene permisos excesivos. Los archivos del interior constituyen la identidad del servicio: hs_ed25519_secret_key es la dirección. Realice una copia de seguridad de ese directorio con modo 600 y mantenga la copia fuera del equipo, ya que perderlo implica obtener una nueva dirección y editar la configuración en cada cliente.

Conexión desde su estación de trabajo

Su estación de trabajo necesita un cliente Tor, el cual no requiere ninguna configuración. En Debian o Ubuntu, este es sudo apt install -y tor netcat-openbsd. Tor escucha entonces en 127.0.0.1:9050 como un proxy SOCKS5. SOCKS es un protocolo de proxy genérico, y la versión 5 puede transportar un nombre de host en lugar de una dirección IP, que es la parte importante en este caso.

OpenSSH no posee un cliente SOCKS propio, por lo que un programa auxiliar realiza la conexión. Añada esto 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 selecciona SOCKS5 y -x 127.0.0.1:9050 apunta al Tor local. %h entrega el nombre onion a Tor como un nombre, de modo que Tor lo resuelve dentro de la red. Esto debe ser el netcat de OpenBSD. El netcat de GNU no tiene la opción -X y se detiene con nc: invalid option -- 'X'.

ssh myvps

La primera conexión es lenta, porque Tor construye un circuito antes de que ocurra cualquier otra cosa. Acepte la huella digital de la clave del host de la misma manera que lo haría en cualquier otro lugar. A partir de aquí, se aplica el manejo habitual de claves SSH sin cambios. El transporte cambió. La autenticación no.

Para una conexión puntual puede omitir la entrada de configuración: torsocks ssh admin@xxxxx.onion realiza la misma tarea.

Añadir autorización de cliente v3

Tal como está, cualquiera que conozca la dirección puede acceder a su banner SSH y comenzar a intentar adivinar credenciales. Las direcciones Onion no pueden enumerarse desde el sistema de directorios, por lo que la dirección actúa como un secreto, pero se filtra de formas comunes: historial de shell y archivos de configuración subidos a un repositorio git. La autorización de cliente cierra esa brecha. El servicio publica su descriptor cifrado con una clave de cliente, de modo que alguien que tenga la dirección pero no la clave ni siquiera puede localizar el servicio.

Genere un par de claves x25519 en el cliente. Esta es la secuencia de comandos de la guía de autorización de cliente del Tor Project, con un cambio.

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

La versión publicada de esas líneas utiliza base64pem -d, que una instalación estándar de Ubuntu no incluye. El comando se detiene entonces con base64pem: command not found. GNU base64 -d decodifica el mismo cuerpo PEM, así que utilícelo en su lugar.

En el servidor, instale la clave 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

Solo se leen los archivos que terminan en .auth. Si lo guarda como laptop.auth.txt, tor ignora el archivo sin mostrar ningún error y el servicio permanece abierto para cualquiera que tenga la dirección.

En el cliente, instale la clave privada. En Ubuntu, el demonio tor se ejecuta como el usuario debian-tor y no puede leer archivos en su directorio personal, así que mantenga el directorio en una ubicación a la que dicho usuario tenga acceso.

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

Añada ClientOnionAuthDir /var/lib/tor/onion_auth al archivo /etc/tor/torrc del cliente y recargue tor. Si ejecuta tor como su propio usuario, por ejemplo con la compilación de Homebrew en macOS, apunte ClientOnionAuthDir a ~/.tor/onion_auth con modo 0700.

La dirección dentro de ese archivo son los 56 caracteres sin el sufijo .onion. Elimine /tmp/k1.prv.pem y /tmp/k1.prv.key cuando haya terminado.

Ahora pruebe ambas direcciones. ssh myvps debería seguir conectando. Desde una máquina que no posea la clave, la misma dirección debería fallar. Ese fallo es su prueba de que la autorización está activa.

Cerrar el puerto 22, en este orden

Establezca primero una red de seguridad. Este comando deshace ambos cambios descritos a continuación después de quince minutos si se bloquea el acceso a sí mismo.

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 la tarea con sudo systemctl stop ssh-rescue.timer una vez que haya confirmado que la ruta de Tor sigue funcionando.

A continuación, detenga la escucha de sshd en la dirección pública. Ubuntu 24.04 activa ssh mediante una unidad de socket, por lo que ListenAddress en sshd_config se ignora: ssh.socket es el propietario del socket de escucha, no sshd. Compruebe en qué caso se encuentra.

systemctl is-enabled ssh.socket

Si esto devuelve enabled, ejecute sudo systemctl edit ssh.socket y añada lo siguiente.

[Socket]
ListenStream=
ListenStream=127.0.0.1:22

El valor vacío en ListenStream= limpia el valor heredado de la unidad empaquetada. Si omite esa línea, añadirá un segundo oyente mientras mantiene el público, que es la forma más común en la que este paso falla sin previo aviso.

sudo systemctl daemon-reload
sudo systemctl restart ssh.socket
ss -tlnp | grep ':22'

ss debería mostrar 127.0.0.1:22 y nada en 0.0.0.0:22. Si ssh.socket estaba desactivado, coloque ListenAddress 127.0.0.1 en /etc/ssh/sshd_config.d/10-onion.conf, ejecute sudo systemctl restart ssh y, a continuación, verifique con la misma línea ss. Esa salida es la prueba en ambos casos.

Luego el firewall, que es el habitual gestión de reglas ufw en un VPS. Ejecute sudo ufw status numbered primero y elimine cualquier regla SSH que aparezca en la lista.

sudo ufw status numbered
sudo ufw delete allow OpenSSH
sudo ufw default allow outgoing
sudo ufw default deny incoming
sudo ufw status verbose

Mantenga permitido el tráfico saliente. Tor se conecta a los repetidores a través de puertos como el 443 y el 9001, por lo que una política de denegación por defecto para el tráfico saliente detiene el arranque de Tor y elimina su única vía de acceso restante al mismo tiempo. La mayoría de los proveedores también ejecutan un firewall de red independiente en el panel de control. Cierre el puerto 22 allí también, o el puerto seguirá siendo accesible independientemente de lo que informe ufw.

Si Docker se ejecuta en este equipo, compruebe sus puertos publicados antes de dar el trabajo por terminado. Docker escribe sus propias reglas en las mismas tablas y publica los puertos de los contenedores saltándose ufw, por lo que una política de denegación de ufw no ofrece una visión completa.

Reinicie antes de confiar en el servicio

systemctl is-enabled tor@default
sudo reboot

Si el primer comando no indica que el servicio está habilitado, ejecute sudo systemctl enable tor@default antes de reiniciar. Espere dos minutos y luego ejecute ssh myvps. Tor debe realizar el proceso de arranque tras el inicio del sistema, por lo que la dirección onion comenzará a responder tiempo después de que la máquina esté operativa.

Si el servicio no vuelve a estar disponible, abra la consola y lea sudo journalctl -u tor@default -b. Allí se mostrará cualquier error de sintaxis en torrc o problemas de permisos en los directorios. También puede verificar la edición de un archivo torrc antes de aplicarla.

sudo -u debian-tor tor --verify-config

Costes comparados con un túnel WireGuard

En comparación con una VPN WireGuard en su propio VPS, un servicio onion es más lento y menos predecible. Sea honesto sobre esta contrapartida antes de comprometerse con ella.

Latencia. Un circuito de cliente consta de tres nodos y el lado del servicio añade otros tres, por lo que sus pulsaciones de teclas atraviesan aproximadamente seis máquinas elegidas al azar en todo el mundo. La escritura interactiva tiene un retraso visible y las copias de archivos son lentas. WireGuard añade un solo salto. Mida su caso particular con time ssh myvps 'echo ok', ya que la cifra depende del circuito que tor haya construido y cambia cuando tor crea uno nuevo.

Un demonio en espacio de usuario en la ruta crítica. WireGuard reside en el kernel y se inicia junto con la red. Tor es un proceso que debe iniciarse, arrancar y alcanzar un nodo de guardia antes de que algo funcione. Cuando falla, usted depende de la consola del proveedor.

Precisión del reloj. Los descriptores de los servicios onion se publican en función de periodos de tiempo, por lo que un reloj mal configurado impide la resolución de direcciones sin mostrar un mensaje claro en ninguna parte. timedatectl debería informar System clock synchronized: yes.

Lo que obtiene a cambio es una exposición que ya no depende de que una regla de firewall sea correcta. No hay puertos que escanear ni banners que capturar, y la dirección es en sí misma una clave pública, por lo que el punto final demuestra su identidad incluso antes de que SSH comience.

La respuesta práctica suele ser utilizar ambos. Ejecute WireGuard como ruta diaria y mantenga el servicio onion como la ruta que sigue funcionando cuando la configuración de WireGuard es incorrecta. Esto deja un puerto UDP abierto en lugar de un puerto SSH público. Nada de esto sustituye a endurecer el propio sshd: la autenticación solo mediante claves y el inicio de sesión sin privilegios de root siguen siendo importantes, ya que un servicio onion protege la ruta de red y nada más allá de ella.

Modos de fallo y errores comunes

Tor nunca supera Bootstrapped 0%. El tráfico saliente está bloqueado o el reloj está desincronizado. Compruebe la política de salida con sudo ufw status verbose y, a continuación, ejecute timedatectl.

systemctl status tor muestra active (exited). Esto es normal en Debian y Ubuntu. Consulte tor@default en su lugar.

No se encuentra el descriptor. Tor devuelve el error extendido de SOCKS F0, "Onion Service Descriptor Can Not be Found". El descriptor aún no se ha publicado, lo cual tarda un breve periodo tras una recarga, o bien el proceso tor no se está ejecutando en el servidor.

F4, "Onion Service Missing Client Authorization". El cliente no tiene un .auth_private coincidente que tor pueda utilizar. Compruebe que ClientOnionAuthDir esté en torrc, que el directorio tenga permisos 0700, que el nombre del archivo termine en .auth_private y que debian-tor tenga permisos de lectura sobre él.

F5, "Onion Service Wrong Client Authorization". La clave privada no coincide con el archivo .auth en el servidor. Un = al final o un salto de línea adicional dentro de la cadena base32 provocan este error.

nc: invalid option -- 'X'. Se ha instalado GNU netcat en lugar de la versión de OpenBSD. Ejecute sudo apt install -y netcat-openbsd.

Could not resolve hostname. ssh intentó usar DNS convencional, el cual no tiene respuesta para .onion, por lo que ProxyCommand nunca se ejecutó. El patrón Host en ~/.ssh/config no coincide con el nombre que ha introducido.

Permission denied (publickey). El túnel funcionó y tor ha terminado su tarea. Trate esto como un problema ordinario de denegación de permiso de clave pública y no tenga en cuenta a tor.

FAQ

¿Un servicio onion realmente significa que no hay puertos abiertos en mi VPS?

Sí, una vez que sshd está vinculado a 127.0.0.1 y el firewall descarta el tráfico entrante. Tor establece una conexión TCP saliente hacia un repetidor y su sesión viaja de vuelta a través de él, por lo que nada en la máquina acepta una conexión en la dirección pública. Compruébelo con ss -tlnp en el servidor y un escaneo de puertos desde otro lugar. No olvide el firewall de red del proveedor en el panel de control, que es un control independiente de ufw y también debe cerrarse.

¿Es la dirección .onion suficiente seguridad por sí misma para SSH?

No. La dirección tiene 56 caracteres y no puede ser adivinada ni enumerada desde el sistema de directorios, por lo que se comporta como un secreto, pero se filtra a través del historial de la shell y los archivos de configuración. Añada autorización de cliente v3. Con ella, el descriptor del servicio se cifra con su clave de cliente, de modo que alguien que solo posea la dirección obtendrá el error extendido F4 y nunca llegará a sshd.

¿Qué sucede si tor no arranca tras un reinicio?

Pierde el acceso SSH por completo, ya que la dirección onion es entonces la única forma de entrar. Por eso debe probarse la consola del proveedor antes de cerrar el puerto 22. Tor también necesita tiempo para iniciarse después del arranque, por lo que la dirección responde más tarde de lo que la máquina responde al ping. Si nunca responde, inicie sesión en la consola y lea sudo journalctl -u tor@default -b, donde se imprime un error de sintaxis en torrc o un problema de permisos en /var/lib/tor/ssh.

¿Es SSH sobre Tor más lento que WireGuard?

Sí, por un margen amplio. Una conexión a un servicio onion atraviesa unos seis repetidores elegidos al azar, mientras que WireGuard es un salto cifrado directo a su servidor. La escritura se siente lenta y las transferencias son pausadas. Una configuración común es usar WireGuard para el trabajo diario y mantener el servicio onion como la ruta de emergencia que sobrevive a una configuración de VPN rota.