SCP : cette commande que tout le monde croit bien connaître pour copier des fichiers depuis une machine linux vers un routeur ou inversement.
Ses cas d’utilisations sont multiples :
- Transfert d’IOS
- Copie de parties de configurations ou de configurations complètes
- Transfert de traces et logs (rapatrier un show tech-support par exemple)
Je m’intéresse ici aux transferts d’IOS depuis ma station d’administration vers mon device. Et par IOS, j’entends un firmware réseau qu’il soit étiquetés Cisco, Juniper, Arista ou autres.
Et justement, ces fichiers IOS ont pris pas mal de volume et on est passé allégrement du megaoctet au gigaoctet. Aussi un transfert prend vite une éternité, surtout via des liens out of band ADSL (compter 2h15 par GigaOctet sur du 8Mb/s).
Evidemment garder les yeux rivés sur le terminal pendant tout ce temps, c’est hors de question. Et si on ferme son terminal, pour aller bêtement manger ou rentrer chez soi, le transfert est arrêté par le système.
D’où la question cruciale de mon collègue Nabil : Comment laisser ce transfert interminable vivre sa vie tout en nous laissant vivre la nôtre ?
Lancer la session en arrière-plan avec la commande unix & ne résoud pas grand-chose, car scp réclame notre intervention pour la saisie le mot de passe du device distant. Et les solutions à la unix basées sur des paires de clefs ne sont pas compatibles avec les authentifications Tacacs qui sont souvent déployées.
On va donc démarrer notre session normalement. Et voilà notre terminal bloqué pour quelques heures en nous laissant en mode statue regarder les statistiques du transfert. Pas top, même si ça nous donne un aperçu du débit moyen et une estimation de la durée.
Bon 115 heures, ça va être trèèèès long, alors un petit Ctrl-C pour reprendre la main sur la session, mais de suite c’est le coup de grâce pour le transfert.
Ma petite astuce c’est Ctrl-Z qui met en pause le processus sans le tuer et rend la main sur la session ! A conjuguer avec les commandes fg et bg (foregroung & background pour les intimes). fg le ramène sur le devant de la scène et bg le renvoie dans les coulisses du système.
Donc, une fois qu’on a fini l’authentification, un p’tit Ctrl-Z suivi, pas trop tard, d’un bg (pour éviter une fin prématurée du TCP) et voilà notre SCP en train de continuer son boulot en arrière-plan.
Tant que la session est ouverte, on peut surveiller le process avec la commande jobs et de retourner au spectacle en mode interfactif avec la commande fg.
Si on veut quand même tout arrêter, par exemple au retour de la pause-café quand on s’est aperçu qu’on transfère un OS Palo Alto sur un routeur Cisco, on a la commande kill %.
Un dernier truc sur la commande SCP : c’est l’option -l qui limite la bande passante du transfert : c’est toujours sympa de laisser un peu de bande passante aux copains qui tentent d’administrer ou de superviser le device pendant le transfert, n’est-ce-pas Nicolas ?
L’autre méthode c’est de ne pas lire tout ce qu’il y a au-dessus et utiliser curl et ses super pouvoirs:
| -u | Pour passer le couple user :password en argument |
| -k | Pour ne pas vérifier |
| –limit-rate | Evite de monopoliser toute la toute passante pendant la durée du transfert |
| -T | Pour se placer en mode upload |
| -s | Pour se passer des statistiques de transfert |
| & | Pour lancer la commande en tâche de fond |
A utiliser sans modération :
Et un Nota Bene spécial aux experts sécurité auto-proclamés qui sont déjà en train de me dénoncer à l’ANSSI parce-que j’ai laissé traîner mon mot de passe dans l’historique des commandes, je leur grossis l’espace entre le prompt et la commande qui évite toute historisation et bien évidemment j’ai utilisé l’option -u pour donner le couple user:password plutôt que le mettre dans l’url (scp://root@pwd:100.100.0.100/). Il est donc supprimé de la liste des arguments et invisible à la commande ps !
