SFTP ou FTP pour WordPress : passez aux clés SSH

Ouvrez la page des comptes FTP dans le panneau de votre hébergeur. Sur beaucoup de sites WordPress, vous y trouverez au moins un identifiant que plus personne ne sait expliquer : celui de l'agence qui a créé le site, d'un freelance intervenu sur une extension il y a trois ans, ou un compte de test baptisé ftp1. Sur la question SFTP ou FTP, la réponse est simple : supprimez ces comptes, cessez d'utiliser le FTP classique et donnez à chaque personne sa propre clé SSH pour le SFTP. Ce guide décrit cette transition dans un ordre qui ne ferme la porte à personne.

SFTP ou FTP : pourquoi le FTP classique doit disparaître

Le FTP classique transmet votre identifiant, votre mot de passe et chaque fichier sans aucun chiffrement. Toute personne située sur le chemin réseau peut tout lire : Wi-Fi d'hôtel, routeur de bureau compromis, opérateur peu scrupuleux. Cela inclut wp-config.php, avec le mot de passe de votre base de données, si vous l'avez un jour téléchargé en FTP.

Les connexions FTP vivent en outre complètement en dehors de WordPress. L'authentification à deux facteurs sur wp-admin ne les protège pas, et elles n'apparaissent pas dans la liste des utilisateurs WordPress. Quiconque possède un mot de passe FTP valide peut téléverser un fichier PHP et exécuter du code sur votre site sans jamais voir la page de connexion.

Ce changement de protocole a des limites nettes. Le SFTP n'aide pas si l'ordinateur portable qui contient la clé est infecté, et il ne fait rien contre une extension vulnérable. Il referme une porte précise : des identifiants lisibles en clair et des accès oubliés à votre système de fichiers.

FTP, FTPS et SFTP : comparaison

Les sigles prêtent à confusion ; voici la version courte.

Le FTPS, c'est l'ancien protocole FTP enveloppé dans TLS. Le trafic est chiffré, mais des connexions de données distinctes restent ouvertes. Elles se heurtent souvent aux pare-feu et au NAT, d'où l'erreur classique « échec de la récupération du listing du répertoire ». Malgré son nom, le SFTP n'a rien à voir avec le FTP. C'est un sous-système de SSH : il passe par une seule connexion chiffrée et accepte l'authentification par clé SSH à la place d'un mot de passe.

