Protocoles SSH, FTP et SFTP

Cryptographie symétrique

La cryptographie symétrique est une technique de chiffrement où une même clé secrète est utilisée pour chiffrer et déchiffrer les données.

Elle est particulièrement rapide et efficace, ce qui en fait une solution couramment utilisée pour protéger de grands volumes de données. Cependant, son principal défi réside dans la gestion et le partage sécurisé de la clé entre les parties communicantes.

Avantages

Très rapide et peu coûteuse en ressources processeur.
Mise en œuvre simple : une seule clé partagée suffit pour chiffrer et déchiffrer.
Bien adaptée au chiffrement de flux importants (fichiers, bases de données, etc.).

Inconvénients

La distribution sécurisée de la clé est complexe (comment échanger la clé sans risque d'interception ?).
Si la clé est compromise, l'ensemble des communications protégées avec celle-ci est vulnérable.
Pas idéale seule pour les communications sur Internet, où les interlocuteurs changent fréquemment : il faudrait une clé différente pour chaque paire d'interlocuteurs (pour 100 personnes, cela représente déjà 4 950 clés).

Sources :

Exemples d'algorithmes symétriques

DES (Data Encryption Standard) : ancien standard des années 1970, aujourd'hui obsolète. Sa clé de 56 bits est trop courte : elle peut être retrouvée en essayant toutes les possibilités (attaque par force brute).
3DES (Triple DES) : applique DES trois fois de suite pour renforcer la sécurité. Il est lui aussi obsolète et ne doit plus être utilisé pour protéger de nouvelles données depuis 2024.
AES (Advanced Encryption Standard) : standard moderne (depuis 2001), largement utilisé (HTTPS, VPN, SSH, disques chiffrés, etc.), avec des clés de 128, 192 ou 256 bits.
ChaCha20 : alternative moderne à AES, généralement associée à Poly1305, qui vérifie l'intégrité des données (on parle de ChaCha20-Poly1305). Elle est utilisée notamment dans TLS 1.3 (HTTPS) et dans SSH. Elle est particulièrement rapide sur les appareils dépourvus d'accélération matérielle pour AES (certains smartphones, objets connectés).

Sources :

Source image

Cryptographie asymétrique

La cryptographie asymétrique (ou cryptographie à clé publique) repose sur une paire de clés distinctes mais liées mathématiquement :

Clé publique : elle peut être partagée librement. Elle sert à chiffrer des données destinées au propriétaire de la paire, ou à vérifier ses signatures.
Clé privée : elle doit rester confidentielle. Elle sert à déchiffrer les données chiffrées avec la clé publique correspondante, ou à signer.

L'idée fondamentale est double :

Un message chiffré avec une clé publique ne peut être déchiffré qu'avec la clé privée correspondante.
Il est pratiquement impossible de retrouver la clé privée à partir de la clé publique.

Cela élimine le besoin d'échanger une clé secrète à l'avance (contrairement à la cryptographie symétrique).

Avantages

Sécurise les communications sans échange de clé secrète préalable.
La clé publique peut être diffusée librement, ce qui simplifie l'établissement de connexions chiffrées.
Sert aussi à l'authentification grâce aux signatures numériques (ex. : prouver qu'un message provient bien de l'expéditeur).

Inconvénients

Plus lente que la cryptographie symétrique (calculs mathématiques plus lourds). En pratique, on l'utilise donc surtout pour échanger des clés ou pour signer, puis on bascule vers un chiffrement symétrique. On parle alors de chiffrement hybride.
Il faut pouvoir s'assurer qu'une clé publique appartient bien à la bonne personne. Sinon, un attaquant peut présenter sa propre clé publique et intercepter les échanges : c'est l'attaque de l'homme du milieu (man-in-the-middle).
- Sur le web, cette vérification est assurée par une infrastructure de gestion de clés (PKI - Public Key Infrastructure).
- SSH utilise un mécanisme plus simple, présenté plus loin.

Sources :

Source image

Exemples d'algorithmes asymétriques

RSA : le plus connu, utilisable pour le chiffrement et la signature. Il nécessite des clés longues (au moins 2 048 bits, et plutôt 3 072 bits).
Algorithmes à courbes elliptiques : ECDSA et Ed25519 pour la signature, X25519 pour l'échange de clés. Ils offrent un niveau de sécurité comparable à RSA avec des clés beaucoup plus courtes.
Diffie-Hellman : dédié à l'échange de clés (voir plus bas).

Sources :

Exemples d'utilisation

SSH : utilise la cryptographie asymétrique pour authentifier le serveur (et souvent le client) et pour établir une clé de session commune. Il bascule ensuite vers un chiffrement symétrique plus rapide pour la communication.
HTTPS (TLS) : les certificats basés sur la cryptographie asymétrique permettent de vérifier l'identité des serveurs et d'établir une connexion sécurisée avec le navigateur.
- SSL est l'ancien nom de ce protocole. Toutes ses versions sont aujourd'hui obsolètes, tout comme TLS 1.0 et 1.1.
- Seuls TLS 1.2 et TLS 1.3 sont encore recommandés.
Signatures numériques : permettent de valider l'intégrité et l'origine d'un document ou d'un message.

Sources :

Source image

Chiffrement vs Signature

Ces deux mécanismes reposent sur une paire de clés publique/privée. Ils l'utilisent dans des sens opposés et pour des objectifs différents.

🔒 Chiffrement (Confidentialité)

But : S'assurer que seul le destinataire prévu puisse lire le message.
Mécanisme :
- L'expéditeur chiffre le message avec la clé publique du destinataire.
- Seule la clé privée correspondante peut déchiffrer le message.
Garantit : la confidentialité.

Exemple : Un patient envoie ses résultats médicaux à son médecin via Internet, de façon à ce que seul ce médecin puisse les lire.

💡 En pratique, la cryptographie asymétrique étant lente, on ne chiffre pas tout le message avec la clé publique :

L'expéditeur chiffre le message avec une clé symétrique générée au hasard.
Il chiffre uniquement cette clé avec la clé publique du destinataire.

C'est le principe du chiffrement hybride.

Sources :

Source image

✍️ Signature numérique (Authenticité + Intégrité)

But : Prouver que le message vient bien de l'expéditeur et qu'il n'a pas été modifié.
Mécanisme :
- L'expéditeur calcule une empreinte du message avec une fonction de hachage. Cette empreinte est un résumé de taille fixe du message.
- Il génère la signature à partir de cette empreinte, avec sa clé privée.
- Le destinataire recalcule l'empreinte du message reçu et vérifie la signature avec la clé publique de l'expéditeur. Si le message a été modifié, la vérification échoue.
Garantit :
- Authenticité : le message vient bien de l'expéditeur.
- Intégrité : le contenu n'a pas été modifié.
- Non-répudiation : l'expéditeur ne peut pas nier avoir signé le message.

⚠️ Une signature ne rend pas le message secret : n'importe qui peut le lire. Pour obtenir à la fois la confidentialité et l'authenticité, on combine chiffrement et signature.

Exemple : Une administration publique publie un document officiel signé numériquement pour prouver qu'il provient bien d'elle et qu'il n'a pas été modifié.

Sources :

Source image

Echange de clés Diffie-Hellman

L'échange de clés Diffie-Hellman (DH) est un protocole cryptographique qui permet à deux parties de calculer un secret commun sans que ce secret ne soit jamais transmis sur le réseau.

Ce secret commun sert ensuite à fabriquer les clés d'un algorithme de cryptographie symétrique (plus rapide) pour chiffrer les communications.

L'idée centrale repose sur des problèmes mathématiques difficiles à résoudre (comme le logarithme discret). Le protocole reste donc sûr même si un attaquant observe tous les échanges publics.

Etapes du protocole

Paramètres publics
- Un très grand nombre premier p (plusieurs centaines de chiffres) et une base g (appelée générateur) sont choisis et partagés publiquement.
Génération des clés privées et publiques
- Alice choisit une clé privée a et calcule sa clé publique : A = g^a mod p.
- Bob choisit une clé privée b et calcule sa clé publique : B = g^b mod p.
Echange des clés publiques
- Alice envoie A à Bob.
- Bob envoie B à Alice.
  - Même si un attaquant intercepte A et B, il ne peut pas retrouver a ou b en un temps raisonnable.
Calcul du secret commun
- Alice calcule : S = B^a mod p.
- Bob calcule : S = A^b mod p.
- Grâce aux propriétés des puissances modulaires, (g^b)^a = (g^a)^b = g^(a×b) mod p. Alice et Bob obtiennent donc le même secret S, sans jamais le transmettre ni révéler leurs clés privées.
- En pratique, S n'est pas utilisé tel quel : les deux parties en dérivent les clés de session.

Sources :

Exemple avec de petits nombres

En réalité, les nombres utilisés sont beaucoup plus grands.

Paramètres publics : p = 23 et g = 5.
Alice choisit a = 6 et calcule A = 5^6 mod 23 = 8.
Bob choisit b = 15 et calcule B = 5^15 mod 23 = 19.
Alice calcule S = 19^6 mod 23 = 2.
Bob calcule S = 8^15 mod 23 = 2.
Tous deux obtiennent S = 2.

Un observateur connaît p, g, A et B. Pour calculer S, il devrait retrouver a ou b, ce qui est impossible en pratique avec de très grands nombres.

Source image

Exemple visuel simplifié

Imaginons que les paramètres publics correspondent à une couleur de peinture commune, connue de tous.
Alice choisit une couleur secrète, la mélange à la couleur commune et envoie le mélange à Bob.
Bob fait de même avec sa propre couleur secrète.
Chacun ajoute ensuite sa couleur secrète au mélange reçu de l'autre : tous deux obtiennent la même couleur finale.
Un observateur voit passer les mélanges, mais ne peut pas en extraire les couleurs secrètes : mélanger des peintures est facile, les séparer est pratiquement impossible. C'est exactement la propriété du calcul g^a mod p.

Source image

Avantages

Pas besoin d'échanger une clé secrète par un canal sécurisé.
Fonctionne même sur un réseau totalement ouvert comme Internet.
Si de nouvelles valeurs a et b sont tirées à chaque connexion (on parle de DH éphémère), on obtient la confidentialité persistante (forward secrecy).
- Même si la clé privée à long terme d'un serveur est volée plus tard, les communications passées restent indéchiffrables.
- TLS 1.3 impose ce mécanisme.

Sources :

Limitation

Diffie-Hellman n'assure pas l'authentification.
- Exemple : un attaquant peut s'interposer entre Alice et Bob et réaliser un échange séparé avec chacun d'eux, en se faisant passer pour l'autre (attaque man-in-the-middle).
C'est pourquoi TLS (HTTPS) et SSH combinent DH avec une authentification.
- Le serveur signe les éléments de l'échange avec sa clé privée.
- Le client peut ainsi vérifier qu'il communique bien avec le bon serveur (grâce au certificat pour TLS, ou à la clé d'hôte pour SSH).

