Introduction
SSH fournit un accès chiffré en ligne de commande à un autre compte Linux, tandis que SCP utilise les mêmes mécanismes d’authentification et de transport pour copier des fichiers. Lors d’une première connexion sécurisée, il faut vérifier la clé d’hôte du serveur ; les connexions suivantes peuvent utiliser une clé personnelle au lieu de transmettre à chaque fois le mot de passe du compte.
Dans ce laboratoire, le compte isolé remoteuser sur localhost sert d’hôte distant. Bien que les deux comptes utilisent la même machine virtuelle de formation, le protocole SSH, les demandes d’authentification, le répertoire personnel distant et les transferts de fichiers reproduisent un scénario élémentaire entre deux hôtes. Le mode d’accès SSH par défaut de labex n’est pas modifié.
Examiner la cible SSH
Dans cette étape, vous allez identifier le client SSH, résoudre le nom de la cible, vérifier qu’un serveur est à l’écoute et afficher un aperçu de sa clé d’hôte publique.
Accédez à l’espace de travail local :
cd /home/labex/project/ssh-lab
Affichez la version du client OpenSSH. Ce programme écrit sa version sur la sortie d’erreur standard ; 2>&1 la combine donc avec la sortie standard :
ssh -V 2>&1
Résolvez la cible locale à l’aide de la configuration système de résolution des noms :
getent hosts localhost
Vérifiez qu’un serveur SSH écoute sur le port TCP 22 :
sudo ss -ltnp | grep ':22'
ssh-keyscan récupère les clés d’hôte publiques sans ouvrir de session. Transmettez la clé ED25519 à ssh-keygen -lf - afin d’afficher son empreinte :
ssh-keyscan -t ed25519 localhost 2>/dev/null | ssh-keygen -lf -
Dans un environnement réel, comparez cette empreinte à une valeur de confiance fournie par l’administrateur avant de l’accepter. Enregistrez un résumé concis de la cible :
printf 'target=localhost\nport=22\nuser=remoteuser\n' > ssh-target.txt
cat ssh-target.txt
Ouvrir votre premier shell distant
Dans cette étape, vous allez vérifier une clé d’hôte, vous authentifier avec un mot de passe, examiner le compte distant, puis fermer le shell distant.
Connectez-vous en utilisant la forme user@host :
ssh remoteuser@localhost
Comme la configuration a supprimé toute entrée précédente de clé d’hôte pour localhost, SSH vous demande si vous faites confiance à l’empreinte affichée. Après l’avoir comparée à celle de l’étape 1, saisissez :
yes
À l’invite du mot de passe, saisissez :
RemoteLab123!
Le mot de passe ne s’affiche pas pendant la saisie. Après la connexion, l’invite appartient à remoteuser, et non à labex. Vérifiez l’identité distante, le nom de l’hôte et le répertoire courant :
whoami
hostname
pwd
Créez un fichier témoin distant dans le répertoire personnel du compte distant :
mkdir -p ~/ssh-lab
printf 'connected as %s\n' "$(whoami)" > ~/ssh-lab/connected.txt
Fermez le shell distant et revenez à l’invite locale de labex :
exit
La commande exit ferme uniquement le shell distant ; le terminal local reste ouvert.
Exécuter une commande distante
Dans cette étape, vous allez exécuter des commandes à distance sans ouvrir un shell interactif persistant et enregistrer leur sortie localement.
Revenez à l’espace de travail local si nécessaire :
cd /home/labex/project/ssh-lab
Placez une commande entre guillemets après l’hôte. SSH l’exécute à distance et renvoie sa sortie vers votre terminal local :
ssh remoteuser@localhost 'whoami; uname -srm; uptime'
Saisissez RemoteLab123! lorsque le mot de passe vous est demandé. Les points-virgules séparent les commandes interprétées par le shell distant.
Exécutez une seconde commande distante et redirigez la sortie renvoyée vers un fichier local :
ssh remoteuser@localhost 'printf "remote_user=%s\nremote_home=%s\n" "$(whoami)" "$HOME"' > remote-context.txt
Saisissez à nouveau le mot de passe. La redirection > est gérée par votre shell local ; remote-context.txt est donc créé dans l’espace de travail local :
cat remote-context.txt
Le fichier doit indiquer remoteuser et /home/remoteuser.
Transférer un fichier avec SCP
Dans cette étape, vous allez envoyer un fichier local, vérifier son contenu à distance, puis le télécharger sous un nouveau nom local.
Créez un exemple de configuration local :
cd /home/labex/project/ssh-lab
printf 'mode=training\nport=8080\n' > app.conf
SCP utilise la forme user@host:path pour désigner un chemin distant. Envoyez le fichier dans le répertoire distant incoming préparé à cet effet :
scp app.conf remoteuser@localhost:/home/remoteuser/incoming/app.conf
Saisissez RemoteLab123! lorsque le mot de passe vous est demandé. Vérifiez le contenu distant via SSH :
ssh remoteuser@localhost 'cat /home/remoteuser/incoming/app.conf'
Saisissez à nouveau le mot de passe. Inversez maintenant la source et la destination pour télécharger le fichier :
scp remoteuser@localhost:/home/remoteuser/incoming/app.conf downloaded-app.conf
Saisissez le mot de passe, puis comparez l’original local à la copie téléchargée :
cmp app.conf downloaded-app.conf && echo "The files match"
Transférer récursivement un répertoire
Dans cette étape, vous allez utiliser le mode récursif de SCP pour copier une arborescence de répertoires vers le compte distant.
Créez une petite arborescence de projet locale :
cd /home/labex/project/ssh-lab
mkdir -p site/assets
printf '<h1>SSH transfer practice</h1>\n' > site/index.html
printf 'body { color: navy; }\n' > site/assets/style.css
L’option -r copie récursivement les répertoires et leur contenu :
scp -r site remoteuser@localhost:/home/remoteuser/incoming/
Saisissez RemoteLab123! lorsque le mot de passe vous est demandé. Affichez l’arborescence distante avec une commande SSH exécutée en une seule fois :
ssh remoteuser@localhost 'find /home/remoteuser/incoming/site -type f -printf "%P\n" | sort'
Saisissez à nouveau le mot de passe. Vous devriez voir assets/style.css et index.html.
Générer une clé SSH personnelle
Dans cette étape, vous allez créer une paire de clés ED25519 dédiée et vérifier ses permissions ainsi que son empreinte.
Une paire de clés comprend une clé privée qui reste en votre possession et une clé publique qui peut être installée sur un compte distant. Générez une clé dédiée pour l’exercice, sans phrase secrète, afin que la validation automatisée puisse l’utiliser :
mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keygen -t ed25519 -f ~/.ssh/labex_remote_ed25519 -N '' -C 'labex-remote-practice'
L’option -t sélectionne l’algorithme, -f définit le fichier, -N '' configure une phrase secrète vide pour l’exercice et -C ajoute un libellé. En production, les clés devraient normalement être protégées par une phrase secrète robuste lorsque les contraintes d’automatisation ne l’interdisent pas.
Vérifiez les deux fichiers et leurs permissions :
ls -l ~/.ssh/labex_remote_ed25519 ~/.ssh/labex_remote_ed25519.pub
La clé privée ne devrait être lisible que par labex. Le fichier .pub est destiné à être partagé. Affichez l’empreinte de la clé publique :
ssh-keygen -lf ~/.ssh/labex_remote_ed25519.pub
Ne copiez et ne divulguez jamais la clé privée.
Installer et utiliser la clé publique
Dans cette étape, vous allez installer la clé publique pour remoteuser, vous connecter sans invite de mot de passe et vérifier un transfert de fichiers reposant sur une clé.
ssh-copy-id ajoute une clé publique au fichier ~/.ssh/authorized_keys du compte distant, avec les permissions appropriées :
ssh-copy-id -i ~/.ssh/labex_remote_ed25519.pub remoteuser@localhost
Saisissez RemoteLab123! pour cette dernière opération authentifiée par mot de passe. Testez la clé privée dédiée avec -i :
ssh -i ~/.ssh/labex_remote_ed25519 remoteuser@localhost 'printf "key authentication works\n" > ~/ssh-lab/key-authenticated.txt; cat ~/ssh-lab/key-authenticated.txt'
Cette commande ne devrait pas demander le mot de passe du compte distant. Utilisez la même identité pour SCP :
scp -i ~/.ssh/labex_remote_ed25519 remoteuser@localhost:~/ssh-lab/key-authenticated.txt key-authenticated.txt
cat key-authenticated.txt
Le fichier téléchargé doit contenir key authentication works. La clé d’hôte authentifie le serveur ; votre clé privée vous authentifie auprès du compte distant. Ces deux clés répondent à des problèmes de confiance différents.
Résumé
Vous avez vérifié une clé d’hôte SSH, ouvert puis fermé un shell distant, exécuté des commandes distantes en une seule fois et distingué la redirection locale de l’exécution distante. Vous avez envoyé et téléchargé des fichiers avec SCP, puis copié récursivement un répertoire.
Vous avez également généré une paire de clés ED25519 dédiée, protégé la clé privée, installé uniquement la clé publique et réutilisé cette identité pour SSH et SCP sans mot de passe. Il s’agit des compétences fondamentales nécessaires à une administration distante sûre, même pour débuter.
