scp via SFTP : écrire des chemins distants qui se résolvent vraiment

Une commande scp qui fonctionnait dans un script depuis des années peut échouer sur un client actuel avec une erreur de chemin qui n'a rien à voir avec le tunnel. Le VPN a transporté les octets ; le client a demandé au serveur un nom que le serveur n'a pas pu résoudre. Le scp actuel d'OpenSSH transfère via SFTP par défaut, et SFTP ne fait pas d'expansion de style shell comme le faisait l'ancien protocole. Remonter la commande depuis votre propre compte vers l'extérieur montre où le chemin est réellement interprété.

Partez du compte, puis du répertoire où il peut écrire

Les deux-points séparent deux espaces de noms, et seul le côté gauche appartient à la machine sur laquelle vous tapez. Tout ce qui suit est résolu par le serveur, sous le compte avec lequel vous vous êtes authentifié, dans la vue du système de fichiers que possède ce compte. Confirmez les deux avant de composer la commande, car un chemin correct pour l'administrateur n'est pas automatiquement correct pour l'utilisateur du transfert. Cette différence est la source de la plupart des erreurs de permissions qui ressemblent à des pannes réseau.

Demandez au serveur sa propre vue : ssh [email protected] pwd et ssh [email protected] ls -ld /srv/archive. Si la seconde commande signale un accès refusé, le tunnel est intact et le chemin est inutilisable pour ce compte. Corrigez la propriété ou choisissez une autre destination plutôt que d'élargir les permissions pour que le transfert puisse continuer.

Une configuration SFTP restreinte peut présenter un chroot comme racine du système de fichiers. Dans cette vue, un chemin absolu est absolu à l'intérieur du chroot, ce qui n'est pas le même emplacement que celui que l'administrateur voit sur l'hôte.

Nommez explicitement les deux côtés des deux-points

Un envoi doit indiquer le nom du fichier distant au lieu de supposer que le nom de base local sera acceptable de l'autre côté.

scp q3-invoice.csv [email protected]:/home/transfer/drop/q3-invoice.csv

Un téléchargement doit indiquer la destination locale exactement pour la même raison. Les deux espaces de noms sont indépendants, et un script qui suppose qu'ils correspondent casse la première fois que l'arborescence distante utilise une disposition différente.

scp [email protected]:/srv/archive/2026-q3.csv ./2026-q3.csv

Évitez ~otheruser dans un script maintenu. L'expansion du répertoire personnel d'un autre compte était une fonctionnalité du shell distant, et un serveur SFTP peut ne pas implémenter l'extension qui l'émule. Écrivez le chemin absolu que le compte peut réellement ouvrir, et mettez entre guillemets les chemins locaux contenant des espaces au lieu de copier des couches de guillemets écrites pour un shell sur le serveur.

Sachez quel protocole votre scp utilise réellement

Depuis OpenSSH 9.0, le client utilise SFTP par défaut, et les distributions adoptent ou rétroportent ce comportement selon leur propre calendrier. La chaîne de version indique ce que le client prévoit, mais une compilation de fournisseur peut différer de l'amont, alors vérifiez le client que vous exécutez réellement : ssh -V.

Les deux protocoles résolvent les noms différemment. L'ancien SCP demande au shell de l'utilisateur distant d'étendre le chemin, donc les jokers et les tildes sont gérés par ce shell selon ses propres règles. SFTP émet plutôt des opérations de transfert de fichiers, donc un joker est soit étendu par le client, soit pas du tout. Les deux voyagent dans SSH vers la même machine, ce qui explique qu'un hôte puisse se comporter différemment sous deux clients.

scp -v imprime le sous-système qu'il demande, et une ligne de sous-système sftp confirme que le chemin moderne est utilisé. scp -O force l'ancien protocole là où il est pris en charge et réellement nécessaire, et il ramène ses propres règles de guillemets. Ce n'est pas une option VPN, pas un moyen d'activer quoi que ce soit sur le serveur, et pas une raison de relâcher la vérification de la clé d'hôte.

Testez le chemin avant que le script en dépende

Un problème de chemin surgit au pire moment possible, dans une tâche automatisée la nuit sans personne pour surveiller. Prouvez d'abord la destination avec un petit fichier et le compte exact que la tâche utilise, et gardez cette commande de test à côté de la définition de la tâche. Si le test a besoin d'un autre compte ou d'un autre répertoire, la tâche en aura besoin aussi.

Vérifiez aussi le côté serveur. grep -i subsystem /etc/ssh/sshd_config indique si un sous-système SFTP est configuré, et sftp -b /dev/null [email protected] ne se termine avec succès que lorsque ce sous-système répond. Un hôte qui accepte les connexions SSH mais n'a pas de sous-système échoue à chaque transfert moderne tout en semblant parfaitement sain lors d'un test de connexion.

Notez la version du client, le protocole utilisé et le chemin distant absolu dans les notes de la tâche. Lorsque la prochaine mise à jour changera une valeur par défaut, cette note fera la différence entre une correction de cinq minutes et un après-midi de suppositions.