Sources :

Variantes actuelles

La version présentée ici, avec des calculs modulo un nombre premier p, est la version historique.
Aujourd'hui, on utilise surtout sa variante sur courbes elliptiques (ECDH, par exemple X25519). Le principe est identique, mais elle est plus rapide et utilise des clés plus courtes.
De futurs ordinateurs quantiques pourraient casser ces calculs. Pour s'y préparer, des échanges de clés « hybrides » apparaissent.
- Depuis OpenSSH 10.0 (avril 2025), l'échange par défaut combine X25519 et ML-KEM, un algorithme dit « post-quantique » standardisé par le NIST.
- La version historique de DH y est désactivée par défaut côté serveur.

Sources :

SSH (Secure Shell)

Le protocole SSH (Secure Shell) est un protocole de communication sécurisé qui permet d'établir une connexion chiffrée entre un client et un serveur à travers un réseau non sécurisé (comme Internet).

La version utilisée aujourd'hui est SSH-2, normalisée par l'IETF en 2006. L'ancienne version SSH-1, qui présente des failles de sécurité, n'est plus prise en charge par les logiciels actuels. L'implémentation la plus répandue du protocole est OpenSSH, intégrée à la plupart des systèmes (Linux, macOS, Windows).

Par défaut, le serveur SSH écoute sur le port TCP 22, attribué officiellement à SSH par l'IANA.

