Transferir un archivo de una máquina a otra suena trivial. Y lo es —hasta que ese archivo es un lote de pagos, y la "máquina de al lado" está al otro extremo de una red que no controlas. Ahí la pregunta deja de ser "¿cómo muevo el archivo?" y pasa a ser "¿quién más puede leerlo por el camino?". La respuesta separa a FTP de SFTP, y explica por qué en entornos serios el primero simplemente no existe.
Qué mueve cada protocolo
Un protocolo de transferencia de archivos es solo un acuerdo: cómo un cliente y un servidor conversan para listar carpetas, subir, bajar y borrar archivos. FTP y SFTP resuelven el mismo problema —mover bytes— pero desde mundos técnicos opuestos.
FTP (File Transfer Protocol) es un protocolo de 1985 que mueve archivos usando dos conexiones de red separadas y sin ningún cifrado: todo —comandos, credenciales y contenido— viaja en texto plano.
SFTP (SSH File Transfer Protocol) es un protocolo moderno que mueve archivos dentro de una conexión SSH ya cifrada. Pese al nombre, no comparte una sola línea de código ni de diseño con FTP.
Cómo funciona FTP (y por qué es de otra época)
Lo que hace a FTP peculiar es que usa dos canales: uno para dar órdenes y otro para mover el contenido.
- El cliente abre el canal de control hacia el servidor en el puerto 21. Por ahí viajan los comandos (
USER,PASS,LIST,RETR…) y las respuestas. - El cliente se autentica enviando usuario y contraseña —en texto plano— por ese mismo canal.
- Para transferir un archivo se abre un segundo canal, el de datos. En modo activo lo abre el servidor hacia el cliente; en modo pasivo lo abre el cliente hacia un puerto que el servidor le indica (por eso el pasivo es el que sobrevive detrás de firewalls).
- El contenido del archivo viaja por ese canal de datos —también sin cifrar—.
Ese diseño de dos canales era razonable en 1985. Hoy es un problema doble: complica los firewalls (hay que gestionar rangos de puertos para el canal de datos) y, sobre todo, no protege nada. Un atacante con visibilidad de la red —un Wi-Fi comprometido, un router intervenido, un vecino en el mismo segmento— lee tu contraseña y tu archivo tal cual.
"Uso FTP pero solo dentro de la red interna, así que es seguro." El perímetro no es cifrado. Un equipo comprometido o un movimiento lateral dentro de esa misma red interna ve todo el tráfico FTP en claro. Interno no significa confidencial.
Cómo funciona SFTP
SFTP no reinventa la seguridad: se apoya en SSH, el mismo protocolo con el que administras servidores de forma remota y segura. SFTP es, literalmente, un subsistema de SSH dedicado a archivos.
- El cliente abre una sola conexión SSH hacia el servidor, normalmente en el puerto 22.
- Cliente y servidor negocian el cifrado y verifican identidades antes de intercambiar nada útil. A partir de aquí, todo lo que pase por esa conexión va cifrado.
- El cliente se autentica por contraseña o —lo recomendable— con un par de llaves SSH: una privada que nunca sale de tu máquina y una pública que vive en el servidor.
- Comandos y contenido viajan por ese único canal cifrado. Un solo puerto, un solo túnel, nada legible desde fuera.
El resultado: un puerto en lugar de varios (firewall feliz), cifrado de extremo a extremo del transporte, verificación de integridad del contenido y la opción de autenticarte con llaves en vez de contraseñas. Todo lo que a FTP le falta, SFTP lo trae de fábrica porque lo hereda de SSH.
La confusión clave: SFTP no es FTPS
Aquí es donde casi todo el mundo tropieza. Existe un tercer nombre —FTPS— y no es un sinónimo de SFTP. Son cosas distintas:
- FTPS (FTP Secure) es el FTP de toda la vida con una capa de TLS encima (el mismo cifrado de HTTPS). Sigue teniendo dos canales y arrastra la complejidad de firewall de FTP. Suele usar el puerto 21 (modo explícito) o el 990 (implícito).
- SFTP no tiene nada que ver con FTP: es SSH, un solo canal, puerto 22.
"SFTP es FTP con SSL." No. Eso que describes es FTPS. La S de SFTP viene de SSH, no de "secure sockets". Son dos caminos diferentes para llegar a la misma meta —cifrar la transferencia—, pero SFTP y FTP ni siquiera hablan el mismo idioma.
Los tres, lado a lado
| Característica | FTP | FTPS | SFTP |
|---|---|---|---|
| Base técnica | FTP puro | FTP + TLS | SSH |
| Cifrado en tránsito | No | Sí | Sí |
| Canales / puertos | 2 canales (21 + datos) | 2 canales (21/990 + datos) | 1 canal (22) |
| Amigable con firewalls | Poco | Poco | Mucho |
| Autenticación por llaves | No | Vía certificados | Sí (llaves SSH) |
| Integridad del contenido | No garantizada | Sí | Sí |
Cuándo usar cada uno
- SFTP — la opción por defecto hoy. Un puerto, cifrado, llaves. Es lo que quieres para cualquier intercambio serio de archivos, interno o externo.
- FTPS — cuando una contraparte antigua exige FTP pero ambos aceptan añadir TLS, o cuando hay certificados de por medio que ya administras. Cifra, pero heredas el dolor de los dos canales.
- FTP puro — prácticamente nunca. Como mucho, para servir archivos públicos donde nada es sensible y no hay credenciales que proteger. Ante la duda, no.
Errores comunes
- Creer que el modo pasivo cifra. Activo vs pasivo solo decide quién abre el canal de datos. No tiene nada que ver con cifrado: un FTP pasivo sigue siendo texto plano.
- Confundir SFTP con FTPS al configurar un cliente o firewall, y terminar abriendo el puerto equivocado (21/990 en vez de 22, o al revés).
- Reutilizar la misma contraseña en SFTP en lugar de usar llaves. El cifrado protege el transporte, pero una contraseña débil o filtrada sigue siendo la puerta.
- Asumir que "está detrás de VPN" basta. La VPN protege un tramo; el archivo puede seguir su viaje por dentro en claro si el protocolo no cifra.
El ángulo banca: por qué SFTP y llaves
En banca, el intercambio de archivos no es una anécdota: es infraestructura. Lotes de pagos, conciliaciones, archivos de clearing, reportes regulatorios, ficheros de proveedores. Se mueven a diario entre instituciones que no comparten red, y su contenido es exactamente lo más sensible que existe.
Por eso hay tres exigencias que FTP no puede cumplir y SFTP sí:
- Confidencialidad en tránsito. Normas como PCI-DSS obligan a cifrar datos de tarjeta cuando cruzan redes abiertas. Un archivo con FTP incumple de entrada.
- Identidad fuerte y auditable. Las llaves SSH permiten dar a cada contraparte su propia credencial, rotarla y revocarla, y dejar rastro de quién se conectó. Una contraseña compartida no da nada de eso.
- Integridad. El canal SSH detecta si el archivo se alteró en el camino. En un lote de pagos, esa garantía no es un lujo.
FTP y SFTP contestan la misma pregunta —cómo mover un archivo— pero solo uno contesta la que de verdad importa: quién más puede leerlo. En un banco, esa segunda pregunta manda. Por eso el estándar no se discute: SFTP, con llaves, y FTP plano fuera de la política.