Notre recommandation : utilisez le SFTP si votre hébergeur propose l'accès SSH. Le FTPS ne sert que de solution de repli. Le FTP classique, jamais. Dans FileZilla, choisissez le protocole dans le Gestionnaire de sites : « SFTP - SSH File Transfer Protocol ». Si vous devez passer par le FTPS, sélectionnez l'option qui exige le FTP explicite sur TLS (« Require explicit FTP over TLS » dans l'interface anglaise). Évitez l'option « Use explicit FTP over TLS if available » : en cas d'échec de TLS, elle bascule discrètement vers le FTP en clair. WinSCP propose le même choix sous « Protocole de fichier ».

Commencez par repérer et supprimer les anciens comptes FTP

Faites un inventaire avant de créer la moindre clé. Regardez à ces endroits :

• La section des comptes FTP du panneau d'hébergement (cPanel, Plesk et les panneaux similaires en ont tous une).
• La section d'accès SSH ou de clés SSH, y compris les clés déjà autorisées.
• Sur votre propre serveur : les utilisateurs système dotés d'un shell de connexion (grep -vE 'nologin|false' /etc/passwd) et chaque fichier ~/.ssh/authorized_keys.

Pour chaque compte, notez qui l'utilise et pourquoi. Si personne ne peut désigner son titulaire, supprimez-le. Changer son mot de passe ne suffit pas. Si le mot de passe du compte d'hébergement principal a un jour été saisi dans un client FTP, changez-le aussi : il a circulé au moins une fois sans chiffrement.

Conservez une trace brève du nettoyage : date, comptes supprimés, personne qui a validé. Faites la même revue pour les comptes WordPress, en parallèle. Notre guide sur la sécurité des rôles utilisateurs WordPress traite ce volet.

Générer une clé SSH avec phrase de passe (une par personne)

Chaque personne crée sa propre clé sur son propre ordinateur. macOS, Linux et les versions récentes de Windows intègrent OpenSSH :

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

Acceptez l'emplacement proposé par défaut, puis saisissez une phrase de passe quand elle vous est demandée. Ne la sautez pas. La commande crée deux fichiers :

• ~/.ssh/id_ed25519 est la clé privée. Elle ne quitte jamais l'appareil.
• ~/.ssh/id_ed25519.pub est la clé publique. C'est celle que vous partagez.

Pour ne pas retaper la phrase de passe à chaque connexion, chargez la clé dans un agent une fois par session avec ssh-add ~/.ssh/id_ed25519. Sous Windows, activez d'abord le service « OpenSSH Authentication Agent ». Certains clients, comme PuTTY, exigent le format .ppk : PuTTYgen sait importer la clé OpenSSH et en enregistrer une copie .ppk. Le manuel de ssh-keygen détaille toutes les options.

Pourquoi une clé par personne ? Retirer l'accès de quelqu'un revient alors à supprimer une seule ligne, et les journaux indiquent quelle clé a servi. Les clés et les identifiants partagés rendent ces deux opérations impossibles : abandonnez-les pendant cette migration.

Ajouter la clé publique : panneau d'hébergement ou ~/.ssh/authorized_keys

Sur un hébergement mutualisé ou géré, ouvrez la section d'accès SSH ou de clés SSH. Collez la clé publique, donnez-lui un nom reconnaissable et autorisez-la si le panneau le demande (cPanel prévoit une étape « Authorize » distincte).

Sur votre propre serveur, ajoutez la clé au fichier authorized_keys de l'utilisateur et appliquez des permissions strictes :

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

Si la connexion par mot de passe fonctionne encore, ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host fait la même chose depuis l'ordinateur de la personne. Gardez le commentaire à la fin de chaque ligne de clé (anna@example-company.eu) : c'est lui qui vous permettra de la reconnaître dans deux ans.

Tester la connexion par clé, puis désactiver le mot de passe

Gardez votre session actuelle ou l'onglet du panneau ouvert. Dans un second terminal, testez la nouvelle clé :

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

Vous pouvez aussi vous connecter avec votre client SFTP en lui indiquant le fichier de clé. Ne désactivez l'authentification par mot de passe qu'une fois que cela fonctionne pour chaque personne qui a besoin d'un accès. Dans un panneau d'hébergement, il s'agit généralement d'un interrupteur dans la section SSH. Sur un mutualisé où vous n'en trouvez pas, demandez à votre hébergeur s'il peut désactiver les connexions SSH et FTP par mot de passe pour votre compte.

Sur votre propre serveur, définissez ceci dans /etc/ssh/sshd_config :

PasswordAuthentication no
KbdInteractiveAuthentication no

Vérifiez aussi les fichiers de /etc/ssh/sshd_config.d/. Certaines images cloud livrent un fichier complémentaire qui impose PasswordAuthentication yes. Validez la configuration et contrôlez la valeur effective avant de recharger :

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

Sur les systèmes de la famille Red Hat, le service s'appelle sshd.

Désormais, le départ d'un collaborateur comporte une étape de plus : le jour où la personne s'en va, supprimez la ligne de sa clé.

FS_METHOD et identifiants FTP dans wp-config.php

Il arrive que WordPress affiche un formulaire « Informations de connexion » lors de l'installation ou de la mise à jour d'une extension. La raison : PHP ne peut pas écrire directement dans les fichiers, ce qui relève le plus souvent d'un problème de propriétaire. Notre article sur les permissions de fichiers WordPress en explique la cause.

Une solution de contournement courante consistait à placer les paramètres FTP dans wp-config.php :

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

Les mises à jour fonctionnent, mais le mot de passe d'hébergement se retrouve en clair dans un fichier que PHP lit à chaque requête. Si wp-config.php fuite, par une copie de sauvegarde, un serveur mal configuré ou une extension vulnérable, l'accès aux fichiers fuite avec lui. Recherchez ces constantes :

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

Faites aussi cette recherche dans le répertoire parent, car certaines installations placent wp-config.php un niveau au-dessus. Supprimez les constantes et corrigez le propriétaire des fichiers pour que WordPress puisse y écrire directement. Dans ce cas, FS_METHOD à 'direct' convient, ou vous pouvez l'omettre complètement. N'utilisez 'ssh2' que si l'extension PHP ssh2 et une clé dédiée sont correctement configurées. Supprimez ensuite le compte FTP concerné, ou au minimum changez son mot de passe. La documentation de wp-config.php décrit toutes ces constantes. Notre checklist de durcissement de wp-config.php couvre les autres réglages de ce fichier.

L'extension gratuite Security Audit & Compliance de secaudit.eu recherche les secrets et fichiers exposés ainsi que les failles de durcissement, ce qui aide à repérer des identifiants oubliés au mauvais endroit. Elle ne voit pas la liste des comptes FTP de votre panneau d'hébergement : l'inventaire décrit plus haut reste une tâche manuelle.

FAQ

Le FTPS suffit-il si mon hébergeur n'offre pas le SSH ?

C'est acceptable comme solution de repli, puisque le trafic est chiffré. Configurez votre client pour exiger TLS, utilisez un mot de passe fort et unique par personne, et supprimez quand même les anciens comptes. Si votre hébergeur ne propose aucun accès SSH et ne peut pas dire quand il le fera, envisagez de changer d'hébergeur.

Faut-il des clés SSH pour le SFTP, ou un mot de passe suffit-il ?

Le SFTP avec mot de passe est déjà bien meilleur que le FTP, car le mot de passe circule chiffré. Les clés restent préférables. On ne peut ni les deviner ni les voler au moyen d'une fausse page de connexion, puisque la clé privée ne quitte jamais l'appareil. Utiliser une même clé publique sur plusieurs serveurs ne l'expose pas comme le fait la réutilisation d'un mot de passe, et chaque clé peut être retirée individuellement.

Que faire si quelqu'un perd son ordinateur portable contenant une clé ?

Retirez la clé publique de cette personne de tous les serveurs et panneaux le jour même. La phrase de passe vous fait gagner du temps, mais ce n'est pas une raison d'attendre. La personne génère ensuite une nouvelle paire de clés sur son nouvel appareil.

Le FTP classique pose-t-il un problème au regard du RGPD ?

L'article 32, paragraphe 1, point a) du RGPD cite le chiffrement comme exemple de mesure de sécurité appropriée. Des connexions non chiffrées vers un serveur qui contient des données de clients ou de formulaires de contact sont donc difficiles à justifier. Notre article sur l'article 32 du RGPD pour WordPress détaille le reste de la disposition et l'approche fondée sur les risques.

Cet article est une information générale et ne constitue pas un conseil juridique.