Commande SCP Linux pour transférer des fichiers en sécurité

Un administrateur doit parfois récupérer un export, pousser une archive de configuration ou copier un dossier de logs avant une intervention. La commande SCP répond bien à ce besoin : elle copie un fichier entre deux machines en s’appuyant sur SSH, avec la même logique d’authentification que la connexion distante. Pour une PME, l’intérêt est clair : un transfert ponctuel, rapide, scriptable et compréhensible sans déployer une plateforme complète ni changer les habitudes SSH existantes.

Mais SCP n’est pas un bouton “copier en sécurité” à utiliser sans réflexion. Depuis OpenSSH 9.0, l’outil utilise par défaut le protocole SFTP pour le transfert, tout en gardant la syntaxe familière de SCP. C’est une bonne nouvelle pour la robustesse, mais cela change certains comportements historiques, notamment les chemins avec jokers, les guillemets et les vieux serveurs.

À quoi sert vraiment la commande SCP sous Linux ?

SCP sert à copier des fichiers entre machines lorsque vous avez déjà un accès SSH valide. Il est utile pour un transfert ponctuel : récupérer un fichier de configuration, envoyer une archive, copier un rapport, déplacer un script validé ou rapatrier des logs avant diagnostic.

La forme la plus courante tient en une ligne : une source locale, un compte distant, puis le dossier de destination sur le serveur, avec une syntaxe assez stable pour être reprise dans une procédure interne.

scp rapport.pdf admin@serveur:/srv/partage/

Cette commande envoie le fichier local vers le serveur distant. Pour rapatrier un fichier, inversez simplement les deux côtés et gardez le dossier local de sortie explicite.

scp admin@serveur:/var/log/app/export.log ./

Le réflexe important est de lire la commande en deux blocs : source puis destination. Chaque bloc peut être local ou distant. Le bloc distant combine généralement un utilisateur SSH, un hôte et un chemin : utilisateur@hote:/chemin/fichier.

Ce format est pratique, mais il ne remplace pas une stratégie de sauvegarde ou de synchronisation. SCP copie ce qu’on lui demande, au moment où on le lance. Il ne compare pas finement les versions comme rsync, ne reprend pas naturellement un transfert interrompu et ne documente pas à lui seul la traçabilité métier.

Les commandes SCP à connaître en priorité

Pour un usage PME, quelques commandes couvrent la majorité des besoins. Le but n’est pas de mémoriser toutes les options, mais de construire des commandes lisibles, vérifiables et faciles à relire par un collègue.

Premier cas fréquent : envoyer une archive depuis votre poste vers un dossier prévu côté serveur, en utilisant un compte d’exploitation limité et un chemin cible déjà préparé.

scp sauvegarde.tar.gz [email protected]:/srv/backups/

Deuxième cas : rapatrier un fichier depuis le serveur vers le dossier courant de votre poste, par exemple avant une analyse locale ou une conservation temporaire.

scp [email protected]:/srv/backups/sauvegarde.tar.gz ./

Troisième cas : copier un dossier complet. L’option récursive doit être assumée, car elle peut transférer beaucoup plus que prévu.

scp -r ./exports [email protected]:/srv/imports/

Si SSH écoute sur un port non standard, utilisez -P en majuscule. C’est une erreur classique : -p en minuscule sert à préserver certains attributs, pas à définir le port.

scp -P 2222 fichier.conf deploy@serveur:/etc/app/

Pour une clé privée spécifique, ajoutez -i. Cette option est utile quand vous séparez les accès par environnement, par client ou par niveau de privilège.

Pour approfondir ce point, consultez chmod linux permissions, qui traite plus précisément de utiliser chmod sans ouvrir trop largement ses fichiers linux.

scp -i ~/.ssh/id_ed25519_prod fichier.conf deploy@serveur:/srv/app/

Bien gérer les chemins, espaces et caractères spéciaux

Beaucoup d’erreurs SCP ne viennent pas du réseau, mais d’un chemin mal formulé. Un espace dans un nom de dossier, un caractère interprété par le shell, un * utilisé trop vite ou un ~ placé côté distant peuvent changer le résultat. Sur un transfert critique, le chemin cible doit être explicite et relu avant exécution, idéalement par rapport à une procédure ou à un ticket validé, avec le sens source-destination confirmé.

Le plus simple est souvent d’éviter les noms ambigus dans les dossiers d’échange : pas d’espaces, pas d’accents, pas de caractères spéciaux inutiles. Si vous devez copier un fichier avec espace, protégez correctement le chemin.

scp "rapport final.pdf" deploy@serveur:/srv/exports/

Côté serveur, privilégiez les chemins absolus pour les opérations de production. /srv/app/imports/ est plus clair que ~/imports quand plusieurs comptes, scripts ou environnements sont en jeu. Ce choix paraît banal, mais il évite des copies dans le mauvais répertoire personnel ou dans un dossier créé par erreur.

