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
