scp ne fonctionne pas mais ssh oui

Une cause possible de ce type de comportement est l'impression de tous messages pendant le processus de connexion sur le serveur. Scp dépend de ssh pour fournir un tunnel crypté totalement transparent entre le client et le serveur.

Vérifiez tous les scripts de connexion sur le serveur, et essayez également d'utiliser un utilisateur différent. Une autre méthode pour identifier la source de l'erreur est d'utiliser le -v dans la commande, pour suivre la progression de la transaction, et voir où elle échoue. Vous pouvez utiliser jusqu'à -vvv pour augmenter la verbosité, si nécessaire. La vérification des différentes formes de scp peut également être instructive, comme le précise le post de InChargeOfIT.

scp, sous le capot, met en place un tunnel en utilisant ssh, puis transfère le fichier par ce tunnel, avec une commande ssh à l'extrémité pour attraper le fichier au fur et à mesure qu'il arrive. Ceci est illustré par l'utilisation de tar et ssh pour copier une structure de répertoire en préservant la propriété et les temps de création avec les commandes suivantes :

tar czf - ./* | ssh jf@otherserver.com tar xzf - -C ~/saved_tree

pour l'envoyer, et

ssh jf@otherserver.com "tar czf - ~/saved_tree" | tar xzvf - -C ./

pour le récupérer.

Vérifiez le fichier .bashrc de l'utilisateur cible ou un fichier équivalent. Le fichier ~/.bashrc est destiné aux connexions non interactives. S'il y a un écho ou une commande qui produit quelque chose, cela brisera le protocole SCP.

Modifier : Êtes-vous sûr d'entrer un chemin d'accès valide dans la commande scp ? Par exemple :

scp test.txt username@remoteserver.com

va échouer (en fait, il va juste imprimer la commande comme vous le voyez). Dans ce cas, vous devrez fournir un chemin d'accès valide au serveur distant… par exemple : scp test.txt username@remoteserver.com:~/

Exemples d'utilisation :

Envoyer un fichier :

scp /path/to/local/file yourremoteusername@servername.com:/path/to/remote/directory

Obtenir un fichier :

scp yourremoteusername@servername.com:/path/to/remote/file /path/to/local/directory

Exemples :

Envoyer un fichier de mon bureau vers mon dossier personnel sur un serveur distant :

scp ~/Desktop/myfile.txt john_doe@10.1.1.10:~/

Souvenez-vous que le ~ est un raccourci pour votre répertoire d'origine… par exemple, /home/

Envoyez un fichier à la racine du site :

scp ~/Documents/working/index.html john_doe@johndoe.com:/var/www/index.html

Dans cet exemple, l'utilisateur john_doe aurait besoin de privilèges d'écriture sur le répertoire distant /var/www.

Sur certains hôtes, la source .bash_profile est incorrecte pour les connexions non interactives telles que scp. Les messages qui sont imprimés sur le terminal peuvent éventuellement faire en sorte que scp ne fonctionne pas correctement. Si vous avez des messages dans votre .bash_profile, cela peut en être la cause.

Pour que vos messages de connexion, bannière, etc. s'affichent toujours sur les connexions interactives et que vous puissiez toujours utiliser scp via une connexion non interactive, ajoutez ce qui suit avant tout message qui s'imprimerait dans votre fichier .bash_profile.

# **********If not running interactively, don't do anything more!***********

[-z "$PS1"] && return

Le code alternatif est :

[[$- == *i*]] || return

Et un autre code alternatif :

case $- in
    *i*) ;;
      *) return;;
esac

Ce qui est, je crois, la version la plus longue du premier code alternatif. J'ai constaté que sur certains hôtes, le premier code ne fonctionne pas correctement, mais le second oui.

Lors d'une connexion scp non interactive, il interrompra l'exécution de .bash_profile et permettra à scp de fonctionner, mais affichera vos messages de connexion lorsque vous vous connecterez via ssh.

Note: Il peut également être utilisé dans votre fichier .bashrc si vous le sourcez à partir de .bash_profile (pour $PATH), de sorte qu'une partie seulement est source lors de connexions non interactives.

J'appelais exec /bin/bash dans .cshrc.

La suppression de ce numéro a résolu le problème pour moi.

Cela ne répond pas directement à la question, mais pourrait être utile à des gens comme moi, qui cherchent une solution avec un scp de gel lors du transfert de fichiers entre 2 hôtes distants.

Si scp se bloque à cause de messages provenant de ssh, cela pourrait aider à les surcharger :

scp -o "StrictHostKeyChecking no"

et / ou

scp -B

Du scp man:

-B Sélectionne le mode batch (évite de demander des mots de passe ou des phrases de passe).

-o ssh_option Peut être utilisé pour passer des options à ssh dans le format utilisé dans il n'y a pas d'indicateur de ligne de commande scp séparé. Pour plus de détails sur les options énumérées ci-dessous, et leurs valeurs possibles, voir ssh_config(5).

Dans mon cas, cela a semblé aider, mais n'a pas résolu tout le problème. Nous n'avons pas pu trouver pourquoi scp s'accroche lors d'un transfert de distant à distant. Il s'accrochait au milieu du fichier. 9 fois ça a marché, la tentative numéro 10 n'a pas marché. Nous avons soupçonné qu'il pouvait être bloqué lorsque notre connexion VPN connaît un pic de trafic pendant un moment et que scp ne se rétablit pas. En fait, elle est bloquée pour toujours et ne donne même pas de message d'erreur.

Cependant, j'ai abandonné et je suis passé à sftp. C'est raisonnablement plus rapide, car il utilise une connexion directe entre les hôtes distants. Vous devez cependant activer

Host example.com
    AgentForward yes

dans le fichier ~/.shh/config de la machine qui exécute le script. Bien sûr, ce n'est une solution que si les machines distantes se trouvent toutes deux dans votre réseau de confiance.