Servidor SFTP-only con chroot: guía de configuración segura

📅 Publicado el 10 de octubre, 2026 · Por Equipo RedServicio

Un servidor SFTP-only con chroot es, en mi experiencia, la manera más sensata de dejar que usuarios externos suban y bajen archivos sin entregarles un shell completo. El FTP tradicional manda credenciales y datos en texto plano (sí, todavía hay quien lo usa). SFTP, en cambio, cifra toda la comunicación, y el enjaulado con chroot encierra a cada usuario en su propio directorio. Que no husmee. Que no vea nada más allá de su carpeta.

¿Qué es un servidor SFTP-only con chroot y por qué usarlo?

SFTP (SSH File Transfer Protocol) trabaja sobre el puerto 22 y se apoya en la infraestructura de SSH para autenticar y cifrar los datos. Al montar un servidor SFTP-only, limitas a ciertos usuarios a una sola cosa: transferir archivos. Nada de ejecutar comandos, nada de reiniciar servicios, nada de pasearse por el sistema.

El chroot es lo que convierte todo esto en algo realmente seguro. La directiva ChrootDirectory de OpenSSH hace que el usuario crea que su directorio asignado es la raíz (/) del sistema. Si intenta llegar a /etc/passwd o a cualquier otra ruta del servidor, no podrá. Ahí se acaba su mundo. Y punto.

¿Cuándo tiene sentido esto? Los casos más habituales:

• Clientes que suben contenido a su web sin peligro de tocar archivos de otros usuarios.
• Intercambio seguro de archivos con proveedores o colaboradores externos.
• Backups automatizados de aplicaciones que solo necesitan escribir en una carpeta concreta.
• Reemplazo del FTP clásico, que transmite credenciales y datos sin cifrar.

Requisitos previos y verificación de OpenSSH

Antes de tocar nada, conviene confirmar unas cosas:

1. Un servidor Linux (Debian, Ubuntu, CentOS, AlmaLinux o similar) con acceso root o mediante sudo.
2. OpenSSH versión 4.9 o superior. Fue la primera en incluir la directiva ChrootDirectory para el subsistema SFTP.
3. Acceso por SSH al servidor para editar la configuración.

Comprueba la versión instalada:

ssh -V

Deberías ver algo como OpenSSH_8.9p1, OpenSSL 3.0.2. Cualquier versión posterior a 4.9 sirve. Es raro encontrar hoy distribuciones con versiones tan viejas, pero si te toca, actualiza antes de seguir:

• En Debian/Ubuntu: sudo apt update && sudo apt upgrade openssh-server
• En RHEL/CentOS/AlmaLinux: sudo dnf update openssh-server

Una cosa que aprenderás pronto o tarde (mejor pronto): haz copia del fichero de configuración antes de modificarlo. Cuando algo falla a las dos de la mañana, agradecerás poder volver atrás en segundos:

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Creación del usuario SFTP y del directorio enjaulado

Crear el grupo y el usuario

Lo más limpio es agrupar a todos los usuarios SFTP en un grupo específico, digamos sftpusers, y aplicarles la configuración de una sola vez:

sudo groupadd sftpusers

sudo useradd -g sftpusers -d /uploads -s /sbin/nologin cliente1

sudo passwd cliente1

Dos detalles que conviene no pasar por alto: la opción -s /sbin/nologin bloquea el inicio de sesión por shell, y el directorio home apunta a /uploads, un subdirectorio que crearemos dentro de la jaula.

Estructura del directorio chroot

Aquí hay una peculiaridad de OpenSSH que despista a más de uno. La ruta indicada en ChrootDirectory debe pertenecer a root y no ser escribible por otros usuarios. Es decir: la jaula en sí no puede ser escribible por el usuario. La solución de siempre es crear un subdirectorio escribible dentro de ella:

• sudo mkdir -p /data/cliente1/uploads
• sudo chown root:root /data/cliente1
• sudo chmod 755 /data/cliente1
• sudo chown cliente1:sftpusers /data/cliente1/uploads

