Protocolos de transferencia de archivos: Parte 2 — FTPS o SFTP

Los nombres FTPS y SFTP difieren en una sola letra y a menudo se confunden. En realidad son dos protocolos distintos con arquitecturas diferentes. FTPS es el FTP habitual al que se le añadió cifrado TLS. SFTP es un protocolo independiente que funciona dentro de una conexión SSH y no tiene relación con FTP.

FTPS: FTP con cifrado TLS

FTPS conserva toda la lógica de FTP: dos conexiones, comandos, modos activo y pasivo, pero las envuelve en TLS, el mismo protocolo que protege HTTPS. Existen dos variantes.

FTPS explícito (explicit, AUTH TLS). Descrito en RFC 4217. El cliente se conecta al puerto 21 habitual y con el comando AUTH TLS solicita pasar a un canal protegido. El servidor puede permitir sesiones sin cifrar, por lo que es importante exigir TLS de forma obligatoria (en vsftpd — los parámetros force_local_logins_ssl y force_local_data_ssl).

FTPS implícito (implicit). TLS comienza inmediatamente al conectar, sin comandos. Para ello hay puertos dedicados: 990 para la conexión de control y 989 para los datos. Es una variante más antigua, no llegó a estandarizarse, pero muchos clientes y servidores la soportan.

Fortalezas de FTPS:

• se usan certificados comunes — los mismos que para un sitio web, por ejemplo de Let’s Encrypt;
• compatible con sistemas que “entienden” solo FTP y saben activar TLS.

Debilidades heredadas de FTP:

• las conexiones siguen siendo dos, y en modo pasivo se necesita un rango de puertos;
• NAT y firewalls no ven el contenido del canal de control cifrado y no pueden “averiguar” qué puerto abrir para los datos, por lo que las reglas deben definirse de forma rígida;
• más parámetros de configuración: certificado, modo, rango de puertos, cifrado obligatorio.

SFTP: transferencia de archivos sobre SSH

SFTP (SSH File Transfer Protocol) es una sub-sistema de SSH. El cliente se conecta al mismo servidor SSH en el puerto 22, pasa la autenticación SSH habitual — por contraseña o, mejor, por clave — y dentro de esa única conexión transmite archivos, obtiene listados de directorios, renombra y borra archivos.

Ventajas de SFTP:

• una conexión y un puerto — no hay problemas con el modo pasivo ni con NAT;
• el servidor ya existe — OpenSSH está instalado en casi todos los servidores Linux e incluye servidor SFTP;
• claves en lugar de contraseñas — se puede prescindir totalmente de las contraseñas;
• amplio soporte de clientes — FileZilla, WinSCP, Cyberduck, sftp en la línea de comandos, gestores de archivos de Linux y macOS.

Aislamiento de usuarios SFTP: chroot

Una tarea frecuente es dar a un contratista o a un tercero acceso a un único directorio para intercambio de archivos, sin acceso a la línea de comandos ni al resto del sistema. En OpenSSH esto se hace con un bloque Match en /etc/ssh/sshd_config:

# /etc/ssh/sshd_config
Subsystem sftp internal-sftp

Match Group sftponly
    ChrootDirectory /srv/sftp/%u
    ForceCommand internal-sftp
    AllowTcpForwarding no
    X11Forwarding no

• ForceCommand internal-sftp inicia el servidor SFTP integrado y no permite ejecutar otras órdenes. Según la documentación, no necesita archivos auxiliares dentro del chroot.
• ChrootDirectory encierra al usuario en su directorio; %u inserta el nombre de usuario.
• AllowTcpForwarding no y X11Forwarding no son necesarios explícitamente: la documentación de sshd advierte que ForceCommand por sí solo no impide el reenvío de puertos a través de la conexión.

Requisito principal para chroot: según la documentación, sshd comprueba que todos los componentes de la ruta pertenezcan a root y no sean grabables por el grupo ni por otros. Por eso el propio directorio del usuario se hace “solo lectura”, y para subir archivos se crea un subdirectorio:

sudo groupadd sftponly
sudo useradd -m -d /srv/sftp/partner -G sftponly -s /usr/sbin/nologin partner
sudo chown root:root /srv/sftp /srv/sftp/partner
sudo chmod 755 /srv/sftp /srv/sftp/partner
sudo mkdir /srv/sftp/partner/upload
sudo chown partner:partner /srv/sftp/partner/upload
sudo sshd -t && sudo systemctl reload ssh

El comando sshd -t verifica la configuración antes de recargar el servicio: un error en sshd_config en un servidor remoto puede cerrar el acceso SSH incluso para ustedes.

Comparación

Qué elegir

• Intercambio de archivos nuevo, servidor propio — SFTP. Más fácil de configurar, un puerto, claves en lugar de contraseñas.
• El tercero o el equipo solo soporta FTP — FTPS con cifrado obligatorio, cuenta separada y rango de puertos limitado.
• Se necesita acceso web para usuarios sin cliente — ninguno de los dos: es mejor un almacenamiento en la nube propio, por ejemplo Nextcloud, o WebDAV.

Errores típicos

• FTPS sin TLS obligatorio. El servidor acepta sesiones sin cifrar y algunos clientes se conectan sin cifrado sin darse cuenta.
• Directorio chroot perteneciente al usuario. sshd rechaza la conexión; en el registro aparece un mensaje sobre propietario o permisos incorrectos del directorio.
• Usuario SFTP con shell normal. Sin ForceCommand internal-sftp y nologin el usuario podrá iniciar sesión por SSH y ejecutar comandos.
• Contraseñas en lugar de claves para intercambios continuos. Para cargas automatizadas use una clave separada sin acceso a shell.