Les jokers demandent encore plus d’attention. Selon le shell local, le serveur distant et le protocole utilisé, l’expansion peut ne pas se produire là où vous l’imaginez. Si vous devez sélectionner plusieurs fichiers, testez d’abord avec une liste courte ou une commande de vérification. Pour un lot régulier, un script contrôlé ou rsync avec filtres sera souvent plus lisible qu’une commande SCP pleine de caractères spéciaux difficiles à relire.

Options utiles sans transformer SCP en usine à gaz

Les options les plus utiles sont celles qui rendent le transfert plus clair ou plus contrôlable. -r copie un répertoire, -P définit le port, -i choisit la clé, -C active la compression et -v affiche les détails de négociation SSH. Cette dernière option est précieuse quand l’authentification échoue, quand la configuration SSH n’est pas celle attendue ou quand un alias masque un port différent de celui documenté.

Il existe aussi des options avancées, comme -J pour passer par un bastion SSH. Elles peuvent être très utiles dans une architecture d’entreprise, mais elles doivent être documentées. Une commande qui traverse un bastion, utilise une clé dédiée et écrit dans un dossier système ne doit pas finir dans un script sans commentaire ni contrôle de sortie.

Dans une équipe, le bon niveau de maturité consiste à standardiser les exemples, à éviter les variantes improvisées selon les postes et à garder une convention de nommage stable.

SCP, SFTP ou rsync : choisir le bon outil

SCP est excellent pour un transfert simple. SFTP convient mieux quand l’utilisateur doit naviguer, lister, déposer et récupérer plusieurs fichiers dans une session interactive. Rsync devient préférable quand il faut synchroniser un dossier, transférer seulement les différences, conserver finement les attributs ou relancer une opération de manière régulière sans recopier tout le volume à chaque passage.

La confusion vient du nom. Aujourd’hui, avec OpenSSH moderne, SCP utilise généralement SFTP sous le capot, mais sa logique d’usage reste celle d’une commande de copie directe. Cela ne le transforme pas en outil de synchronisation avancée.

En production, cette distinction évite beaucoup de scripts fragiles et force à choisir l’outil selon le besoin réel, pas selon l’habitude ou la commande retenue de mémoire.

Sécuriser SCP avec les bons réflexes SSH

La sécurité de SCP dépend principalement de SSH. La première priorité est donc de savoir à quel serveur vous vous connectez. Un changement de clé d’hôte ne doit pas être ignoré mécaniquement : il peut signaler une réinstallation légitime, une mauvaise entrée known_hosts, ou un risque d’interception. En environnement sensible, la vérification de l’empreinte doit être documentée avec une source interne fiable, pas validée dans l’urgence au milieu d’un incident.

La deuxième priorité concerne les clés privées. Une clé sans phrase de passe, copiée sur plusieurs postes, utilisée par plusieurs personnes et jamais renouvelée, crée une dette de sécurité. Mieux vaut une clé par usage important, un agent SSH maîtrisé, des permissions strictes et une procédure de révocation. Ce niveau de discipline paraît parfois lourd, mais il protège aussi l’entreprise lors d’un départ collaborateur, d’un poste perdu ou d’un accès client à fermer vite.

La troisième priorité est la destination. Beaucoup d’incidents viennent d’un chemin mal relu : fichier envoyé au mauvais endroit, écrasement d’une configuration, copie dans un répertoire trop exposé, permission incohérente après transfert. SCP sécurise le transport ; il ne corrige pas une mauvaise décision d’exploitation.

Préparer une configuration SSH lisible

Quand les commandes SCP deviennent longues, le fichier ~/.ssh/config peut clarifier les accès. Il permet de déclarer un alias SSH, un hôte, un utilisateur, un port et une clé par environnement. Au lieu de recopier partout une commande complexe, l’équipe utilise un nom stable, plus facile à auditer.

Pour approfondir ce point, consultez Maîtriser le protocole SMB pour optimiser le, qui traite plus précisément de maîtriser le protocole smb pour optimiser le partage de fichiers et la sécurité réseau.

Host prod-app
  HostName 10.0.0.20
  User deploy
  Port 2222
  IdentityFile ~/.ssh/id_ed25519_prod

La commande devient alors beaucoup plus lisible, car l’alias porte les paramètres SSH répétitifs et réduit le risque de faute de port, de clé ou d’utilisateur.

scp fichier.conf prod-app:/srv/app/

Ce confort ne doit pas masquer la gouvernance. Un alias SSH doit rester documenté, surtout lorsqu’il pointe vers une production, un bastion ou un client. Dans une PME, la configuration personnelle finit parfois par devenir une procédure de fait. C’est acceptable pour un usage individuel, mais insuffisant pour une exploitation partagée où plusieurs personnes doivent pouvoir reprendre un transfert sans deviner les habitudes du poste précédent ni fouiller un historique local.

La bonne pratique consiste à garder un modèle validé dans la documentation interne : noms d’alias, ports, utilisateurs, type de clé, dossier cible, règle de rotation et personne responsable. Ainsi, quand un poste est remplacé ou qu’un administrateur quitte l’entreprise, l’accès ne repose pas sur des souvenirs locaux.

Automatiser SCP sans créer un risque invisible

