FTP, FTPS y SFTP mueven ficheros entre tu ordenador y un servidor, y solo comparten el apellido. El FTP viaja en texto plano. El FTPS es ese mismo FTP metido dentro de TLS, el cifrado del candado del navegador. El SFTP no es FTP: es otro protocolo, y viaja dentro de SSH. Si tu servidor ofrece SFTP, usa SFTP.
El lío viene de que los tres se configuran en la misma ventana del mismo programa, con un desplegable de tres líneas, y de que el panel de tu hosting los llama a todos «FTP». Vamos por partes.
Qué es un cliente FTP y qué es un servidor
Un cliente FTP es el programa que instalas en tu equipo para conectarte a un servidor y trabajar con sus ficheros: subir, descargar, renombrar, mover, borrar, cambiar permisos. Por dentro es un explorador de archivos de dos paneles (a la izquierda tu disco, a la derecha el del servidor) y por eso se aprende en cinco minutos. FileZilla es el más extendido y funciona en Windows, macOS y Linux; si has llegado hasta aquí buscando el programa en sí, lo que necesitas es descargar el cliente FileZilla.
El servidor es la otra mitad. Es un programa que se queda escuchando en un puerto, comprueba usuario y contraseña, y decide qué carpetas puede ver cada cuenta. Casi nadie tiene que instalar uno: el hosting ya lo trae montado, y lo que te llegó en el correo de bienvenida (servidor, usuario, contraseña, puerto) son las credenciales de su servidor. Solo necesitas el tuyo si quieres servir ficheros desde tu propia máquina, y para eso existe FileZilla Server.
Ahí hay una trampa que se paga cara. FileZilla se llama igual en las dos puntas, pero son dos programas distintos y no hablan los mismos protocolos. El cliente entiende FTP, FTPS y SFTP. El servidor gratuito se presenta a sí mismo como servidor de FTP y de FTPS, y el SFTP no aparece por ningún lado: ni en esa descripción ni en la tabla que compara sus ediciones. No es que lo desaconseje en una nota; es que no está. Si lo que quieres es montar un SFTP, esta no es la pieza: el SFTP lo sirve el propio SSH del sistema. Y cuidado con el nombre, porque existe un producto de pago distinto, FileZilla Pro Enterprise Server, que ese sí anuncia SFTP: comparte marca y no comparte binario.
Qué es el FTP: dos conexiones y todo en claro
La especificación del FTP es de octubre de 1985. No es una manera de decir que es antigua: es literalmente el mismo documento que sigue vigente hoy.
El detalle que explica el noventa por ciento de los problemas es que el FTP usa dos conexiones. Una de control, por el puerto 21, por la que viajan las órdenes y sus respuestas. Y otra distinta, que se abre y se cierra para cada fichero y para cada listado de directorio. En el diseño original esa segunda conexión salía del puerto contiguo al de control y la abría el servidor llamando al cliente. Vas a leer en todas partes que ese puerto es el 20, y el número no está en el documento de 1985: allí pone «el puerto adyacente al de la conexión de control», y ya está. El 20 se lo puso después el registro de puertos de la IANA, que lo tiene apuntado como ftp-data.
A esa forma de trabajar se la llama modo activo. El nombre tampoco es del documento original: es jerga que vino después. Y hoy funciona mal, porque tu router no tiene forma de saber que debe dejar entrar esa llamada entrante. Por eso todo el mundo usa el modo pasivo, que sí está en el texto de 1985 aunque con otras palabras: el proceso de transferencia se pone a la escucha en un puerto y espera a que el otro lado llame, en vez de llamar él. Cuando FileZilla se queda clavado en «Recuperando el listado del directorio» después de haber autenticado bien, es esto casi siempre.
Lo demás cabe en una frase, y merece la pena saber en qué papel está escrita, porque no es en el de 1985: aquel texto ni siquiera llega a tener una sección de seguridad. Quien lo dice con todas las letras es el documento que el IETF publicó en 1999 sobre la seguridad del FTP. Todos los datos y toda la información de control, contraseñas incluidas, se envían por la red sin cifrar. No es un fallo de implementación ni algo que arregle una contraseña más larga; es el protocolo. Cualquiera que esté en medio —la wifi del hotel, un equipo comprometido de la red de la oficina— lee tu contraseña tal cual la escribiste. El mismo documento describe además el ataque de rebote, que consiste en usar una orden del propio protocolo para que un servidor FTP abra conexiones contra un tercero en tu nombre.
Al FTP a secas le queda un uso decente: repositorios de descarga pública anónima, donde no hay credenciales que robar. Para lo demás, no. Los navegadores ya sacaron la conclusión por su cuenta y dejaron de abrirlo: Firefox lo retiró en la versión 90, en julio de 2021, y Chrome hizo lo mismo en la 95.
Qué es el FTPS: el mismo FTP, dentro de TLS
El FTPS no es un protocolo nuevo. Es el FTP de 1985 hablando por un túnel TLS, la misma tecnología que hay detrás del https. Las órdenes de seguridad que lo hacen posible se añadieron al FTP en 1997, y en 2005 se publicó cómo usarlas concretamente con TLS.
Hay dos formas de hacerlo, y solo una de las dos está escrita en una especificación:
- FTPS explícito. Conectas al puerto 21 como en un FTP normal y, antes de mandar la contraseña, pides subir a TLS. Es el que está estandarizado y el que vas a encontrarte en cualquier hosting.
- FTPS implícito. El servidor abre un puerto aparte, el 990, donde todo va cifrado desde el primer byte y no se negocia nada. Esto no lo estandarizó nadie, y conviene decirlo con precisión: la especificación de 2005 no lo desaconseja ni lo prohíbe, sencillamente no lo nombra. Ni la palabra «implícito» ni el número 990 aparecen una sola vez en todo el documento. Y el 990 está en el registro de la IANA a nombre de un particular, sin ninguna norma detrás. Existe en las máquinas y funciona, pero sobre el papel no existe; si te lo encuentras suele ser síntoma de un equipo viejo. Casi nunca hace falta tocarlo.
El servidor se identifica con un certificado X.509, del mismo tipo que lleva tu banco. De ahí viene el aviso que todo el mundo ha visto alguna vez: la primera vez que conectas, FileZilla te enseña el certificado y te pregunta si te fías, porque muchos hostings usan uno autofirmado o emitido a nombre del servidor físico y no de tu dominio. Aceptarlo una vez y guardarlo está bien. Lo que no está bien es aceptarlo cada vez sin mirar: si el certificado cambia de un día para otro y nadie te ha avisado de una migración, ahí conviene parar y preguntar.
El punto flojo del FTPS es el del FTP, pero peor, y aquí hay que ir despacio porque es la parte que suele contarse justo al revés. Las órdenes que negocian el segundo canal, las que anuncian qué dirección y qué puerto se van a usar para mover el fichero, no viajan por la conexión de datos. Viajan por la de control. Y es esa, la de control, la que el router con NAT o el cortafuegos necesita leer para saber qué tiene que dejar pasar después. Al meterla dentro de TLS, el equipo de en medio se queda ciego.
El problema es tan real que la especificación de 2005 lo escribe tal cual: los equipos de frontera, dice, como el NAT y los cortafuegos, esperan poder examinar el contenido de la conexión de control para modificar su comportamiento. Y contempla una orden, el CCC, para devolver esa conexión de control a texto plano una vez que ya te has autenticado, precisamente para que el cortafuegos vuelva a leerla, con su advertencia de seguridad al lado, claro. Cuando la solución estándar a un problema pasa por apagar parte del cifrado, ya sabes por dónde va la cosa.
Qué es el SFTP: ni es FTP, ni es un estándar publicado
El SFTP no tiene nada que ver con el FTP más allá de las tres letras. Es un subsistema de SSH: la misma conexión con la que abrirías una consola remota, pero pidiendo el módulo de ficheros en lugar de un intérprete de órdenes. Una conexión, un puerto (el 22, que el registro de puertos de la IANA tiene asignado a SSH, no al FTP) y nada que tocar en el cortafuegos. Esa es la razón práctica de que haya ganado la partida.
Y ahora el dato que descoloca a casi todo el mundo: el SFTP nunca llegó a publicarse como estándar. El borrador del IETF se quedó en su revisión 13, fechada en julio de 2006, y caducó ahí; el grupo de trabajo cerró en diciembre de 2011 sin llevarlo a RFC.
El matiz que casi nadie añade es que esa revisión 13 describe un papel que prácticamente nadie implementa. Lo que hablan las máquinas es la versión 3 del protocolo, y la versión 3 la define una revisión mucho más vieja del mismo borrador, la 02 de octubre de 2001, que lo dice en una línea: el número de versión del protocolo especificado en este documento es el 3. Esa es la que implementa OpenSSH, que es el servidor SFTP que hay detrás de la inmensa mayoría de los hostings. Así que «el SFTP es un borrador caducado de 2006» es media verdad: el que se usa es un borrador caducado de 2001. De ahí salen las rarezas ocasionales entre un cliente y un servidor de fabricantes distintos, casi siempre con permisos, enlaces simbólicos y fechas de modificación.
La autenticación también funciona distinta. El servidor no enseña un certificado X.509: enseña su clave de host, y tu cliente la compara con la que guardó la primera vez. Certificados, en SSH, haberlos hay, pero no son los del navegador: el protocolo de transporte solo contempla claves RSA y DSS y certificados OpenPGP, y OpenSSH añadió por su cuenta un formato propio que su documentación describe como distinto y mucho más simple que el X.509 del SSL. Existe una norma para meter X.509 dentro de SSH, pero OpenSSH no la lista entre lo que implementa, así que en la práctica no te la vas a cruzar. La propia arquitectura de SSH asume el atajo: la estrategia recomendada es aceptar la clave sin comprobarla la primera vez que conectas, guardarla en una base local y contrastarla en todas las conexiones siguientes. Eso es el diálogo de «clave de host desconocida» con una huella hexadecimal que a todos nos ha salido y casi nadie lee. Aquí es donde la mayoría se equivoca: el aviso que importa no es el primero, es el segundo. Si la huella cambia y tú no has cambiado de servidor, no lo aceptes.
Por tu lado puedes entrar con contraseña o con una clave SSH. Con clave es más cómodo y más seguro, y el fichero de clave se carga en el propio gestor de sitios de FileZilla.
Diferencias entre FTP, FTPS y SFTP
| FTP | FTPS | SFTP | |
|---|---|---|---|
| Qué es | protocolo propio, de 1985 | FTP metido en TLS | subsistema de SSH |
| ¿Estándar publicado? | sí | el explícito sí; el implícito no lo estandarizó nadie | no: borrador caducado (se usa la versión 3, de 2001) |
| Puerto por defecto | 21 (control) + el de datos (el 20 lo asigna la IANA, no la especificación) | 21 explícito · 990 implícito (puerto de la IANA, sin norma detrás) | 22 |
| Conexiones | dos | dos | una |
| Cifrado | ninguno | TLS | SSH |
| El servidor se identifica con | nada | un certificado X.509 | su clave de host |
| Entrar con clave en vez de contraseña | no | no | sí, claves SSH |
| Detrás de un router | problemático | más problemático | sin problemas |
| Lo habla el cliente FileZilla | sí | sí | sí |
| Lo habla FileZilla Server (el gratuito) | sí | sí | no aparece (sí lo anuncia el de pago, FileZilla Pro Enterprise Server) |
¿Cuál debo usar?
El orden es corto: SFTP si te lo ofrecen, FTPS explícito si no, y FTP a secas nunca con credenciales que te importen.
En la práctica no eliges tú, elige tu proveedor, y ahí hay un patrón bastante fiable. Si tienes un VPS, un servidor propio o cualquier sitio donde entres por SSH, ya tienes SFTP montado sin instalar nada: si el SSH funciona, el SFTP funciona. Si estás en un hosting compartido con cPanel o Plesk, lo normal es que no haya acceso SSH y te toque FTPS explícito; el panel te lo llamará «FTP» y no mencionará el TLS por ninguna parte, pero pruébalo igual, porque casi siempre está ahí. Y si lo que hay al otro lado es un NAS, una cámara de red, una impresora o un equipo industrial, prepárate para encontrar todavía FTP puro, y de vez en cuando el FTPS implícito del 990.
En FileZilla toda esta decisión se reduce a un desplegable. Eligiendo SFTP no hay nada más que decidir. Eligiendo FTP tienes debajo el selector de cifrado: pide TLS explícito y no te conformes con el FTP simple, que el propio programa etiqueta como inseguro. El puerto puedes dejarlo vacío en los dos casos, que FileZilla pone el que corresponde; si el hosting te lo exige, es 22 para SFTP y 21 para FTP y FTPS explícito. El paso a paso de la conexión, con el gestor de sitios abierto, está en cómo configurar FileZilla.
Un aviso de los que ahorran una tarde: cambiar de FTP a SFTP te cambia el usuario. Las cuentas FTP que creas en el panel del hosting son cuentas del servidor FTP, no del sistema operativo; por SFTP entras con un usuario del sistema, que suele ser otro y que suele aterrizar en otra carpeta. Si conectas por SFTP y no ves tu public_html donde lo dejaste, no está borrado: estás un nivel más arriba. Con eso resuelto, subir tu web es arrastrar y soltar.