secaudit.eu
Protección

SFTP vs FTP en WordPress: cambie a claves SSH

SFTP vs FTP en WordPress: por qué abandonar el FTP plano, cómo borrar cuentas FTP antiguas, crear claves SSH por persona y quitar contraseñas FTP de wp-config.php.

Por el , AngelForce OÜ 8 min de lectura

También en: English Deutsch Français Italiano Polski Português Türkçe

Abra la página de cuentas FTP del panel de su hosting. En muchos sitios WordPress encontrará al menos un acceso que nadie sabe explicar. Puede ser de la agencia que montó la web, de un freelance que arregló un plugin hace tres años o de una cuenta de prueba llamada ftp1. En el debate de SFTP vs FTP, la respuesta es sencilla: elimine esas cuentas, deje de usar FTP plano y dé a cada persona su propia clave SSH para SFTP. Esta guía recorre ese cambio en un orden que no deja a nadie fuera.

SFTP vs FTP: por qué hay que dejar el FTP plano

El FTP plano envía su usuario, su contraseña y cada archivo sin cifrar. Cualquiera que esté en el camino de la red puede leerlo todo: por ejemplo, en la wifi de un hotel, a través de un router de oficina comprometido o en un proveedor de red poco cuidadoso. Eso incluye wp-config.php con la contraseña de su base de datos, si alguna vez lo ha descargado por FTP.

Además, los accesos FTP quedan completamente fuera de WordPress. La autenticación en dos pasos de wp-admin no los protege y no aparecen en la lista de usuarios de WordPress. Quien tenga una contraseña FTP válida puede subir un archivo PHP y ejecutar código en su sitio sin ver nunca la página de inicio de sesión.

Cambiar de protocolo tiene límites claros. SFTP no sirve de nada si el portátil que guarda la clave está infectado, y tampoco resuelve un plugin vulnerable. Cierra una puerta concreta: las credenciales legibles y los accesos olvidados a su sistema de archivos.

Flujo de la clave SSH: ssh-keygen crea una clave privada y otra pública; solo la pública va al servidor
La clave privada se queda en su dispositivo. Al servidor solo se copia la clave pública.

FTP, FTPS y SFTP: comparativa

Los nombres confunden, así que va la versión corta.

FTPFTPSSFTP
CifradoNingunoTLSSSH
Puerto habitual2121 (explícito) o 990 (implícito)22
ConexionesControl + datosControl + datosUna
Acceso con claveNoNo (solo certificados)Sí
VeredictoNuncaAlternativaRecomendado

FTPS es el viejo protocolo FTP envuelto en TLS. Cifra el tráfico, pero sigue abriendo conexiones de datos separadas. Estas suelen chocar con cortafuegos y NAT, y el resultado es el clásico error de «fallo al recuperar el listado del directorio». SFTP, pese al nombre, no tiene relación con FTP. Es un subsistema de SSH, funciona sobre una única conexión cifrada y permite entrar con claves SSH en lugar de contraseñas.

Nuestra recomendación: use SFTP si su hosting ofrece acceso SSH. Use FTPS solo como alternativa. No use FTP plano en ningún caso. En FileZilla, elija el protocolo en el Gestor de sitios: «SFTP - SSH File Transfer Protocol». Si tiene que usar FTPS, seleccione «Requerir FTP explícito sobre TLS». No escoja «Usar FTP explícito sobre TLS si está disponible», porque esa opción vuelve en silencio al FTP plano cuando TLS falla. WinSCP ofrece la misma elección en «Protocolo de archivo».

Primero, localice y borre las cuentas FTP antiguas

Haga un inventario antes de crear ninguna clave. Revise estos lugares:

  • La sección de cuentas FTP del panel de su hosting (cPanel, Plesk y paneles similares la tienen).
  • La sección de acceso SSH o de claves SSH, incluidas las claves ya autorizadas.
  • En su propio servidor: usuarios del sistema con shell de inicio de sesión (grep -vE 'nologin|false' /etc/passwd) y todos los archivos ~/.ssh/authorized_keys.

