web-dev-qa-db-fra.com

scp échoue avec "erreur de protocole: le nom de fichier ne correspond pas à la demande"

J'ai un script qui utilise SCP pour extraire un fichier d'un hôte Linux distant sur AWS. Après avoir exécuté le même code tous les soirs pendant environ 6 mois sans problème, il a commencé à échouer aujourd'hui avec protocol error: filename does not match request. J'ai reproduit le problème sur certains noms de fichiers plus simples ci-dessous:

$ scp -i $IDENT $Host_AND_DIR/"foobar" .
# the file is copied successfully

$ scp -i $IDENT $Host_AND_DIR/"'foobar'" .
protocol error: filename does not match request
# used to work, i swear...

$ scp -i $IDENT $Host_AND_DIR/"'foobarbaz'" .
scp: /home/user_redacted/foobarbaz: No such file or directory
# less surprising...

La raison de mes guillemets simples était que je récupérais un fichier avec des espaces dans le nom à l'origine. Pour gérer les espaces, j'avais fait $Host_AND_DIR/"'foo bar'" Pendant plusieurs mois, mais à partir d'aujourd'hui, il n'accepterait que $Host_AND_DIR/"foo\ bar". Donc, mon problème est corrigé, mais je suis toujours curieux de savoir ce qui se passe.

J'ai googlé le message d'erreur, mais je n'en vois aucune mention réelle, ce qui me surprend.

Les deux hôtes impliqués ont OpenSSL 1.0.2g Dans la sortie de ssh -v localhost, Et bash --version Dit GNU bash, version 4.3.48(1)-release (x86_64-pc-linux-gnu) Des idées?

16
dcc310

J'ai fini par jeter un œil au code source et j'ai trouvé le commit où cette erreur est levée:

GitHub Commit

les copies du répertoire distant-> local satisfont le caractère générique spécifié par l'utilisateur.

Cette vérification offre une certaine protection contre un serveur malveillant envoyant des noms de fichiers inattendus, mais elle risque de rejeter les fichiers voulus en raison des différences entre les règles d'extension génériques client et serveur.

Pour cette raison, cela ajoute également un nouvel indicateur -T pour désactiver la vérification.

Ils ont ajouté un nouveau drapeau -T qui ignorera cette nouvelle vérification qu'ils ont ajoutée afin qu'elle soit rétrocompatible. Cependant, je suppose que nous devrions regarder et découvrir pourquoi les noms de fichiers que nous utilisons sont marqués comme restreints.

30
JBond