La copie sécurisée (SCP) d'OpenSSH permet de transférer des données entre un client et un serveur, ainsi qu'entre deux serveurs depuis une machine locale. Une fonctionnalité peu connue, très utile, mais qui n'était pas toujours simple à utiliser. Avec OpenSSH 8.7 elle s'améliore, on vous explique comment.
Le protocole Secure Shell (SSH) permet de se connecter à distance à un serveur et de transférer des fichiers depuis ou vers un client. L'utilisateur peut s'authentifier à travers un identifiant et un mot de passe ou une paire de clés cryptographiques. Pour cela, il faut que le serveur dispose d'une liste de clés publiques autorisées et le client d'au moins une clé privée correspondante. Celle-ci peut être protégée de différentes façons.
Clés de sécurité et OpenSSH : de mieux en mieux
Jusqu'à récemment, une phrase de passe pouvait être ajoutée, évitant à une personne mal intentionnée ayant accès à la clé privée de pouvoir l'utiliser. Cet élément doit cependant être mémorisé et n'est pas toujours aisé à mettre en sécurité. Depuis OpenSSH 8.2 on peut donc utiliser une clé répondant au standard U2F ou FIDO.
Avec la version 8.7 sortie fin août, une autre nouveauté fait son apparition : la copie sécurisée (SCP) d'OpenSSH évolue et permet de transférer des données d'un serveur à un autre en s'authentifiant de manière interactive, c'est-à-dire avec une méthode nécessitant une intervention de l'utilisateur.
Cet ajout est permis par une modification du protocole sous-jacent qui passe désormais par SecureFTP (SFTP). Comment cela fonctionne-t-il et comment l'utiliser ? On a testé pour vous.
OpenSSH 8.7 : merci la rolling release
Pour tester cette fonctionnalité, il faut avoir accès à la version 8.7 d'OpenSSH. Encore récente, elle n'arrivera dans la plupart des distributions d'ici quelques mois au meilleur des cas. On peut choisir de compiler cette version soi-même avec le support des clés de sécurité. Nous avons toutefois opté pour une solution plus simple.
En effet, il existe des distributions en rolling release, qui reçoivent constamment des mises à jour récentes. C'est le cas d'Arch Linux et de son dérivé Manjaro. Nous avons donc opté pour ce dernier. Nous l'avons installé sur un vieux PC portable qui fera office de client et deux machines virtuelles (VM) hébergées via Proxmox VE 7.0 sur notre serveur HPE ProLiant DL365 Gen10 Plus v2. Le client servira à transférer un fichier de la VM1 à la VM2.
Une fois Manjaro installé, il faut mettre le système à jour et installer le support des clés de sécurité :
pamac update
pamac install libfido2
Sur les deux machines virtuelles, active le serveur OpenSSH :
systemctl enable sshd.service
systemctl start sshd.service
Vous devriez pouvoir vous connecter depuis le client sur vos serveurs (manjvm1 et manjvm2 dans notre cas) :
ssh utilisateur@manjvm1
ssh utilisateur@manjvm2
Bien entendu, pensez à remplacer « utilisateur » par le nom de l'utilisateur sur vos machines. Si vous utilisez le même pour le client et les serveurs, il n'est pas nécessaire de le préciser.
Pour vérifier la version installée d'OpenSSH et le statut du service, tapez les commandes suivantes :
ssh -V
systemctl status sshd.service
Création d'une paire de clés nécessitant une clé de sécurité
Il faut désormais créer une paire de clés cryptographiques qui exigera l'insertion de la clé de sécurité lorsque vous tenterez de vous connecter. Branchez un modèle U2F ou FIDO (une Solo Tap dans notre cas) et tapez sur le client :
ssh-keygen -t ecdsa-sk
Pendant la procédure, ajoutez une phrase de passe à la clé (sinon elle pourrait être rejetée). Un emplacement et un nom de fichier par défaut sont proposés pour la paire de clés, vous pouvez les modifier. Dans notre cas il s'agit de :
~/.ssh/id_ecdsa_sk // Clé privée, à garder en sécurité
~/.ssh/id_ecdsa_sk.pub // Clé publique, qui peut être librement partagée
Il faut maintenant transmettre la clé publique aux deux serveurs :
ssh-copy-id -i ~/.ssh/id_ecdsa_sk.pub utilisateur@manjvm1
ssh-copy-id -i ~/.ssh/id_ecdsa_sk.pub utilisateur@manjvm2
Vous devriez pouvoir vous connecter depuis le client aux serveurs avec votre clé :
ssh utilisateur@manjvm1 -i ~/.ssh/id_ecdsa_sk
Notez que si vous n'avez qu'une paire de clés cryptographiques sur votre machine, vous n'êtes pas obligé de préciser son emplacement (-i ...). Ce n'est nécessaire que si vous en avez plusieurs.
Transférer un fichier d'un serveur à un autre
Commençons par télécharger un fichier sur le premier serveur :
ssh utilisateur@manjvm1 -i ~/.ssh/id_ecdsa_sk -C "wget https://cdn2.nextinpact.com/medias/wallpaper-nxi-v6-1080p.jpg -O image.jpg"
On peut alors le transférer au second serveur :
scp -s -i ~/.ssh/id_ecdsa_sk utilisateur@manjvm1:image.jpg utilisateur@manjvm2:
Le « -s » permet d'utiliser la copie par SFTP qui autorise l'authentification interactive et donc via les clés de sécurité, pour le moment au stade expérimental. Dans les prochaines versions, il ne sera plus nécessaire.
Si tout se passe bien, l'authentification par la clé de sécurité devrait être faite pour le premier serveur, puis le second et le fichier sera alors transféré de l'un à l'autre, un message vous indiquant que tout s'est bien passé. Nous avons testé cette procédure avec diverses clés U2F et FIDO sans rencontrer de soucis particuliers.
On pourrait bien entendu se connecter au premier serveur via SSH et l'utiliser pour transférer le fichier vers le second via SCP, mais cette manière de faire permet d'utiliser le client local comme intermédiaire et que les serveurs n'aient pas forcément connaissance l'un de l'autre, ce qui peut être nécessaire dans certaines situations.
Et si les serveurs ne sont pas à jour ?
Disposer d'un client sous OpenSSH 8.7 est nécessaire pour utiliser cette fonctionnalité comme nous venons de le voir. Mais si ce n'est pas le cas des serveurs ? Nous avons également fait le test avec deux machines virtuelles sous Debian 11, qui dispose actuellement de la version 8.4, cela a fonctionné sans problème :
Que ce soit avec des serveurs sous Debian 11 ou Manjaro, la copie de serveur à serveur fonctionne
Commentaires (22)
#1
cool, maintenant manque plus que des wearable qui peuvent remplacé les clefs de sécurité ;), car si on l’a toujours sur soit c’est mieux niveau … sécurité. xD
#1.1
Techniquement FIDO n’est pas limité à un type d’interface en particulier. Tout dépend de l’implémentation d’OpenSSH là-dessus, elle pourra évoluer dans le temps, même si gérer le wearable = passer par le BT ou le NFC avec tout le foutoir que ça entraîne.
Mais si l’écosystème Linux pouvait déjà gérer de manière globale et correctement les clés de sécurité via les standard U2F/FIDO même seulement en USB, ce serait un bon début.
#1.2
par curiosité, comme openssh recommande d’utiliser rsync plutôt que scp (ici), est-il possible d’utiliser ces clés FIDO avec rsync ?
sachant en plus, que ici scp utilise en fait le protocole sftp, ce que rsync ne peut semble-t-il pas faire directement…
#1.3
C’est notamment pour ça que SFTP est utilisé en remplacement du protocole SCP dans la commande de connexion sécurisée, ce qui permet au passage le transfert remote-remote via l’authentification par clé de sécurité
#2
oui j’ai bien compris, je dit juste que gardé une clef de sécurité sur soit 24⁄7 c’est parfois complexe (oublis etc) donc avoir des constructeur qui crée des appareil consu pour (collier, bague, bracelet etc) qui le font serait plus que bienvenu ^^ (meme si derrière ca reste un truc usb-a usb-c.
#2.1
Tu peux parfaitement avoir une clef usb en pendentif.
#3
Est-ce que ça marche bien sous Windows (Git for Windows) et même Putty ?
Sachant que
ssh -Vme ramèneOpenSSH_8.7p1, OpenSSL 1.1.1k 25 Mar 2021(et que je n’ai pas de clef FIDO/U2F pour vérifier).Ou via un vaccin, non ne me remerciez pas
Blague à part, ça me rappelle ces histoires de salariés de Suède qui avaient acceptés de se faire greffer (si c’est le terme) une puce RFID à la place du “classique” badge.
#3.1
Je ne suis pas sûr de comprendre, W10/W11 sont toujours à OpenSSH 8.1 de mémoire.
#4
J’ai pas bien compris à quoi sert la clé physique. Concrètement c’est quoi les mécanismes avec la clé ?
#4.1
La clé de sécurité est nécessaire pour que la connexion se fasse.
#4.2
Il n’y a aucune configuration à faire à part activer la fonctionnalité ? Au moment de la création des clés rsa, l’empreinte de la clé physique ou quelque chose du genre est pris en compte ?
#5
Git for Windows 2.33.0.windows.2 m’indique la version 8.7p1 (résultat de la commande
ssh -V). Probablement une version mingw.Ce qui ne doit pas être la même version que celle via winget (que je n’utilise pas) qui semble pour le moment limitée à la version 8.6 : https://github.com/powershell/Win32-OpenSSH
#5.1
OpenSSH est intégré nativement à Windows 10⁄11, il n’y a rien à installer. C’est une version spécifique, compilée par MS et open source (mais en retard par rapport à la version classique).
La commande de génération de la clé indique que c’est pour utiliser avec une clé de sécurité (d’où le -sk dans le nom de l’algo)
#6
W10, W11 ssh -V : 8.1p1
#7
J’ai testé pour info, tant dans la version native à Windows que celle de Git/Bash, ça ne fonctionne pas. Sans doute que la compilation a été faite sans le support des clés de sécurité. Mais apparemment il faut passer par des intégrations tierces pour le moment.
#8
Merci pour les informations :)
#9
@David_L Cette phrase a retenu mon attention :
Comme ta commande
scpn’utilise pas-3les données transitent par défaut du serveur 1 vers le serveur 2, sans passer par ta machine locale.Du coup, sauf erreur de ma part, pour que cette phrase soit correcte, il faudrait préciser que si on veut que le trafic passe par la machine locale, il faut utiliser
-3, utile lorsque serveur 1 ne peut pas dialoguer avec serveur 2.#9.1
Non, -3 était le flag nécessaire antérieurement à la 8.7, il ne l’est plus dans le cas présent.
#10
J’ai particulièrement du mal à comprendre pourquoi se poser la question.
Si j’ai bien compris, la secure key ne sert qu’à remplacer le mot de passe de la clé privée qui est déchiffrée sur le client, ce qui n’impacte donc que le client.
Question subsidiaire: est-ce que l’on peut avoir une paire de clefs différente pour chaque serveur chacune protégée par une secure key différente (ouais je sais c’est tordu comme question) ?
#10.1
Parce que même si c’est logique, je pars du principe (par expérience) qu’il y a aussi des questions illogiques mais pertinentes du point de vue de l’utilisateur. Surtout qu’li pourrait y avoir une dépendance non explicitée côté serveur. Donc je vérifier et j’explique ;)
Sinon la SK n’est pas un remplacement, c’est un élément de sécurité parmi d’autres. Elle est complémentaire à la phrase de passe de la clé privée.
Oui, mais ça me paraît logique
#11
Merci en tous cas pour le complément.
#12
Je serais curieux de voir le débit des transferts, j’ai souvent mis en place des tunnels SSH pour transférer des gros backups entre machines, c’était très difficile de dépasser 100Mio/s avec le client/server 7.x (une histoire de fenêtre TCP statique et trop petite).
PS: une potentielle solution https://www.psc.edu/hpn-ssh-home/