> ## Content Index
> Fetch the complete content index at: https://tagazette.digitalpress.blog/llms.txt
> Use this file to discover other available public pages before exploring further.

# Le scanner parlait SFTP, Nextcloud parlait WebDAV, donc j’ai ouvert un bureau de traduction
- URL: https://tagazette.digitalpress.blog/scanner-sftp-vers-webdav/
- Published: 2026-09-28T04:00:00.000Z
- Updated: 2026-09-28T04:00:52.000Z
- Description: Un pont de dépôt a relié deux protocoles qui s’ignoraient ; le scanner exigeait du RSA, son bouton de test redémarrait la machine et le quota comptait ailleurs.
- Author: Julien CHATY-CAPELLE
- Tags: SFTP, WebDAV, Nextcloud, Linux, Brother, Généré par IA, #source-cyspace

Les protocoles de transfert de fichiers forment une famille au sens des repas de Noël : ils ont des noms proches, une longue histoire commune et très peu d’envie de se parler.

FTP date d’un Internet où envoyer un mot de passe en clair ne paraissait pas encore une provocation. SFTP a conservé trois lettres mais vit dans SSH et transfère des fichiers sur un flux sûr ; son effort de standardisation est d’ailleurs encore décrit comme un [Internet-Draft](https://datatracker.ietf.org/doc/html/draft-spaghetti-sshm-filexfer?ref=tagazette.digitalpress.blog). WebDAV, né comme extension d’HTTP à la fin des années 1990 puis révisé par la [RFC 4918](https://www.rfc-editor.org/info/rfc4918/?ref=tagazette.digitalpress.blog) en 2007, manipule des collections distantes avec des méthodes telles que `PROPFIND`, `PUT` ou `DELETE`.

Mon scanner Brother savait déposer vers FTP, SFTP ou CIFS. Mon Nextcloud savait recevoir du WebDAV. Chacun possédait donc une excellente solution de transfert, à condition de ne pas demander au fichier de traverser la pièce.

Le menu du scanner rendait la situation plus élégante encore. Il affichait cinq destinations : FTP, SFTP, dossier réseau, SharePoint et HTTP(S). Les deux dernières avaient même leur bouton radio. Leur éditeur répondait 401 sur ce modèle, tandis que les trois autres rendaient 200 dans la même session. Le firmware était partagé avec des scanners plus chers ; l’interface présentait les options de toute la gamme et la machine refusait celles qu’elle n’avait pas. Les radios mentaient, le 401 disait vrai.

## Le drapeau WebDAV qui ne voulait pas dire WebDAV

Le relevé des protocoles apportait une dernière fausse joie : `EnableWebDav=1`. J’en ai d’abord conclu que le scanner pouvait viser Nextcloud directement. Or ce drapeau décrivait la pile embarquée, pas les destinations de numérisation. Le seul client WebDAV prévu par le firmware était la fonction SharePoint, absente de ce modèle.

La distinction n’est pas académique. La page SharePoint est réservée par Brother à d’autres références ; aucune licence ni clé ne pouvait faire passer son 401 à 200\. Il ne manquait pas un réglage. Il manquait le produit situé une ligne plus bas dans le catalogue.

J’aurais pu placer un mot de passe d’application Nextcloud dans le scanner si l’appareil avait su s’en servir. Cela aurait ouvert tout le compte : Nextcloud ne borne pas ce mot de passe à un dossier. Le Brother, de son côté, rendait les mots de passe de ses profils en clair à toute session d’administration. Lui confier l’accès au nuage aurait donc consisté à mettre une clé générale dans une boîte qui affiche déjà ses secrets. L’informatique domestique offre parfois des choix d’architecture d’une grande limpidité.

Le pont devait vivre sur une petite machine Linux du réseau local :

```text
scanner ──SFTP──> boîte locale ──HTTPS PUT──> dossier Nextcloud

```

Le scanner ne conserverait qu’un secret SFTP borné à une boîte vide. La machine Linux garderait le jeton WebDAV. Si l’un était compromis, il ne donnerait ni un shell sur le collecteur, ni tout le compte Nextcloud.

## Une boîte volontairement misérable

Le compte SFTP n’a pas de shell et ne connaît qu’un répertoire `depot`. Un bloc `Match` de `sshd` lui impose `ChrootDirectory`, `ForceCommand internal-sftp -d /depot`, aucun forwarding et aucun TTY. La racine du chroot et ses parents appartiennent à root, comme l’exige OpenSSH ; seul le sous-répertoire de dépôt est inscriptible par le scanner.

Les témoins ont été joués dans les deux sens :

| Essai                        | Résultat                                       |
| ---------------------------- | ---------------------------------------------- |
| écrire dans /depot           | fichier créé                                   |
| lister hors de la prison     | seul depot apparaît                            |
| lire /etc de l’hôte          | FileNotFoundError                              |
| écrire à la racine du chroot | PermissionError                                |
| obtenir un shell             | « This service allows sftp connections only. » |

Le dernier message avait d’abord fait échouer le test, qui attendait une sortie vide. Il était pourtant la preuve exacte du refus demandé. Une garde correcte et un test faux produisent une situation très pédagogique, surtout pour la personne qui vient d’écrire le test.

Le serveur exécutait OpenSSH 10.0p2 sans `diffie-hellman-group*`, sans chiffrement CBC et sans `ssh-rsa` comme algorithme de signature. Si le scanner réclamait cette archéologie, il aurait fallu un second `sshd` sur un port isolé : les algorithmes de transport se négocient avant l’identité de l’utilisateur et ne peuvent pas être relâchés dans son seul bloc `Match`.

Cette concession n’a pas été nécessaire. La poignée de main moderne passait. Le scanner réservait son exigence historique à un autre endroit.

## Une requête où l’ordre des champs fait partie de l’API

Configurer le profil sans piloter le navigateur a révélé une interface HTTP d’une délicatesse rare. L’index du profil se trouve dans l’URL :

```text
GET /ft/scan_tosftp=2&&

```

Sans l’index, la machine rend 500\. Les champs du formulaire sont séparés par `&&`, pas par `&`. Leur ordre compte : le même corps réordonné rend 400\. Il faut reproduire exactement `createData()` dans le JavaScript de l’interface : les trente-six paramètres de numérisation, les champs SFTP, puis `ProfileIndex`, `Network_command` et `ScantoSFTP_Save`.

`Profile_Type` vaut 0 pour CIFS, 1 pour FTP, 2 pour SFTP, 7 pour HTTP(S) et 8 pour SharePoint. Les nombres 7 et 8 restent parfaitement configurables dans un formulaire dont les pages correspondantes n’existent pas sur la machine. Le firmware n’est pas incohérent ; il est simplement plus fidèle à sa base de code qu’au produit vendu.

Le profil possédait deux chemins d’enregistrement. `Network_command=SaveOnly` rendait 200 et conservait tout. `Network_command=SaveTest` devait vérifier la connexion. Il coupait la session HTTP, rendait le scanner muet au ping pendant vingt à trente secondes, puis le ramenait à `Ready`.

Le redémarrage a été reproduit deux fois. Le serveur SFTP n’a vu aucune connexion entrante : le test tombait avant le premier paquet réseau. Même corps, mêmes champs, seul `SaveTest` différait. Le bouton « tester » ne diagnostiquait donc pas une mauvaise poignée de main ; il redémarrait l’appareil avant de tenter la poignée de main. C’est une façon radicale d’éviter les faux positifs.

## Pas de TOFU, et seulement du RSA

Après un `SaveOnly`, le premier vrai dépôt a échoué avec « erreur d’authentification ». Côté serveur : aucun SYN, aucune ligne dans le journal, aucune activation de `ssh.socket`. Le scanner renonçait avant le réseau.

Son magasin de clés d’hôte était vide et son état interne disait `ServerPublickKeyisnull`, faute comprise. Contrairement à un client SSH interactif, il ne proposait aucune confiance à la première connexion. La clé du serveur devait être importée au préalable par deux requêtes : téléversement sur `/serverkeyupload`, puis commande `Import` sur `/ft/net_security_server_public_key`.

Une clé `ssh-ed25519` rendait 527\. Une clé `ssh-rsa` rendait 200 et apparaissait dans le magasin. Le scanner n’exigeait pas que le serveur signe les échanges avec l’antique `ssh-rsa` ; il exigeait une clé d’hôte de type RSA, que le serveur pouvait employer avec une signature SHA-2 moderne. Nuance décisive : ajouter une clé RSA ne demandait pas de ressusciter les algorithmes obsolètes pour tous les clients.

Une machine ne portant qu’une clé Ed25519 resterait invisible à ce Brother, et le symptôme serait une erreur d’authentification sans le moindre paquet sur le fil. Le pointeur à garder n’est donc pas « vérifier le pare-feu », mais « importer explicitement une clé d’hôte RSA dans le magasin du scanner ».

À 13:35, une vraie feuille a produit deux sessions SFTP successives et un PDF de 289 943 octets, avec un en-tête `%PDF-`, dans la boîte locale. Le scanner savait parfaitement parler à OpenSSH 10\. Il avait seulement refusé de lui adresser la parole avant les présentations officielles.

## Le quota de cinq gibioctets qui comptait zéro octet

La boîte partageait un volume avec d’autres services. Un quota de projet ext4, identifiant 2001, devait la borner à 5 Gio. Le service annonçait le projet, le plafond et le répertoire. `repquota` confirmait la limite. Tout était déclaré ; il ne restait qu’à regarder où le PDF avait réellement été compté.

Il était dans le projet zéro.

L’identifiant 2001 avait bien été posé récursivement sur les répertoires, mais le drapeau d’héritage `P` ne vivait que sur la racine :

```text
2001 --------------e----P-- /mnt/.../sftp
2001 --------------e------- /mnt/.../sftp/scanner
2001 --------------e------- /mnt/.../sftp/scanner/depot
   0 --------------e------- /mnt/.../depot/document.pdf

```

L’outil écrivait l’identifiant dans tout l’arbre existant, tandis que le drapeau d’héritage ne se propageait pas tout seul. Les répertoires avaient donc reçu le premier sans le second : la boîte pouvait remplir le volume entier pendant que son quota restait impeccablement vide.

Le correctif a posé l’héritage sur les trois répertoires. Un fichier témoin de 2 Mio créé au fond a alors augmenté le projet 2001 de 2 048 blocs. La contre-pression devenait réelle : boîte pleine, le dépôt SFTP échouerait et le scanner le montrerait à la personne devant l’écran, plutôt que d’engloutir le disque en silence.

## Un PUT aveugle vaut mieux qu’un client serviable

Côté Nextcloud, un lien public protégé par mot de passe vise seulement le dossier de dépôt. Ses permissions ont été mesurées méthode par méthode. En création seule, `PUT` rend 201 ; `OPTIONS`, `PROPFIND`, `GET` et `DELETE` rendent 405 ; sans secret, le même `PUT` rend 401.

Beaucoup de clients WebDAV commencent poliment par `OPTIONS` puis `PROPFIND`. Ils concluent qu’un partage en création seule est inutilisable avant d’essayer d’y créer quoi que ce soit. Passer les droits à lecture et mise à jour leur permettrait de sonder, mais ouvrirait aussi les fichiers au détenteur du jeton.

Le relais local n’avait aucune raison d’être poli. Il connaît le nom du fichier et émet directement son `PUT`. Un code 201 constitue l’acceptation ; seulement après cette réponse, il retire le fichier du spoule. Une destination qui refuse, expire ou disparaît laisse l’original local pour la prochaine tentative.

La garde a été éprouvée contre une destination qui accepte et trois qui refusent. Le premier PDF a donné :

```text
document.pdf remis (289943 octets, 201)
reprise — 1 remis, 0 conservé

```

Le spoule était vide et le fichier présent dans le dossier partagé. La portée recherchée interdisait au relais de le relire ; la preuve terminale était donc la réponse du serveur à l’écriture, pas une permission supplémentaire accordée pour rendre le test plus confortable.

## Les coordonnées de ce mariage arrangé

Les détails à conserver sont ceux qui ont réellement mordu :

```text
scanner Brother   profil SFTP de type 2, champs ordonnés et joints par &&
test intégré      SaveTest redémarre ; SaveOnly conserve le profil
confiance SSH     clé d’hôte RSA importée, Ed25519 refusée avec 527
spoule            chroot internal-sftp, quota de projet avec héritage P
Nextcloud         lien création seule : PUT 201, lecture et suppression 405
relais            effacement local uniquement après acceptation du PUT

```

Une feuille posée dans le chargeur arrive désormais dans Nextcloud sans donner au scanner un compte Nextcloud, sans ouvrir de shell sur le collecteur et sans accorder la lecture du dossier au relais. Le montage est composé de deux protocoles qui ne se rencontrent jamais et de trois refus qui font l’essentiel de sa sécurité.

Il aura fallu découvrir qu’un bouton WebDAV ne mène pas au WebDAV, qu’un bouton de test teste surtout le redémarrage, qu’une erreur SSH peut se produire avant IP et qu’un quota correctement affiché ne compte pas forcément les fichiers. Le résultat final paraît simple sur le schéma. C’est le privilège des schémas : les flèches n’ont jamais à importer une clé RSA dans un scanner.