Resultado: cliente1 queda enjaulado en /data/cliente1 (propiedad de root, solo lectura para él) y solo puede escribir dentro de uploads, que es donde de verdad subirá y bajará archivos. Verifica los permisos con ls -la /data/cliente1 antes de pasar a la configuración de sshd, que veremos en la siguiente parte de esta guía.

Configuración del sshd_config: bloque Match y ForceCommand internal-sftp

Con los directorios listos, toca tocar la configuración del servidor SSH. Abre /etc/ssh/sshd_config con tu editor (nano, vim, el que uses a diario) y añade al final un bloque Match. Esto es, básicamente, el corazón del asunto:

Match Group sftpusers
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no
    PermitTunnel no

¿Y qué hace cada directiva exactamente? Vamos una por una:

• Match Group sftpusers: las reglas solo afectan a los usuarios de ese grupo. El resto de conexiones SSH del servidor siguen funcionando igual que siempre.
• ChrootDirectory %h: encierra al usuario en su propio home (%h). Desde su punto de vista, ese directorio es la raíz «/» del sistema. No verá nada más allá, porque para él no existe.
• ForceCommand internal-sftp: obliga a usar el subsistema SFTP interno de OpenSSH, sin invocar ninguna shell. Sin shell, no hay comandos que ejecutar. Fácil.
• AllowTcpForwarding no, X11Forwarding no y PermitTunnel no: cierran el resto de puertas —túneles, reenvío de puertos, sesiones gráficas— que nadie necesita aquí.

Guarda los cambios. Y antes de reiniciar el servicio, comprueba la sintaxis:

sshd -t
systemctl restart sshd

Si sshd -t no devuelve nada, la configuración es válida. Un consejo que aprendí a las malas hace años: deja siempre una sesión SSH abierta mientras reinicias el servicio. Si algo va mal, esa sesión es tu única vía de escape para revertir rápido.

Permisos, prueba de conexión y errores comunes

Momento de la verdad. Conecta desde cualquier cliente SFTP —FileZilla, WinSCP o el propio terminal— con el usuario cliente1:

sftp [email protected]

Deberías caer directamente en el chroot y, tras hacer cd uploads, subir archivos sin rechistar. ¿Que no funciona? Casi seguro es uno de estos tres errores:

• «Connection closed» inmediato: casi siempre significa que el ChrootDirectory o alguna carpeta superior no es de root, o tiene permisos de escritura de grupo. Mira ls -la /data y corrige con chown root:root /data/cliente1.
• «Permission denied» al subir: aquí el problema es el contrario. El usuario no puede escribir en la carpeta destino. Comprueba que uploads pertenece a cliente1:sftpusers con 755 o 775.
• «Could not resolve hostname» o conexión rechazada: revisa que el puerto 22 está abierto en el firewall y que sshd está corriendo (systemctl status sshd). A veces es algo tan tonto como eso.

Para depurar con detalle, los logs del sistema en tiempo real son tu amigo:

tail -f /var/log/auth.log (Debian/Ubuntu) o tail -f /var/log/secure (CentOS/RHEL).

Allí verás el motivo exacto de cada rechazo. Cuando gestionas varios usuarios, esa diferencia lo es.

Conclusión: un SFTP seguro al alcance de todos

Pocas mejoras dan tanto por tan poco. En menos de una hora tienes la garantía de que tus usuarios solo accedan a sus archivos: sin shell, sin túneles, sin riesgo de escalada. La configuración se apoya en tres pilares: un grupo que identifique a los usuarios SFTP, la directiva ForceCommand internal-sftp que elimina el acceso a la shell, y un ChrootDirectory con los permisos correctos de root. Nada más. Y nada menos.

Eso sí, no lo dejes olvidado: mantén OpenSSH al día, repasa los logs de vez en cuando y valora la autenticación por clave pública en lugar de contraseñas. ¿Y si prefieres no complicarte con la administración? En RedServicio ofrecemos hosting con soporte técnico 24/7 que se encarga de estas configuraciones por ti, para que te centres en lo que de verdad importa: tu web y tu negocio.