Résumé

  • La version 8.7 d’OpenSSH a introduit en 2021 un mode SFTP expérimental pour scp. La version 9.0, publiée le 8 avril 2022, en a fait le mode de transfert par défaut.
  • L’ancien SCP/RCP confiait l’expansion des jokers au shell distant et imposait parfois de citer deux fois les caractères spéciaux. L’option -O conserve ce chemin pour les besoins de compatibilité, avec ses contraintes.

Le shell était un employé invisible

Dans scp hôte:*.txt ., qui décide quels fichiers correspondent à l’étoile? Avec le protocole historique SCP/RCP, c’était le shell du compte distant. Les notes de la version 9.0 exposent l’effet secondaire: des caractères spéciaux dans un nom exigeaient une double citation sur la ligne de commande. Une chaîne devait traverser l’interprétation locale, puis celle de la machine éloignée. On croyait demander un fichier; on rédigeait aussi des instructions pour un autre interprète.

Ce changement ne portait pas sur la protection de la connexion SSH. Le manuel actuel de scp(1) précise que SFTP passe toujours par SSH. La question était plutôt de savoir quel protocole échange les fichiers et quel logiciel décide du sens d’un chemin distant. Le shell du serveur perdait son rôle ordinaire dans l’expansion des jokers.

Une répétition générale en 2021

La publication d’OpenSSH 8.7 a proposé scp -s comme essai du mode SFTP. Ses auteurs décrivaient un traitement des noms plus prévisible et l’absence d’expansion par le shell distant. La même version a fait passer, par défaut, une copie entre deux hôtes distants par l’hôte local. Cette route évitait d’exposer des identifiants sur le premier hôte et de faire interpréter les noms par trois shells successifs. La migration se préparait au niveau des chemins réels, pas seulement dans une préférence de configuration.

En avril 2022, OpenSSH 9.0 a basculé le défaut. Les vieilles constructions de guillemets destinées au shell distant pouvaient alors faire échouer un transfert SFTP. Le projet l’a reconnu et a refusé de recréer cette bizarrerie dans le nouveau mode. Un défaut plus simple peut casser un script qui avait soigneusement appris à composer avec un défaut compliqué.

L’autre difficulté s’écrit ~user/. SFTP ne possède pas de mécanisme natif pour développer le répertoire personnel d’un autre utilisateur. OpenSSH 8.7 avait ajouté une extension de développement des chemins côté serveur. Un vieux serveur SFTP pouvait ne pas la proposer. Un client neuf ne met pas à jour son interlocuteur par télépathie.

La documentation actuelle conserve scp -O pour employer SCP/RCP: serveur sans SFTP, motif de nom particulier, expansion de ~ sur un serveur ancien. Ce détour réintroduit aussi l’analyse par le shell distant. L’option est une sortie de secours, avec l’ancien escalier.

Le nom stable a masqué la nouvelle frontière

Le manuel d’OpenBSD 7.3 décrit déjà un scp qui transfère par SFTP sur SSH. Le manuel actuel situe le changement de défaut à OpenSSH 9.0. Ces pièces montrent une transformation très précise: le nom de commande a survécu, le protocole de transfert ordinaire a changé, l’ancien protocole est devenu une exception. La frontière pratique se trouvait dans les noms de fichiers, les capacités des serveurs et les habitudes des scripts.

Une migration qui conserve l’interface visible peut paraître presque gratuite. Elle l’est seulement jusqu’au premier chemin cité pour un shell qui n’est plus invité, ou au premier serveur qui ne connaît pas SFTP. C’est là, dans une copie concrète, que le changement cesse d’être un titre de version et devient de l’histoire technique.