Tailscale permite conectar por SSH a un servidor sin IP pública ni puertos abiertos en el router. Ejecutas tailscale up en el servidor, inicias sesión con la misma cuenta en la app de Tailscale del móvil y te conectas a la dirección 100.x del equipo o a su nombre MagicDNS. Las ACL deciden quién llega y con qué usuario.
Cómo instalar Tailscale y ejecutar tailscale up en un servidor Linux
tailscale up une la máquina a tu tailnet y muestra una URL de inicio de sesión. Tras autenticarte, el equipo recibe una dirección 100.x. En Linux, el script oficial instala el paquete y el servicio:
curl -fsSL https://tailscale.com/install.sh | sh
sudo tailscale up
tailscale ip -4
tailscale statustailscale ip -4 muestra la dirección IPv4 de la tailnet y tailscale status lista el resto de equipos con su nombre y su estado. El tráfico entre nodos viaja cifrado sobre WireGuard. Cada nodo inicia la conexión hacia fuera, así que no hace falta redirigir el puerto TCP 22 en el router ni tener IP pública.
En macOS, iOS y Android no se escribe tailscale up: se instala la app de Tailscale y se inicia sesión desde su interfaz.
Direcciones 100.x y MagicDNS en Tailscale: a qué host apunta tu cliente SSH
Cada nodo de Tailscale recibe una dirección del rango 100.64.0.0/10, que solo es alcanzable dentro de tu tailnet. MagicDNS le asigna además un nombre igual al del equipo. Desde cualquier cliente SSH valen las tres formas:
ssh [email protected]
ssh deploy@servidor
ssh [email protected]El nombre corto es el más cómodo. Si no resuelve en algún dispositivo, usa el nombre completo en .ts.net. Conviene guardar la conexión con el nombre MagicDNS y no con la IP: si el nodo se vuelve a registrar y cambia de dirección, el nombre sigue apuntando al equipo correcto.
Si prefieres no depender de Tailscale, Prialo, red privada en malla resuelve el mismo problema: llegar a equipos sin abrir puertos.
Tailscale SSH frente a OpenSSH con claves: tabla comparativa
sudo tailscale set --ssh activa Tailscale SSH en el servidor. A partir de ahí, Tailscale atiende las conexiones al puerto 22 que llegan por la tailnet y autentica con la identidad de tu cuenta, sin claves en authorized_keys. La alternativa es mantener OpenSSH con claves y usar Tailscale solo como red.
| Qué se mide | OpenSSH con claves sobre Tailscale | Tailscale SSH |
|---|---|---|
| Autenticación | Clave Ed25519 o RSA en authorized_keys | Identidad de la cuenta de Tailscale |
| Quién decide el acceso | sshd y authorized_keys de cada servidor | Sección ssh del archivo de ACL |
| Volver a autenticarse | No existe de serie | La acción check obliga a reconfirmar el inicio de sesión |
| Si Tailscale no está disponible | La clave sigue valiendo desde la red local | No hay acceso por esa vía |
| Cliente en iOS/Android | Cualquier cliente SSH con la clave cargada | Cualquier cliente SSH conectado a la tailnet |
Si te quedas con claves, usa Ed25519: OpenSSH la admite desde la versión 6.5 (enero de 2014) y las ed25519-sk con llave FIDO2 desde la 8.2. En termi1 la clave se puede generar en el propio móvil y se guarda en el almacén seguro del sistema; la clave privada no sale del dispositivo.
ACL de Tailscale para SSH: limitar quién entra y con qué usuario
El archivo de políticas de Tailscale tiene dos capas: acls decide quién alcanza el puerto 22 y ssh decide quién usa Tailscale SSH y como qué usuario local. Este ejemplo deja entrar solo al grupo de administradores, y únicamente como deploy, en los servidores etiquetados como producción:
{
"groups": { "group:admins": ["[email protected]"] },
"tagOwners": { "tag:prod": ["group:admins"] },
"acls": [
{ "action": "accept", "src": ["group:admins"], "dst": ["tag:prod:22"] }
],
"ssh": [
{ "action": "check", "src": ["group:admins"], "dst": ["tag:prod"], "users": ["deploy"] }
]
}La etiqueta se aplica al servidor con la opción --advertise-tags=tag:prod de tailscale up. Con "action": "accept" la entrada es directa; con "check" Tailscale pide reconfirmar la identidad antes de abrir la sesión. Los detalles de cada campo están en la documentación oficial de Tailscale SSH.
Mosh, tmux y SFTP sobre Tailscale desde el móvil con termi1
Mosh arranca mosh-server mediante una conexión SSH inicial y después usa UDP, por defecto en los puertos 60000-61000. Dentro de la tailnet esos puertos tampoco requieren abrirse en el router:
mosh deploy@servidor
tmux new -A -s maintermi1 mantiene la sesión con Mosh al pasar de wifi a datos, y tmux conserva lo que dejaste corriendo para cuando vuelvas. Mosh no hace port forwarding ni X11 forwarding: si necesitas un túnel, abre una sesión SSH aparte. El teclado de termi1 trae Esc, Ctrl, Tab y flechas para manejar tmux, y el SFTP integrado permite subir o bajar archivos por la misma dirección MagicDNS sin salir de la sesión.
Si etiquetas en termi1 como producción las conexiones a servidores tag:prod, Production Guard impide que la IA pulse Intro en ellas y retiene antes del prompt lo que borra, detiene o cambia algo. La app está en la App Store para iPhone y en Google Play.
4 errores al conectar por SSH a través de Tailscale
- La app de Tailscale del móvil está desconectada. Si la VPN de Tailscale no está activa, ni las direcciones 100.x ni MagicDNS resuelven, y el cliente SSH agota el tiempo de espera.
- Repetir
tailscale upcon otras opciones.tailscale upespera que repitas todas las opciones no predeterminadas que ya habías usado. Para cambiar solo una, usatailscale set. - Dejar el puerto 22 abierto en la interfaz pública. Con ufw, permite la interfaz de la tailnet y elimina después la regla general:
sudo ufw allow in on tailscale0ysudo ufw delete allow 22/tcp. Comprueba antes que entras por Tailscale. - Permisos incorrectos con OpenSSH. sshd rechaza la clave si
~/.sshno tiene permisos 700 o siauthorized_keysno tiene 600.
Preguntas frecuentes
¿Tailscale necesita abrir puertos en el router para usar SSH?
Tailscale no necesita abrir puertos en el router para SSH. Cada nodo establece la conexión hacia fuera y el tráfico viaja cifrado sobre WireGuard dentro de la tailnet. Basta con que el servidor y el móvil hayan iniciado sesión en la misma cuenta y que las ACL permitan el puerto 22.
¿Qué diferencia hay entre Tailscale SSH y SSH con claves?
Tailscale SSH autentica con la identidad de la cuenta de Tailscale y aplica las reglas de la sección ssh de las ACL, sin claves en authorized_keys. SSH con claves usa OpenSSH normal sobre la tailnet y sigue funcionando desde la red local aunque Tailscale no esté disponible.
¿Funciona Mosh a través de Tailscale?
Mosh funciona a través de Tailscale: arranca mosh-server con una conexión SSH inicial y luego usa UDP, por defecto en los puertos 60000-61000, dentro de la tailnet. No hay que abrir esos puertos en el router, aunque el cortafuegos local del servidor debe permitirlos en la interfaz de Tailscale.
¿Puedo usar MagicDNS en lugar de la dirección 100.x?
MagicDNS asigna a cada equipo de la tailnet un nombre igual al de la máquina, así que puedes escribir ssh deploy@servidor en lugar de la dirección 100.x. Si el nombre corto no resuelve, usa el nombre completo terminado en .ts.net que aparece en el panel de Tailscale.