Anote para cada cuenta quién la usa y para qué. Si nadie sabe decir quién es su titular, bórrela. Cambiar su contraseña no basta. Si la contraseña de la cuenta principal del hosting se ha escrito alguna vez en un cliente FTP, cámbiela también: esa contraseña ha viajado sin cifrar al menos una vez.

Conserve un breve registro de la limpieza: fecha, cuentas eliminadas y quién lo aprobó. Haga en paralelo la misma revisión con los accesos de WordPress. Nuestra guía sobre seguridad de los roles de usuario en WordPress cubre ese aspecto.

Genere una clave SSH con frase de contraseña (una por persona)

Cada persona crea su propia clave en su propio ordenador. macOS, Linux y las versiones actuales de Windows incluyen OpenSSH:

ssh-keygen -t ed25519 -C "anna@example-company.eu"

Acepte la ubicación por defecto y, cuando se le pida, establezca una frase de contraseña. No la omita. El comando crea dos archivos:

  • ~/.ssh/id_ed25519 es la clave privada. No sale nunca del dispositivo.
  • ~/.ssh/id_ed25519.pub es la clave pública. Es la que se comparte.

Para no teclear la frase en cada conexión, cargue la clave una vez por sesión en un agente con ssh-add ~/.ssh/id_ed25519. En Windows, active antes el servicio «OpenSSH Authentication Agent». Algunos clientes, como PuTTY, necesitan el formato .ppk. PuTTYgen puede importar la clave OpenSSH y guardar una copia .ppk. El manual de ssh-keygen enumera todas las opciones.

¿Por qué una clave por persona? Retirar el acceso de alguien se reduce entonces a borrar una línea, y los registros muestran qué clave se usó. Con claves o accesos compartidos, ninguna de las dos cosas es posible, así que retírelos durante esta migración.

Añada la clave pública: panel del hosting o ~/.ssh/authorized_keys

En un hosting gestionado o compartido, abra la sección de acceso SSH o de claves SSH. Pegue la clave pública, póngale un nombre reconocible y autorícela si el panel se lo pide (cPanel tiene un paso aparte llamado «Authorize»).

En su propio servidor, añada la clave al archivo authorized_keys del usuario y aplique permisos estrictos:

mkdir -p ~/.ssh
chmod 700 ~/.ssh
cat anna.pub >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Si el acceso con contraseña sigue funcionando, ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host hace lo mismo desde el ordenador de la propia persona. Conserve el comentario al final de cada línea de clave (anna@example-company.eu): es lo que le permitirá reconocerla dentro de dos años.

Pruebe el acceso con clave y después desactive las contraseñas

Mantenga abierta su sesión actual o la pestaña del panel. En un segundo terminal, pruebe la clave nueva:

ssh -i ~/.ssh/id_ed25519 user@host

O conéctese con su cliente SFTP indicando el archivo de clave. Solo cuando funcione para todas las personas que necesitan acceso debe desactivar la autenticación por contraseña. En un panel de hosting suele ser un interruptor en la sección SSH. En un hosting compartido donde no lo encuentre, pregunte a su proveedor si se pueden desactivar para su cuenta los accesos SSH y FTP con contraseña.

En su propio servidor, configure esto en /etc/ssh/sshd_config:

PasswordAuthentication no
KbdInteractiveAuthentication no

Revise también los archivos de /etc/ssh/sshd_config.d/. Algunas imágenes de nube incluyen un archivo complementario que establece PasswordAuthentication yes. Valide la configuración y confirme el valor efectivo antes de recargar:

sudo sshd -t
sudo sshd -T | grep -i passwordauthentication
sudo systemctl reload ssh

En los sistemas basados en Red Hat, el servicio se llama sshd.

A partir de ahora, la baja de una persona incluye un paso más: el día que se va, se borra la línea de su clave.

FS_METHOD y credenciales FTP en wp-config.php

A veces WordPress muestra un formulario de «Información de conexión» al instalar o actualizar un plugin. Ocurre porque PHP no puede escribir directamente en los archivos, normalmente por un problema de propietario. Nuestro artículo sobre los permisos de archivos en WordPress explica la causa.

Un apaño habitual consistía en poner los datos FTP en wp-config.php:

