Un sftp test bien préparé ne sert pas seulement à vérifier qu’une connexion répond. Il permet surtout de savoir si le tunnel SSH est ouvert, si l’authentification passe, si le répertoire distant est réellement exploitable et si un transfert simple peut s’exécuter sans surprise. Dans un contexte DevOps, je le considère comme un contrôle de bout en bout, utile autant avant un déploiement que dans une chaîne d’intégration continue.
Les points à vérifier avant de conclure que la connexion tient
- Le port SSH est joignable et ce n’est pas seulement un problème de pare-feu local.
- L’authentification fonctionne avec le bon utilisateur, la bonne clé et le bon hôte.
- Le sous-système SFTP est bien activé côté serveur et ne bloque pas après le login.
- Les droits sur le dossier cible permettent de lire, écrire ou lister selon le besoin.
- Le test doit valider un vrai aller-retour de fichier, pas uniquement l’ouverture d’une session.
- En automatisation, le signal utile est le code de sortie et le journal verbeux, pas un message vague.
Ce qu’un test SFTP doit vraiment valider
Je vois souvent des équipes s’arrêter trop tôt : la session s’ouvre, donc tout semble bon. En pratique, un contrôle SFTP utile doit valider plusieurs couches à la fois. Il faut d’abord confirmer que le transport SSH répond, ensuite que l’identité est acceptée, puis que le serveur expose bien le sous-système SFTP et que les chemins distants sont utilisables.
Autrement dit, le but n’est pas de “voir si ça se connecte”, mais de répondre à une question plus précise : est-ce que je peux transférer un fichier de façon fiable, répétable et scriptable ? C’est cette nuance qui évite les faux positifs en production.
- Un simple `ls` interactif ne suffit pas toujours, car il peut passer alors que l’écriture échoue.
- Un transfert réussi ne dit rien si le répertoire est limité par un chroot ou par des ACL trop strictes.
- Un test vraiment utile doit produire un résultat exploitable par un humain et par une machine.
Une fois ce périmètre posé, je prépare le terrain pour éviter de lire une erreur réseau comme un problème d’identifiants.
Préparer l’environnement avant de lancer la vérification
Avant même d’ouvrir le client, je vérifie quatre choses : le port, l’utilisateur, la clé et le répertoire cible. C’est banal, mais c’est là que se cachent la majorité des échecs. Dans beaucoup d’incidents, la connexion n’est pas cassée ; elle est simplement mal cadrée.
| Point à contrôler | Ce que je regarde | Symptôme classique si ce point manque |
|---|---|---|
| Port SSH | Le service écoute bien sur le port attendu, souvent 22 mais parfois un port personnalisé. | `Connection refused`, timeout, ou bonne connexion sur le mauvais service. |
| Utilisateur et clé | Le compte distant existe, la clé publique est autorisée, et les permissions de `~/.ssh` sont correctes. | `Permission denied (publickey)` ou authentification qui boucle. |
| Répertoire cible | Le dossier demandé est lisible, et s’il faut écrire, il est bien inscriptible. | Session ouverte mais `put` ou `ls` refusé. |
| Configuration serveur | Le sous-système SFTP est déclaré, ou le serveur force correctement `internal-sftp` si c’est le choix retenu. | `subsystem request failed` au moment de l’entrée en session. |
Je prends aussi en compte les environnements avec bastion, filtrage IP ou VLAN séparé, parce qu’un test lancé depuis mon poste ne reflète pas toujours le trajet réel d’un job CI. Quand cette base est propre, le test lui-même devient lisible et beaucoup plus rapide à diagnostiquer.
La séquence de contrôle que j’utilise en pratique
Quand je veux vérifier une connexion SFTP sans perdre de temps, je procède par couches. Je commence par isoler la couche SSH, puis je passe au client SFTP en mode verbeux, et seulement ensuite je teste les opérations de fichier. Cette progression évite de confondre un problème réseau, d’authentification ou de droits.
- Je confirme que le serveur répond au niveau SSH avec un client verbeux.
- J’ouvre ensuite une session SFTP sur le bon port avec `-v` pour obtenir un journal exploitable.
- Je liste le répertoire distant et je vérifie le chemin courant.
- Je transfère un petit fichier de test, puis je le récupère.
- Je ferme proprement la session et je note le comportement exact en cas d’échec.
ssh -v utilisateur@serveur
sftp -v -P 22 utilisateur@serveur
sftp> pwd
sftp> ls -la
sftp> put ./test.txt
sftp> get ./test.txt
sftp> byeCe que j’observe en priorité, ce n’est pas la sortie “jolie”, mais le moment précis où le flux casse. Si `ssh` passe mais que `sftp` échoue juste après l’authentification, je soupçonne d’abord le sous-système ou les droits du dossier. Si la session ne s’ouvre même pas, je reviens au port, à la clé et au pare-feu.
Quand cette séquence manuelle est stable, je peux la transformer en contrôle non interactif pour un pipeline.
Automatiser le contrôle dans un pipeline DevOps
En CI/CD, je préfère un test court, déterministe et sans saisie humaine. Le mode batch de SFTP est utile ici, parce qu’il permet d’exécuter une série de commandes et de s’appuyer sur un code de sortie clair. C’est exactement ce qu’il faut pour bloquer un déploiement quand le transfert ne passe plus.
printf "ls\nbye\n" | sftp -b - -P 22 utilisateur@serveur| Mode | Usage | Ce qu’il prouve | Limite principale |
|---|---|---|---|
| Manuel | Diagnostic ponctuel | Je vois les prompts, les chemins et les réactions du serveur. | Peu reproductible dans une chaîne automatisée. |
| Batch | Script ou tâche planifiée | Le transfert échoue ou réussit sans intervention. | Nécessite une authentification non interactive. |
| Pipeline | Vérification avant release | Je peux bloquer une livraison si l’accès aux fichiers est cassé. | Il faut définir un timeout propre, souvent entre 15 et 30 secondes selon le réseau. |
Dans un pipeline, je recommande aussi de figer le fichier `known_hosts` et de refuser les invites interactives. Sans cela, un changement d’empreinte serveur peut bloquer le job au pire moment, ou pire, être accepté sans contrôle réel. L’automatisation révèle vite les régressions, mais elle n’a de valeur que si le journal reste exploitable.
Décrypter les erreurs sans perdre une heure
Quand un test SFTP échoue, le message affiché donne souvent la moitié de l’histoire. Je regarde d’abord le symptôme, puis je remonte à la couche correspondante. Cette discipline évite les corrections au hasard, qui font gagner cinq minutes et en perdent trente.
| Message ou symptôme | Cause probable | Vérification utile |
|---|---|---|
| `Connection refused` | Le service SSH n’écoute pas, le port est faux ou un pare-feu bloque la route. | Vérifier l’état du service, le port déclaré et le filtrage réseau. |
| `Permission denied (publickey)` | La clé publique n’est pas autorisée, l’utilisateur est incorrect ou les droits sur `authorized_keys` sont mauvais. | Comparer l’utilisateur attendu avec celui du serveur et valider les permissions du répertoire SSH. |
| `subsystem request failed` | Le sous-système SFTP n’est pas configuré ou pointe vers le mauvais binaire. | Revoir la configuration `sshd` et le mode `internal-sftp` si nécessaire. |
| `Host key verification failed` | L’empreinte du serveur a changé ou le fichier `known_hosts` est incohérent. | Comparer l’empreinte par un canal fiable avant toute mise à jour locale. |
| Connexion ouverte, mais `put` ou `ls` refusé | Droits insuffisants, chroot actif ou répertoire cible mal choisi. | Tester un autre chemin et vérifier les ACL, les permissions POSIX et les restrictions du compte. |
Je trouve que cette lecture par couche est la plus rentable en production, parce qu’elle ramène chaque erreur à un niveau précis. Une fois ce tri fait, il reste à sécuriser le test pour qu’il soit fiable dans la durée, pas seulement un jour donné.
Les règles que je garde en place avant de le considérer fiable en production
Un bon test SFTP n’est pas seulement un contrôle de connectivité. C’est un petit scénario reproductible qui dit si la chaîne réseau, l’authentification et les droits sont encore sains. Pour qu’il tienne dans le temps, je garde quelques règles simples.
- J’utilise un compte dédié avec le minimum de droits nécessaires.
- Je préfère l’authentification par clé, surtout dans un job automatisé.
- Je fige la clé d’hôte dans `known_hosts` et je traite toute dérive comme un événement à vérifier.
- Je teste un fichier réel, même minuscule, au lieu de me contenter d’un listing de dossier.
- Je journalise le résultat, le temps de réponse et le chemin testé pour faciliter l’audit.
- Je distingue toujours le test de transport du test fonctionnel métier, parce que les deux ne couvrent pas la même panne.
Quand je mets ce cadre en place, la vérification SFTP cesse d’être un rituel fragile et devient un vrai garde-fou de déploiement. C’est précisément ce que j’attends d’un contrôle DevOps utile : court, explicite, automatisable et assez strict pour détecter un problème avant qu’il n’atteigne la production.