Automatiser SCP dans un cron ou un script de déploiement peut être légitime, mais seulement si l’échec est géré. Un script qui copie un fichier puis continue comme si tout avait fonctionné est dangereux. Il faut tester le code retour, journaliser l’opération, contrôler la présence du fichier cible et prévoir une alerte. Sans cela, le transfert devient un point aveugle : il semble automatisé, mais personne ne sait vraiment s’il a réussi.

Évitez aussi les commandes construites à partir d’entrées non maîtrisées. Les noms de fichiers, chemins et utilisateurs injectés dans une commande shell peuvent provoquer des surprises, surtout dans des scripts maison. Préférez des variables contrôlées, des guillemets cohérents et des chemins absolus pour les opérations répétées.

Pour des lots volumineux ou réguliers, posez-vous franchement la question de rsync. Son mode archive, ses filtres et sa capacité à éviter de recopier inutilement les fichiers en font souvent le meilleur choix industriel pour une synchronisation de dossiers.

• Testez le code retour de la commande avant de lancer l’étape suivante.
• Journalisez le transfert quand il concerne des données client, paie, finance ou production.
• Évitez les clés partagées entre plusieurs administrateurs ou plusieurs clients.
• Préférez rsync pour les synchronisations récurrentes et volumineuses.

Résoudre les erreurs SCP les plus fréquentes

La plupart des erreurs SCP viennent de quatre familles : authentification, nom d’hôte, chemin distant ou permission. Avant de chercher une faille complexe, testez SSH directement. Si ssh utilisateur@serveur échoue, SCP échouera aussi. Si SSH fonctionne, l’erreur se situe souvent dans le chemin distant, le port, la clé utilisée ou les droits sur le dossier cible.

Utilisez -v pour lire le détail de la négociation. Vous verrez quelle clé est proposée, quel fichier de configuration est chargé, quel port est utilisé et à quel moment la connexion échoue. Ce mode verbeux doit rester un outil de diagnostic, pas une sortie copiée telle quelle dans un ticket public, car elle peut révéler des chemins, des noms d’hôtes ou des informations d’environnement.

Un autre cas courant concerne les chemins distants. Les espaces, jokers et chemins avec ~ peuvent se comporter différemment selon le serveur, la version OpenSSH et le mode protocolaire utilisé. Si un ancien comportement est indispensable, l’option -O force le protocole SCP historique, mais elle doit rester un choix de compatibilité, pas un réflexe par défaut.

Vérifier le résultat après transfert

Un transfert terminé sans message d’erreur ne suffit pas toujours. Pour un fichier sensible, vérifiez sa présence, sa taille, ses permissions et, si nécessaire, son empreinte. Cette vérification peut être manuelle pour une opération ponctuelle, mais elle doit devenir automatique dans un script dès qu’il y a un impact production, client ou conformité. C’est le contrôle post-transfert qui transforme une copie en opération fiable et défendable.

Une méthode simple consiste à contrôler le fichier côté distant juste après la copie, avec le même compte SSH que celui utilisé pour le transfert et le même chemin cible.

ssh deploy@serveur "ls -lh /srv/app/fichier.conf"

Pour une archive importante, comparez une empreinte calculée localement et côté serveur. Cela prend quelques secondes et évite de découvrir trop tard une copie incomplète, un mauvais fichier ou une archive modifiée pendant le transfert.

Cette étape est particulièrement importante lorsque SCP sert à alimenter un traitement automatisé : import de données, restauration partielle, livraison de configuration, transfert de rapports clients. Dans ces cas, la preuve de transfert compte autant que la commande elle-même.

Deux points à contrôler quand SCP échoue

Dans la majorité des cas, le problème se trouve avant même le transfert du fichier.

Clé et identité SSH

Vérifiez la clé utilisée, les permissions locales et l’empreinte du serveur avant de relancer en boucle.

Chemin et accès réseau

Contrôlez le port, le nom d’hôte, le dossier cible et les droits d’écriture avec une commande SSH simple.

La priorité à retenir

SCP reste un outil simple et efficace pour copier un fichier via SSH, à condition de l’utiliser pour le bon besoin. Il convient très bien à une copie ponctuelle, à un transfert d’administration ou à un rapatriement rapide de logs. Il devient moins adapté quand vous devez synchroniser des dossiers, reprendre des transferts, historiser des sauvegardes ou garantir une traçabilité forte. La simplicité reste un avantage seulement si elle est encadrée.

La prochaine action est concrète : créez deux exemples validés pour votre équipe, un envoi et un rapatriement, avec utilisateur, port, clé et dossier cible. Ajoutez ensuite une règle de choix : SCP pour le ponctuel, rsync pour le récurrent, sauvegarde dédiée pour le critique. Cette discipline vaut mieux qu’une collection de commandes copiées depuis l’historique shell, surtout quand les transferts concernent des configurations, des exports clients ou des environnements de production.

Pour approfondir ce point, consultez Transférer Vos Fichiers en Toute Sécurité avec, qui traite plus précisément de comment transférer vos fichiers en toute sécurité avec ssh.