Sources :

Source image

Sécurité

Confidentialité : toutes les données (commandes, fichiers, mots de passe, etc.) sont chiffrées pendant le transit.
Intégrité : un code de contrôle ajouté à chaque paquet permet de détecter toute modification en cours de route.
Authenticité : le serveur prouve son identité grâce à sa clé publique (appelée clé d'hôte), puis le client s'authentifie à son tour (mot de passe, clé publique, etc.).

SSH combine :

La cryptographie asymétrique pour établir la connexion et authentifier les parties.
La cryptographie symétrique pour chiffrer rapidement le reste de la session.

Sources :

Authentification

SSH supporte plusieurs méthodes d'authentification du client :

Mot de passe : simple mais moins sécurisé.
Clé publique / clé privée : méthode recommandée.
Autres méthodes : certificats SSH, clés de sécurité matérielles (FIDO), authentification à deux facteurs.

Ces méthodes sont détaillées dans la section suivante.

Sources :

Utilisations courantes

Administration à distance : gérer un serveur depuis un autre ordinateur via un shell interactif.
Exécution de commandes à distance : lancer des scripts ou des programmes sans ouvrir de session interactive.
Transfert sécurisé de fichiers :
- SFTP (SSH File Transfer Protocol), présenté plus loin.
- SCP (Secure Copy) : la commande scp existe toujours, mais depuis OpenSSH 9.0 elle utilise en interne le protocole SFTP. L'ancien protocole SCP est considéré comme dépassé.
Tunnels SSH : encapsuler du trafic non sécurisé dans une connexion SSH pour le protéger (exemple : accès à une base de données distante).
Développement et DevOps : accès aux dépôts Git (GitHub, GitLab, etc.), déploiement automatisé, CI/CD, gestion des infrastructures cloud.

Sources :

Authentification SSH

L'authentification SSH est le processus par lequel un client prouve son identité à un serveur distant. Elle a lieu après l'établissement du canal chiffré (voir la section suivante) : toutes les informations d'authentification circulent donc déjà de façon chiffrée.

Deux méthodes principales existent.

Authentification par mot de passe

Le client envoie son nom d'utilisateur et son mot de passe au serveur, à travers le canal chiffré.
Le serveur les vérifie auprès de son système de comptes. Le mot de passe n'y est normalement pas stocké en clair, mais sous forme d'empreinte (hash).
Simple à mettre en place.
Moins sécurisée :
- Vulnérable aux attaques par force brute (essais automatisés de nombreux mots de passe), surtout si le mot de passe est faible.
- Si l'utilisateur accepte sans vérification la clé d'un faux serveur (voir « Chiffrement de la communication avec SSH »), il transmet son mot de passe directement à l'attaquant. Le chiffrement protège le trajet, pas la destination.

Sources :

Authentification par clé publique (méthode recommandée)

Basée sur une paire de clés asymétriques :
- Une clé privée, conservée par le client et idéalement protégée par une phrase secrète (passphrase).
- Une clé publique, copiée sur le serveur dans le fichier ~/.ssh/authorized_keys du compte utilisateur.
Avantages :
- Plus sûre que les mots de passe : la clé privée ne quitte jamais l'ordinateur du client, donc même un faux serveur ne peut pas la récupérer.
- Permet de se connecter sans retaper de mot de passe à chaque fois : l'agent SSH garde la clé déverrouillée pendant la session de travail.
- Compatible avec des mécanismes avancés (agent SSH, certificats SSH, clés de sécurité matérielles).
Bonne pratique : une fois l'authentification par clé en place, désactiver l'authentification par mot de passe sur le serveur.

Sources :

Processus détaillé (clé publique)

Au moment de l'authentification, le canal chiffré est déjà établi. Le client et le serveur partagent un identifiant de session, une valeur unique pour cette connexion, issue de l'échange de clés.

Proposition de la clé
- Le client indique le nom d'utilisateur et la clé publique qu'il souhaite utiliser.
- Le serveur vérifie si cette clé publique figure dans le fichier ~/.ssh/authorized_keys de ce compte.
Signature
- Le client signe avec sa clé privée un ensemble de données qui contient l'identifiant de session.
- Comme cet identifiant est différent à chaque connexion, il joue le rôle de défi : la signature n'est valable que pour cette connexion-là.
Vérification
- Le serveur vérifie la signature avec la clé publique enregistrée.
- Si elle est valide, le client a prouvé qu'il possède la clé privée correspondante, sans jamais l'avoir envoyée.
Ouverture de la session
- L'utilisateur est authentifié. Le client ouvre alors un canal et demande un shell, une commande ou un transfert de fichiers.
- Les échanges restent chiffrés avec les clés issues de l'échange de clés, qui peuvent être renouvelées en cours de connexion.

Comme la signature dépend de l'identifiant de session, un serveur malveillant qui la recevrait ne pourrait pas la réutiliser pour se connecter ailleurs à la place de l'utilisateur.

Sources :

Source image : Générée avec Claude Opus 5.5 (High)

Chiffrement de la communication avec SSH

SSH garantit la confidentialité, l'intégrité et l'authenticité des échanges grâce à un mécanisme hybride. Il combine la cryptographie asymétrique (pour l'authentification et l'échange initial) et la cryptographie symétrique (pour la session).

Etapes du chiffrement SSH

Clés du serveur (clés d'hôte)
- Lors de son installation, le serveur SSH génère une ou plusieurs paires de clés (sous Linux, dans /etc/ssh/) :
  - Une clé privée, qui ne quitte jamais le serveur.
  - Une clé publique, transmise aux clients à chaque connexion.
Négociation des algorithmes
- Le client et le serveur échangent la liste des algorithmes qu'ils connaissent. Ils choisissent ensuite, pour chaque catégorie, le premier de la liste du client que le serveur prend aussi en charge :
  - la méthode d'échange de clés
  - le type de clé d'hôte
  - l'algorithme de chiffrement symétrique
  - l'algorithme d'intégrité, etc.
Echange de clés et authentification du serveur (une seule et même étape)
- Le client et le serveur réalisent un échange de clés de type Diffie-Hellman. Aujourd'hui, OpenSSH utilise par défaut un échange hybride résistant aux ordinateurs quantiques (voir la section Diffie-Hellman).
- Au cours de cet échange, le serveur envoie sa clé publique d'hôte. Il signe aussi avec sa clé privée un résumé de l'échange.
- Le client vérifie cette signature, puis vérifie que la clé publique appartient bien au serveur attendu :
  - Première connexion : le client ne connaît pas encore cette clé. Il affiche son empreinte (fingerprint) et demande à l'utilisateur s'il lui fait confiance. Idéalement, l'utilisateur compare cette empreinte avec une valeur obtenue par un autre moyen (administrateur, documentation). Si l'utilisateur accepte, la clé est enregistrée dans ~/.ssh/known_hosts.
  - Connexions suivantes : le client compare automatiquement la clé reçue avec celle enregistrée. Si elle a changé, SSH affiche un avertissement et refuse la connexion par défaut. Cela peut signaler une attaque man-in-the-middle, ou simplement une réinstallation du serveur.
- À la fin de l'échange, le client et le serveur partagent un secret commun, qui n'a jamais été transmis sur le réseau. Ils en dérivent les clés de session : pour chaque sens de communication, une clé de chiffrement et une clé d'intégrité.
Communication chiffrée
- À partir de ce moment, tous les échanges sont protégés, y compris l'authentification du client qui suit :
  - Confidentialité : chiffrement symétrique (par exemple AES ou ChaCha20).
  - Intégrité : un code d'authentification de message (MAC) est ajouté à chaque paquet, ou le chiffrement lui-même intègre ce contrôle (AES-GCM, ChaCha20-Poly1305). Toute modification d'un paquet est ainsi détectée.

⚠️ La protection contre l'attaque man-in-the-middle repose sur la vérification de la clé d'hôte. Accepter une clé sans la vérifier revient à faire confiance à n'importe quel serveur qui se présente.

Sources :

Source image : Générée avec Claude Opus 5.5 (High)

Ordre général dans SSH

Ouverture de la connexion
- Le client se connecte au port TCP 22 du serveur.
- Les deux parties annoncent leur version du protocole (par exemple SSH-2.0-OpenSSH_10.0).
Négociation des algorithmes
- Le client et le serveur s'accordent sur les algorithmes d'échange de clés, de clé d'hôte, de chiffrement et d'intégrité.
Echange de clés et authentification du serveur
- Les deux parties exécutent l'échange de clés et obtiennent les clés de session.
- Pendant cet échange, le serveur prouve son identité en signant avec sa clé d'hôte. Le client vérifie cette clé grâce à ~/.ssh/known_hosts, ce qui empêche les attaques de type man-in-the-middle.
- À partir de ce moment, tous les échanges sont chiffrés.
Authentification du client
- Le client s'authentifie dans le canal chiffré : par mot de passe, par clé publique ou par un autre mécanisme.
- Comme tout est déjà chiffré, même un mot de passe ne circule jamais en clair sur le réseau.
Ouverture de la session
- Le client utilise le service demandé : shell, commande à distance, transfert de fichiers ou tunnel.

Ces étapes correspondent aux trois sous-protocoles de SSH :

le protocole de transport (étapes 1 à 3)
le protocole d'authentification (étape 4)
le protocole de connexion (étape 5)

Sources :

FTP (File Transfer Protocol)

Le FTP (File Transfer Protocol) est un protocole de communication standard utilisé pour transférer des fichiers entre un client et un serveur sur un réseau, notamment Internet. C'est l'un des plus anciens protocoles d'Internet : sa version actuelle est normalisée depuis 1985 (RFC 959).

Particularité de FTP : il utilise deux connexions TCP distinctes :

La connexion de contrôle, ouverte pendant toute la session, qui transporte les commandes et les réponses.
La connexion de données, ouverte pour chaque transfert (fichier ou liste de répertoire).

Ports utilisés

Port 21 : connexion de contrôle (envoi des commandes et réponses).
Connexion de données, selon le mode utilisé (voir plus bas) :
- En mode actif, le serveur se connecte depuis son port 20 vers un port choisi par le client.
- En mode passif, le client se connecte à un port choisi dynamiquement par le serveur.

Sources :

Commandes FTP

FTP fonctionne grâce à des commandes textuelles normalisées. Quelques exemples :

USER : envoi du nom d'utilisateur.
PASS : envoi du mot de passe.
LIST : liste des fichiers du répertoire courant.
RETR : télécharger un fichier depuis le serveur.
STOR : envoyer (uploader) un fichier vers le serveur.
PASV : demander le passage en mode passif.

Les clients FTP en ligne de commande proposent des commandes plus simples, qu'ils traduisent en commandes du protocole. Les clients graphiques font de même à partir d'un glisser-déposer. Par exemple :

get fichier.txt (équivaut à RETR)
put fichier.txt (équivaut à STOR)

Sources :

Authentification

Classique : avec nom d'utilisateur et mot de passe.
Anonyme : certains serveurs permettent un accès public via un compte "anonymous".

Sources :

Sécurité

Le protocole FTP classique n'est pas sécurisé : les commandes, les données et même les identifiants et mots de passe transitent en texte clair. Ils peuvent être interceptés, et les fichiers peuvent être modifiés en cours de route sans que personne ne s'en aperçoive.

Solutions :

FTPS (FTP over TLS) : extension de FTP qui ajoute le chiffrement TLS. Elle existe en deux variantes :
- FTPS explicite (la variante normalisée) : la connexion commence sur le port 21, puis le client demande le chiffrement avec la commande AUTH TLS.
- FTPS implicite (ancienne variante, jamais normalisée et considérée comme obsolète) : la connexion est chiffrée dès le départ, sur le port 990.
SFTP (SSH File Transfer Protocol) : un protocole différent, qui fonctionne à l'intérieur d'une connexion SSH (voir section suivante).

Sources :

Note

Malgré leurs noms proches, FTPS et SFTP sont deux protocoles différents et incompatibles entre eux.

Modes de fonctionnement

Mode actif :

Le client ouvre un port de données (numéro supérieur à 1023) et communique ce numéro au serveur (commande PORT).
Le serveur initie la connexion de données vers ce port, depuis son port 20.
⚠️ Problème : cette connexion est souvent bloquée par le pare-feu ou la box Internet du client, car elle ressemble à une connexion entrante non sollicitée.

Mode passif :

Le client demande le mode passif (commande PASV).
Le serveur ouvre un port de données dynamique et communique son numéro au client.
Le client initie la connexion vers ce port.
✅ Toutes les connexions partent du client : ce mode fonctionne à travers les pare-feu et les box Internet côté client. C'est le mode utilisé par défaut par la plupart des clients actuels.
En contrepartie, l'administrateur du serveur doit ouvrir une plage de ports dans son pare-feu.

Sources :

Source image

Utilisations aujourd'hui

FTP a longtemps servi à publier des sites web, distribuer des logiciels et partager des fichiers. Il est aujourd'hui en net recul, en raison de son absence de sécurité :

Les navigateurs Chrome et Firefox ont retiré sa prise en charge en 2021.
Il est largement remplacé par SFTP, HTTPS et les services de stockage en ligne.

On le rencontre encore dans des systèmes anciens et sur certains équipements (par exemple des imprimantes multifonctions qui déposent des numérisations sur un serveur).

Sources :

SFTP (SSH File Transfer Protocol)

Le SFTP (SSH File Transfer Protocol) est un protocole sécurisé de transfert et de gestion de fichiers, qui fonctionne à l'intérieur d'une connexion SSH. On le rencontre parfois sous le nom de « Secure File Transfer Protocol », mais ce n'est pas son nom officiel.

Contrairement à FTPS, SFTP n'est pas une extension de FTP : c'est un protocole entièrement différent, malgré la ressemblance des noms.

Toutes les données (fichiers et commandes) sont échangées dans la session chiffrée de SSH, ce qui garantit confidentialité et intégrité.

Sources :

Note

SFTP n'a jamais été publié sous forme de RFC. Il est décrit par des brouillons de l'IETF. Sa version 3, définie en 2001, est celle qu'implémentent OpenSSH et la plupart des logiciels : c'est devenu un standard de fait. Depuis OpenSSH 9.0, la commande scp utilise elle aussi SFTP en interne.

Sources :

Port utilisé

Port par défaut : 22, identique à SSH, puisque SFTP passe par la connexion SSH.
Il est possible de configurer un autre port. Cela réduit les tentatives de connexion automatisées, mais ce n'est pas une véritable mesure de sécurité : un scan de ports complet retrouve facilement le service.

Sources :

Fonctions de gestion des fichiers

SFTP ne se limite pas au transfert : il offre un ensemble complet d'opérations de gestion de fichiers à distance, telles que :

Lister le contenu des répertoires.
Télécharger et téléverser des fichiers.
Supprimer, renommer ou déplacer des fichiers/répertoires.
Créer des répertoires.
Modifier les permissions et propriétaires des fichiers.

Sources :

Authentification

SFTP hérite des méthodes d'authentification de SSH (voir « Authentification SSH ») :

Mot de passe.
Paire de clés publique/privée (recommandée), dont l'utilisation est facilitée par l'agent SSH (ssh-agent).
Certificats SSH.

L'authentification par clé publique est la méthode la plus robuste. Si l'authentification par mot de passe est désactivée sur le serveur, il n'y a plus de mot de passe à voler ni à deviner.

Sources :

Sécurité

SFTP bénéficie de toute la sécurité de la connexion SSH (voir « Chiffrement de la communication avec SSH ») :

Chiffrement symétrique (ex. AES, ChaCha20) pour protéger la confidentialité des fichiers.
Codes d'authentification de message (MAC) pour garantir que les données n'ont pas été modifiées.
Authentification du serveur par sa clé d'hôte, puis du client (idéalement par clé).

Sources :

En pratique

En ligne de commande : sftp utilisateur@serveur ouvre une session interactive, avec des commandes proches de celles de FTP (ls, get, put, mkdir, etc.). La commande sftp est fournie avec OpenSSH sur Linux, macOS et Windows.
En mode graphique : des clients comme FileZilla, WinSCP (Windows) ou Cyberduck prennent en charge SFTP.

Sources :

Source image

Avantages par rapport à FTP/FTPS

Un seul port (22) au lieu de plusieurs : FTP et FTPS explicite utilisent le port 21 plus des ports de données, et FTPS implicite le port 990 plus des ports de données. SFTP est donc plus simple à faire passer à travers un pare-feu.
Sécurité native : tout le trafic (fichiers et commandes) est chiffré.
Authentification robuste avec paires de clés SSH, au lieu du simple mot de passe souvent utilisé avec FTP/FTPS.
Déjà disponible : un serveur SSH comme OpenSSH inclut en général un serveur SFTP, et le client sftp est fourni avec OpenSSH.

⚠️ SFTP n'est pas compatible avec FTP : il faut un client qui prend en charge SFTP (c'est le cas de la plupart des clients graphiques actuels).

Sources :

Comparaison FTP / FTPS / SFTP

	FTP	FTPS	SFTP
Basé sur	-	FTP + TLS	SSH
Chiffrement	❌ Aucun	✅ TLS	✅ SSH
Ports	21 + ports de données	21 + ports de données (explicite) ou 990 (implicite)	22 uniquement
Nombre de connexions	2 (contrôle + données)	2 (contrôle + données)	1
Authentification	Mot de passe (en clair)	Mot de passe, certificat	Mot de passe, clé publique
Statut	Obsolète pour tout usage sur Internet	Usage résiduel	Recommandé

Sources :

Vocabulaire

✅ Cryptologie : Science globale du secret, regroupant à la fois la cryptographie (protection des messages) et la cryptanalyse (attaque des systèmes de chiffrement).

✅ Cryptographie : Discipline de la cryptologie qui conçoit des méthodes pour protéger des informations. Elle assure la confidentialité (chiffrement), mais aussi l'intégrité et l'authenticité (signatures numériques).

✅ Cryptanalyse : Discipline de la cryptologie qui étudie les moyens de retrouver un message chiffré sans la clé, ou de casser un système cryptographique.

✅ Chiffrement : Procédé de cryptographie qui rend un message illisible à toute personne ne possédant pas la clé appropriée.

✅ Chiffrer : Action d'appliquer un algorithme de chiffrement à un message clair.

✅ Déchiffrer : Action de retrouver le texte clair à partir d'un message chiffré, avec la clé de déchiffrement.

✅ Décrypter : Action de retrouver le texte clair sans posséder la clé, par cryptanalyse ou par une attaque (ex. force brute). Exemple : pendant la Seconde Guerre mondiale, les Alliés ont décrypté les messages d'Enigma. Votre navigateur, lui, déchiffre chaque jour les connexions HTTPS.

✅ Clé : Information secrète (ou publique, en cryptographie asymétrique) utilisée par un algorithme pour chiffrer, déchiffrer, signer ou vérifier.

✅ Clé de session : Clé symétrique temporaire, valable pour une seule connexion, utilisée pour chiffrer les échanges (par exemple dans SSH ou HTTPS).

✅ Fonction de hachage / Empreinte : Une fonction de hachage calcule, à partir de données de taille quelconque, un résumé de taille fixe appelé empreinte (hash). Il est pratiquement impossible de retrouver les données à partir de l'empreinte. Ce n'est pas un chiffrement : il n'y a ni clé, ni retour en arrière possible.

✅ Signature numérique : Valeur calculée avec une clé privée, qui permet à quiconque possède la clé publique correspondante de vérifier l'origine et l'intégrité d'un message.

⛔ Crypter / Cryptage : Termes à éviter en contexte technique. Ils figurent dans certains dictionnaires, mais l'Académie française les déconseille et les spécialistes les rejettent. Par symétrie avec décrypter (retrouver le message sans la clé), crypter voudrait dire « chiffrer sans clé », ce qui n'a pas de sens. On dit chiffrer / chiffrement.

⛔ Encrypter / Désencrypter : Anglicismes issus de encrypt/decrypt. En français technique, on parle de chiffrer/déchiffrer.

⛔ Chiffrage : Désigne avant tout l'évaluation d'un coût (ex. chiffrage d'un devis). Le dictionnaire de l'Académie française l'admet aussi au sens de chiffrement, mais en contexte technique, on emploie chiffrement.

❗ Coder / Encoder / Décoder : Ces termes renvoient à la représentation ou la transformation des données (compression, format multimédia, encodage Base64, etc.). Contrairement au chiffrement, ils ne garantissent aucune sécurité : n'importe qui peut décoder, sans clé.

Sources :