Dans beaucoup d’équipes IT et IoT, le transfert de fichiers entre serveurs reste un geste quotidien : pousser un binaire sur un nœud de calcul, rapatrier des journaux d’un serveur de production, déplacer une sauvegarde vers un coffre-fort numérique.
Quand ces opérations passent encore par un FTP bricolé ou un partage réseau non chiffré, chaque copie devient un risque. Avec SCP sous Linux, ces mouvements s’appuient sur SSH, un protocole sécurisé qui chiffre tout le trafic et s’intègre naturellement dans les outils d’automatisation.
Dans les infrastructures actuelles, souvent hybrides et distribuées, la copie directe serveur à serveur prend une importance particulière. Un cluster Kubernetes sur un cloud public, une base de données hébergée sur une distribution Linux stable type Rocky Linux, quelques Raspberry Pi en périphérie : si chaque nœud échange ses fichiers de manière hétérogène, la maintenance devient vite chaotique.
SCP, lui, propose une syntaxe minimaliste, des options suffisantes pour gérer les cas concrets, et s’appuie sur une authentification robuste par clé publique ou mot de passe.
Ce texte se concentre volontairement sur les usages « terrain » : comment s’appuyer sur SCP pour des copies de serveur à serveur, comment préparer l’environnement SSH, quelles options activer en fonction du contexte, et surtout quels pièges éviter.
L’objectif n’est pas de réciter un manuel, mais de donner des modèles de commandes réutilisables, une grille de lecture pour choisir entre SCP, SFTP et rsync, et quelques réflexes de sécurité adaptés à des environnements qui doivent tourner sans drame le lundi matin.
En bref
- SCP s’appuie sur SSH pour chiffrer le transfert de fichiers et reste adapté aux copies rapides entre machines Linux, en particulier de serveur à serveur.
- La clé du confort d’usage, c’est l’authentification par clé publique et un fichier ~/.ssh/config propre, sans saisie de mot de passe répétitive.
- Pour des répertoires volumineux ou des synchronisations fréquentes, rsync ou SFTP prennent le relais, mais SCP garde toute sa pertinence pour les déploiements ponctuels.
- Les options -r, -p, -P, -i, -C, -J et -l couvrent 90 % des besoins réels en copie distante, y compris derrière un bastion.
- La sécurité repose sur quelques habitudes simples : vérification des clés d’hôte, comptes non privilégiés, logs surveillés et chemins correctement cités.
SSH et SCP sous Linux : bases solides pour un transfert de fichiers sécurisé
Avant de parler d’options exotiques, il reste utile de rappeler le socle : tout ce que fait SCP repose sur SSH. Sans démon SSH fonctionnel côté serveur, la copie échoue. C’est trivial, mais on voit encore des environnements où un serveur minimal a été installé sans les utilitaires OpenSSH, d’où les fameux « scp : command not found » quand on essaie de tirer un fichier.
SSH, pour mémoire, établit un tunnel chiffré entre un client et un serveur. Le serveur écoute par défaut sur le port TCP 22, annonce la liste de ses algorithmes de chiffrement et de compression, et négocie avec le client un jeu commun. Ensuite, il s’authentifie auprès du client via sa clé d’hôte, stockée côté client dans le fichier ~/.ssh/known_hosts. C’est là que l’on accepte ou non l’empreinte lors de la première connexion.
Une fois ce socle en place, l’authentification utilisateur entre en jeu : soit par mot de passe, soit par clé publique. Dans un environnement sérieux, les mots de passe devraient rester l’exception. Les clés sont stockées côté client (par exemple dans ~/.ssh/id_ed25519 pour la clé privée) et côté serveur dans ~/.ssh/authorized_keys. SCP réutilise exactement ce mécanisme et ne rajoute pas sa propre couche d’authentification.
Sur Linux, la pile la plus courante reste OpenSSH, installée par défaut sur beaucoup de distributions : Ubuntu, Debian, Rocky Linux ou d’autres déclinaisons orientées serveur. Sur certaines images minimales, il faut quand même penser à l’installer explicitement, comme on le ferait pour un paquet RPM via la démarche décrite dans ce guide sur les fichiers RPM.
La commande SCP, elle, adopte une syntaxe volontairement compacte : scp [options] source cible. Dès qu’un des chemins contient une séquence de type user@host:, SCP considère qu’il s’agit d’un chemin distant. Sans deux-points, c’est un chemin local. Cette règle simple évite les ambigüités, à condition de rester discipliné sur les guillemets autour des chemins complexes.
Depuis les versions récentes d’OpenSSH, un changement discret a eu lieu : la commande scp utilise en coulisse le protocole SFTP plutôt que l’ancien protocole SCP historique. Pour l’utilisateur, les commandes ne changent pas, mais la gestion des chemins et des caractères spéciaux devient plus fiable. C’est une évolution salutaire, qui n’invalide pas les habitudes existantes.
Un exemple de base, pour fixer les idées. Copier un fichier de configuration nginx du serveur vers le poste d’admin :
scp admin@web-prod:/etc/nginx/nginx.conf ./
La commande reste lisible, ne nécessite aucune configuration spéciale et offre un transport chiffré. Cette simplicité explique pourquoi de nombreux administrateurs continuent de privilégier SCP pour tout ce qui tient dans un fichier ou un répertoire raisonnable.
Pour une infrastructure distribuée, cette bascule de mentalité vers « tout passe par SSH, donc SCP » sert de colonne vertébrale. Le reste se joue sur l’ergonomie d’usage et les options avancées, sujet de la section suivante.
Syntaxe SCP et options indispensables pour les copies serveur à serveur
Dès qu’un environnement rassemble plusieurs machines Linux, la copie serveur à serveur devient un scénario classique. On retrouve souvent la même scène : un serveur A qui génère des sauvegardes, un serveur B qui les stocke sur un disque plus robuste ou dans un réseau séparé. SCP offre deux manières de faire cela, avec ou sans transit de données par la machine de l’administrateur.
La forme la plus simple ressemble à une copie distante classique, déclenchée depuis le poste d’admin :
scp sauvegarde.tar.gz backup@serveur-b:/data/
Mais SCP sait aussi transférer depuis un hôte distant vers un autre sans passer directement par le disque local, grâce à l’option -3 :
scp -3 admin@serveur-a:/var/backups/db.sql backup@serveur-b:/data/
Dans ce cas, les données transitent quand même par votre machine, mais uniquement en mémoire. Pour des volumes raisonnables, cette approche évite d’encombrer un disque local et garde une seule commande à surveiller.
Les options clés méritent un rappel, car certaines confusions coûtent du temps. Le duo le plus commenté reste -P (port) et -p (préserver les métadonnées) :
- -r pour copier récursivement un répertoire.
- -p pour conserver dates et permissions.
- -P 2222 pour se connecter sur un port SSH non standard.
- -i ~/.ssh/id_ed25519 pour forcer l’utilisation d’une clé privée précise.
- -C pour compresser les données en transit, utile sur des liaisons à latence élevée.
- -J bastion@passerelle pour passer par un hôte de rebond (bastion).
Une commande concrète de déploiement d’application combine souvent plusieurs de ces options. Supposons un dossier de site web à envoyer vers une machine de production derrière un bastion :
scp -r -p -C -J ops@bastion webapp/ deploy@web-int:/var/www/webapp/
Ce genre de ligne devient un classique des scripts de déploiement maison. La compression amortit les coûts de latence, la préservation des dates facilite le diagnostic de version, le bastion respecte la segmentation réseau.
Les chemins contenant des espaces ou des caractères spéciaux nécessité une rigueur minimale. Une erreur fréquente consiste à oublier de citer la partie distante, ce qui laisse le shell local développer les jokers (*) avant l’envoi :
scp ‘logs@serveur:/var/log/app/*.log’ ./logs/
Ce simple guillemet évite pas mal de surprises. Même chose pour un fichier local avec espace :
scp « Mon rapport.pdf » user@serveur:/home/user/docs/
Pour garder une vue structurée des usages, un tableau comparatif des scénarios typiques aide les équipes à choisir les bonnes options sans passer par un manuel à chaque fois.
| Cas d’usage | Commande SCP type | Options clés |
|---|---|---|
| Copie simple vers un serveur web | scp index.html web@host:/var/www/html/ | Aucune, syntaxe minimale |
| Déploiement d’un répertoire applicatif | scp -rp ./site/ web@host:/var/www/html/ | -r récursif, -p métadonnées |
| Sauvegarde vers un port SSH custom | scp -P 2222 backup.tar.gz backup@host:/data/ | -P port non standard |
| Transfert via bastion | scp -J ops@bastion admin@priv:/etc/nginx/nginx.conf ./ | -J hôte de rebond |
| Copie serveur A vers serveur B | scp -3 db@a:/var/backups/dump.sql db@b:/var/restore/ | -3 transit via client |
Une fois ces modèles assimilés, la difficulté réelle ne vient plus de la syntaxe, mais de la gestion des clés, des droits et de la sécurité globale, sujet qui mérite un traitement à part entière.
Ce socle de commandes couvre déjà une bonne partie des besoins. La suite consiste à faire disparaître les mots de passe et fiabiliser les connexions.
Préparer un environnement SSH propre pour un SCP sans friction
Les copies interactives demandant un mot de passe à chaque commande passent encore pour tolérables sur un petit lab. Sur un parc de serveurs, c’est surtout un signe que l’authentification SSH n’a pas été correctement industrialisée. La première marche reste la génération et le déploiement des clés publiques, de façon reproductible.
Pour un usage courant, les clés ed25519 offrent un bon compromis entre sécurité et performance. Une clé se crée de manière standard :
ssh-keygen -t ed25519 -C « ops@infra »
Par défaut, la clé privée sera stockée dans ~/.ssh/id_ed25519 et la clé publique dans ~/.ssh/id_ed25519.pub. L’étape suivante consiste à pousser cette clé publique vers chaque serveur cible :
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@serveur
Si l’outil ssh-copy-id n’est pas disponible, il reste possible de copier manuellement le contenu de la clé publique dans ~/.ssh/authorized_keys sur le serveur, avec les permissions adaptées : directory en 700, fichier en 600. Ce détail paraît anodin, mais une mauvaise permission suffit à faire échouer l’authentification par clé, et à encourager un retour aux mots de passe.
Pour les équipes qui gèrent des dizaines de machines, le fichier ~/.ssh/config devient vite un allié. Il permet de définir des alias d’hôtes, les ports, les clés associées, voire la compression par défaut. Un exemple courant pour un serveur de production web :
Host web-prod
HostName 203.0.113.10
User ubuntu
Port 22
IdentityFile ~/.ssh/id_ed25519
Compression yes
Après cela, la commande habituelle se simplifie :
scp build.zip web-prod:/var/www/html/
Ce type de configuration réduit les erreurs, homogénéise les pratiques de l’équipe et facilite l’automatisation. On retrouve souvent des alias distincts pour les environnements de tests, de pré-production et de production, avec des clés dédiées à chaque périmètre.
Dans les architectures plus distribuées, où des nœuds périphériques comme des Raspberry Pi remontent des données via Wi‑Fi, un soin identique doit être porté au réseau. Un Pi connecté comme décrit dans un tutoriel type configuration Wi‑Fi sur Raspberry Pi 3 peut tout à fait recevoir des transferts SCP, à condition d’avoir un SSH verrouillé et une clé déployée proprement. Ces « petits » équipements finissent souvent dans des placards techniques ou des ateliers : mieux vaut ne pas les laisser avec un couple login/mot de passe par défaut accessible en clair.
Au-delà de l’authentification, un poste administrateur correctement configuré implique aussi une gestion propre des comptes sur les serveurs. L’usage systématique de comptes de service dédiés, créés avec les bonnes options useradd, limite la casse en cas de clé compromise. Les bonnes pratiques autour de la commande useradd, détaillées par exemple dans des ressources spécifiques, s’articulent très bien avec une stratégie de clés SSH serrée.
Un environnement SCP fluide ne se résume donc pas à une série de lignes de commande. Il repose sur une hygiène globale : clés entretenues, alias cohérents, droits revus périodiquement. Une fois cette base solide, la couche de sécurité spécifique à SCP peut être abordée sans surcharger les équipes.
Avec ce socle en place, il devient réaliste d’automatiser des transferts quotidiens sans mot de passe, ce qui ouvre la voie aux sauvegardes et déploiements programmés.
Sécurité, performance et diagnostics : garder la commande SCP sous contrôle
La force de SCP vient de sa simplicité, mais cette simplicité peut encourager de mauvaises habitudes. Quelques raccourcis populaires méritent d’être évités, en particulier les options qui désactivent des contrôles de sécurité. Un exemple typique : ajouter -o StrictHostKeyChecking=no pour « aller plus vite » sur un script de déploiement. Sur un pipeline CI éphémère et contrôlé, cela peut se défendre, mais sur un poste d’admin, c’est juste une invitation aux attaques de type man-in-the-middle.
Un minimum de garde-fous s’impose. D’abord, toujours vérifier l’empreinte de clé d’hôte lors de la première connexion, et s’assurer que les changements ultérieurs sont légitimes. Ensuite, privilégier systématiquement l’authentification par clé plutôt que par mot de passe. En pratique, dès qu’un script batch ou un cron utilise SCP, la présence d’une clé sans phrase de passe ou gérée par un agent SSH devient obligatoire.
Sur les serveurs, les comptes utilisés pour les transferts devraient avoir des droits minimaux. Copier une archive d’application ne nécessite pas les droits root. Une approche saine consiste à attribuer un répertoire précis à un compte dédié, avec des permissions ajustées, et laisser des scripts de post-déploiement effectuer les actions nécessitant des privilèges plus élevés.
Côté performance, quelques leviers existent sans transformer un transfert en usine à gaz. La compression avec -C apporte un gain visible pour les archives de logs, les fichiers texte ou les backups compressés. Sur un réseau local gigabit, la limitation ne vient souvent pas du lien, mais du CPU dédié au chiffrement et à la compression. Sur certains serveurs, choisir un chiffre plus rapide via l’option -c (par exemple un AES matériellement accéléré) peut libérer quelques précieuses secondes sur de gros transferts.
La limitation de bande passante avec -l constitue un autre outil utile. Pendant les heures d’ouverture, envoyer une image disque de plusieurs gigaoctets sans bride peut dégrader la qualité de service pour d’autres flux. Une commande du type :
scp -C -l 8000 big.img backup@serveur:/data/
limite le débit à environ 1 Mo/s, ce qui reste suffisant pour des copies non urgentes, tout en laissant respirer le réseau. Hors horaires critiques, la même commande peut être rejouée sans limite.
Les diagnostics ne sont pas à négliger. Un simple scp -v (ou plusieurs v) fournit des informations détaillées sur l’authentification, la négociation d’algorithmes et les chemins utilisés. Quand un transfert échoue avec un laconique « Permission denied », ce mode verbeux gagne un temps précieux en identifiant la clé utilisée, le compte, voire le répertoire problématique.
La plupart des incidents récurrents tournent autour des permissions ~/.ssh incorrectes, des chemins mal cités ou des pare-feux mal configurés. La consultation régulière de /var/log/auth.log (ou du journal systemd) permet de repérer les échecs répétés de connexion, les tentatives de brute force et les anomalies. Dans des environnements soumis à des contraintes réglementaires, cette traçabilité n’est pas négociable.
Enfin, un mot sur « SCP vs rsync vs SFTP ». SCP garde sa place pour les copies ponctuelles, la ligne rapide tapée à la main ou la petite automation. Pour des synchronisations fréquentes, la reprise sur coupure ou la validation par sommes de contrôle, rsync prend le relais. Pour les usages interactifs, un client SFTP ou un gestionnaire de fichiers graphique piloté en SFTP reste plus confortable. Chercher à faire de SCP l’outil unique de transfert est une mauvaise idée ; le bon réflexe consiste plutôt à choisir le bon outil pour chaque type de flux.
En résumé, un SCP maîtrisé, c’est un triangle équilibré entre sécurité, performance et observabilité. Quand l’un de ces côtés est sacrifié, le reste de l’architecture en paie le prix à moyen terme.
Automatiser les transferts SCP de serveur à serveur dans un environnement de production
Une fois les bases en place, la tentation naturelle consiste à automatiser les transferts. Les sauvegardes nocturnes, les exports de bases, les dépôts de builds vers un serveur web sont autant de candidats parfaits à un cron ou à un job de CI. La commande SCP se prête bien à cet exercice, à condition d’intégrer quelques garde-fous.
Un script classique de sauvegarde pourrait ressembler à ceci : création d’une archive, transfert via SCP, écriture dans un log et retour de statut. Le cœur du transfert pourrait inclure des options comme -C pour compresser, -l pour limiter, et -o BatchMode=yes pour s’assurer qu’aucune invite interactive ne bloque le job. L’ajout systématique de -o StrictHostKeyChecking=yes garantit, lui, que l’hôte rejoint est bien celui attendu.
Dans certaines architectures IoT, on voit émerger un autre modèle : des nœuds périphériques (capteurs, gateways, micro-serveurs) qui poussent périodiquement des paquets de données vers un concentrateur central. Les ressources de ces nœuds étant limitées, il devient vite pertinent de surveiller la consommation énergétique associée à ces transferts. Les chiffres de consommation d’un Raspberry Pi 5, par exemple, montrent que des pointes de charge CPU répétées impactent directement le budget énergétique global, ce qui pousse à regrouper les transferts dans des fenêtres temporelles et à utiliser la compression de manière mesurée.
Dans un scénario plus classique de web hosting, des pipelines de CI/CD intègrent SCP comme dernier maillon, une fois les tests passés. Un build frontend, par exemple, peut être empaqueté dans une archive tar.gz puis poussé sur un serveur Nginx via une simple commande. L’avantage est double : le pipeline reste lisible, et en cas de besoin, la même commande peut être rejouée depuis un poste d’admin pour dépannage.
Reste un dernier point souvent sous-estimé : la gestion des erreurs. Un cron qui exécute un scp sans vérifier le code retour ni les logs finit par donner une impression de sécurité trompeuse. Une discipline minimale consiste à vérifier le code retour, à calculer une somme de contrôle (sha256, par exemple) avant et après transfert sur les fichiers sensibles, et à déclencher une alerte en cas de divergence.
Au fil des années, une règle simple se vérifie régulièrement chez les opérateurs : plus la ligne SCP est courte mais dense (options explicites, chemins clairs, alias d’hôte bien choisis), plus elle est robuste. À l’inverse, empiler des hacks ponctuels fait grossir la dette technique. Le sujet n’est pas l’outil lui-même, mais la façon dont il est intégré dans une chaîne d’exploitation.
Comment copier efficacement un répertoire complet de serveur à serveur avec SCP sous Linux ?
Pour copier un répertoire complet de serveur à serveur, il est recommandé d’utiliser l’option -r pour la récursivité et -p pour préserver les permissions et dates. Depuis votre poste d’administration, une commande type ressemble à : scp -3 -rp admin@serveur-source:/var/www/app/ deploy@serveur-cible:/var/www/app/. L’option -3 fait transiter les données par votre machine sans les écrire sur disque, ce qui reste pratique pour des volumes raisonnables. Vérifiez auparavant que l’authentification par clé SSH est en place sur les deux serveurs et que les permissions des répertoires cibles sont correctes.
Quelle est la différence pratique entre SCP, SFTP et rsync pour le transfert de fichiers ?
SCP offre une copie rapide et chiffrée via SSH, avec une syntaxe très compacte, adaptée aux transferts ponctuels et aux scripts simples. SFTP, lui aussi basé sur SSH, fournit un mode interactif (liste de fichiers, navigation, reprise possible selon les clients) et est souvent préféré pour les usages manuels ou via gestionnaire de fichiers. rsync, enfin, gère la synchronisation incrémentale, les sommes de contrôle et la reprise fine sur coupure, ce qui en fait le meilleur choix pour les sauvegardes récurrentes ou les répertoires volumineux. En pratique, beaucoup d’équipes utilisent SCP pour les déploiements ponctuels, rsync pour les mirroirs réguliers et SFTP pour les interventions manuelles.
Comment renforcer la sécurité des transferts SCP sans compliquer la vie des équipes ?
Le socle consiste à désactiver l’authentification par mot de passe au profit des clés SSH, limiter les comptes utilisés (pas de root en direct) et vérifier systématiquement la clé d’hôte lors de la première connexion. Ensuite, configurez ~/.ssh/config pour utiliser des clés dédiées par environnement, activez la journalisation des connexions dans /var/log/auth.log et évitez les options dangereuses comme -o StrictHostKeyChecking=no en production. Enfin, mettez en place des scripts qui vérifient le code retour des commandes scp et comparent les sommes de contrôle sur les fichiers critiques. Ces quelques mesures apportent une sécurité tangible sans transformer SCP en usine à gaz.
SCP est-il toujours pertinent avec les évolutions récentes de SSH et du cloud ?
Oui, SCP garde tout son intérêt. Les versions récentes d’OpenSSH utilisent SFTP comme couche de transport sous-jacente, ce qui corrige plusieurs défauts historiques sans changer la syntaxe. Dans les environnements cloud (AWS, GCP, Azure), SCP reste un outil simple pour pousser des builds, des configurations ou rapatrier des journaux, souvent en complément de services de stockage objet. Là où des besoins de synchronisation avancée apparaissent, rsync, rclone ou des solutions natives viennent compléter l’arsenal. Le point clé n’est pas de remplacer SCP, mais de l’utiliser pour ce qu’il sait faire : des copies chiffrées rapides entre hôtes, intégrées à un SSH correctement entretenu.