define( 'FS_METHOD', 'ftpext' );
define( 'FTP_HOST', 'ftp.example.de' );
define( 'FTP_USER', 'webuser' );
define( 'FTP_PASS', 'the-hosting-password' );

Con eso las actualizaciones funcionan, pero la contraseña del hosting queda en texto plano en un archivo que PHP lee en cada petición. Si wp-config.php se filtra, ya sea por una copia de seguridad, un servidor mal configurado o un plugin vulnerable, se filtra con él el acceso a los archivos. Compruebe si existen estas constantes:

grep -nE "FS_METHOD|FTP_(HOST|USER|PASS|SSL|PUBKEY|PRIKEY)" wp-config.php

Haga la misma comprobación en el directorio superior, porque algunas instalaciones guardan wp-config.php un nivel más arriba. Elimine las constantes y corrija el propietario de los archivos para que WordPress pueda escribir directamente. En ese caso sirve FS_METHOD con el valor 'direct', o puede omitirlo por completo. Use 'ssh2' solo si la extensión ssh2 de PHP y una clave dedicada están bien configuradas. Después borre la cuenta FTP a la que se hacía referencia o, como mínimo, cambie su contraseña. La documentación de wp-config.php de WordPress describe todas estas constantes. Nuestra lista de refuerzo de wp-config.php cubre el resto de ajustes de ese archivo.

El plugin gratuito Security Audit & Compliance de secaudit.eu analiza el sitio en busca de secretos y archivos expuestos y de problemas de refuerzo, lo que ayuda a detectar credenciales olvidadas donde no deben estar. No puede ver la lista de cuentas FTP de su panel de hosting, así que el inventario descrito arriba sigue siendo una tarea manual.

Preguntas frecuentes

¿Es suficiente FTPS si mi hosting no ofrece SSH?

Es aceptable como alternativa, porque el tráfico va cifrado. Configure su cliente para exigir TLS, use una contraseña fuerte y única por persona y borre igualmente las cuentas antiguas. Si su hosting no ofrece acceso SSH en absoluto y no sabe decir cuándo lo hará, plantéese cambiar de proveedor.

¿Necesito claves SSH para SFTP o basta con una contraseña?

SFTP con contraseña ya es mucho mejor que FTP, porque la contraseña viaja cifrada. Aun así, las claves son mejores: no se pueden adivinar ni robar con una página de acceso falsa, porque la clave privada nunca sale de su dispositivo. Usar una misma clave pública en varios servidores no la expone como ocurre con una contraseña reutilizada, y cada clave se puede retirar por separado.

¿Qué hago si alguien pierde su portátil con una clave dentro?

Elimine la clave pública de esa persona en todos los servidores y paneles ese mismo día. La frase de contraseña le da algo de margen, pero no es motivo para esperar. Después, la persona genera un par de claves nuevo en su nuevo dispositivo.

¿Es el FTP plano un problema para el RGPD?

El artículo 32, apartado 1, letra a) del RGPD menciona el cifrado como ejemplo de medida de seguridad adecuada. Por eso resulta difícil justificar accesos sin cifrar a un servidor que contiene datos de clientes o de formularios de contacto. Nuestro artículo sobre el artículo 32 del RGPD en WordPress explica el resto del precepto y el enfoque basado en el riesgo que lo sustenta.

Este artículo es información general, no asesoramiento jurídico.

Compruebe su propio sitio

Security Audit & Compliance es el plugin de WordPress de secaudit.eu: busca malware, spam oculto, archivos del núcleo modificados y código vulnerable, y relaciona sus hallazgos con el art. 32 del RGPD, el art. 21 de NIS2 y el OWASP Top 10.

Ver qué comprueba el plugin
Equipo editorial de secaudit.eu

Las guías de secaudit.eu sobre seguridad de WordPress y cumplimiento normativo europeo se redactan con herramientas de IA y se contrastan automáticamente con nuestra lista de fuentes antes de publicarse. secaudit.eu lo publica AngelForce OÜ, una empresa de software de Tallin (Estonia).

Elaborado con ayuda de IA y verificado antes de su publicación. Este artículo es información general, no asesoramiento jurídico.