Cours Linux / Se connecter avec SSH et transférer des fichiers avec scp et sftp

SSH, pour Secure Shell, permet de se connecter à un serveur et d’exécuter des commandes dans un canal chiffré ; OpenSSH fournit aussi scp et sftp pour transférer des fichiers. Vérifiez l’identité du serveur à la première connexion, puis prouvez que la clé voulue sert réellement à l’authentification. Conservez l’accès existant tant qu’une nouvelle connexion n’a pas été validée et utilisez des répertoires de pratique pour éviter d’écraser des fichiers.

Les exemples visent un client Linux avec Bash et OpenSSH, et un serveur de pratique Ubuntu 26.04 LTS ou Rocky Linux 9 que vous êtes autorisé à administrer. user et server.example sont des paramètres à remplacer par le compte et l’adresse réels ; ce domaine n’est pas un serveur d’essai à contacter. Préparez la console dans votre environnement de pratique en machine virtuelle. Le client et le serveur peuvent être deux machines virtuelles distinctes.

Préparer le client, le serveur et le chemin réseau

Le client est la machine où vous lancez ssh, scp ou sftp ; le serveur est celle qui reçoit la connexion. Le serveur doit posséder un compte utilisable, les composants OpenSSH nécessaires et une écoute accessible sur le port prévu. La configuration du pare-feu, d’un hébergeur et d’une traduction d’adresses éventuelle intervient séparément.

Sur le client, identifiez les programmes :

command -v ssh
command -v scp
command -v sftp
ssh -V

Sur un serveur Ubuntu où le paquet manque, examinez les transactions et installez uniquement la branche Ubuntu :

sudo apt update
sudo apt install openssh-server
systemctl status ssh.service ssh.socket --no-pager

L’installation peut activer l’écoute. Ubuntu peut utiliser ssh.socket pour déclencher ssh.service : le service n’a pas besoin d’être constamment actif avant une connexion pour que le socket soit disponible. Inspectez les deux unités et la configuration prévue au lieu de forcer simultanément deux modes de lancement. La documentation Ubuntu d’OpenSSH décrit le paquet ; l’annonce de l’équipe Ubuntu sur l’activation par socket explique ce mécanisme.

Si une installation de pratique est bien prévue pour l’activation par socket et que son socket est désactivé, sudo systemctl enable --now ssh.socket demande son activation et son démarrage. Sur un serveur délibérément configuré avec le service permanent, gérez plutôt ce service selon sa configuration. N’appliquez pas l’une de ces variantes simplement pour faire disparaître un état inactive.

Sur un serveur Rocky Linux 9 où le paquet manque, la branche habituelle est :

sudo dnf install openssh-server
sudo systemctl enable --now sshd.service
systemctl status sshd.service --no-pager

Vérifiez les noms réellement installés, l’adresse et le port d’écoute. enable --now modifie aussi l’activation future ; ce n’est pas une simple consultation. Le cours sur les états systemd aide à distinguer ces effets et le cours de diagnostic réseau permet d’isoler résolution, route et connexion. Gardez une session ou une console de récupération avant de toucher à un accès distant existant.

Vérifier l’empreinte de la clé d’hôte du serveur

La clé d’hôte sert à reconnaître le serveur ; elle est différente de la clé personnelle qui autorisera votre compte. Depuis sa console ou un autre chemin déjà fiable, l’administrateur relève l’empreinte de la clé publique d’hôte effectivement utilisée. Pour un serveur possédant une clé Ed25519 :

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub

Si ce fichier n’existe pas ou si la politique cryptographique n’autorise pas cet algorithme, faites identifier la clé d’hôte réellement proposée. Une politique FIPS, c’est-à-dire liée aux Federal Information Processing Standards, peut imposer d’autres choix ; ne créez pas arbitrairement une nouvelle clé d’hôte pour suivre l’exemple.

Depuis le client, lancez la première connexion :

ssh user@server.example

Comparez le type de clé et l’empreinte SHA256 affichés avec la valeur obtenue par le chemin fiable avant d’accepter. Une empreinte, ici calculée avec la fonction de hachage Secure Hash Algorithm 256 bits, est une représentation courte à comparer exactement. Le manuel OpenSSH de ssh décrit l’authentification de l’hôte et la connexion.

Un avertissement indiquant que la clé d’un serveur connu a changé exige une vérification : réinstallation, rotation prévue, mauvaise destination ou interception possible. Ne videz pas known_hosts et ne désactivez pas le contrôle d’identité. Après confirmation par l’administrateur, gérez seulement l’entrée correspondant à la machine et au port concernés selon la procédure prévue.

Une fois connecté, confirmez que vous êtes sur le bon serveur et le bon compte, puis utilisez exit pour revenir au client. Une invite distante ressemble parfois à l’invite locale : gardez le rôle de chaque terminal explicite pendant les étapes suivantes.

Créer une clé personnelle et enregistrer uniquement la partie publique

Sur le client, vérifiez que .ssh est bien un répertoire de votre compte. S’il est absent, la commande suivante le crée avec des droits privés ; elle ne modifie pas les permissions d’un élément existant :

if test ! -e "$HOME/.ssh"; then
  mkdir -m 700 -- "$HOME/.ssh"
fi

Si le chemin existant n’est pas un répertoire utilisable ou si sa création échoue, résolvez ce problème avant de poursuivre. Choisissez ensuite un nom de clé libre :

ssh-keygen -t ed25519 -f "$HOME/.ssh/linux-course-key"

Choisissez une phrase secrète et conservez la clé privée sur le client. Si le programme demande d’écraser un fichier existant, refusez et choisissez un autre nom dans toutes les commandes suivantes. Le fichier sans suffixe est privé ; celui portant .pub contient la clé publique. Le manuel de ssh-keygen définit ces fichiers et les empreintes.

Enregistrez seulement la clé publique du client dans le compte serveur autorisé, en utilisant le moyen d’accès initial prévu :

ssh-copy-id -i "$HOME/.ssh/linux-course-key.pub" user@server.example

Cette commande modifie les clés autorisées du compte distant. L’option -i choisit explicitement la clé à ajouter, comme le précise le manuel Ubuntu de ssh-copy-id. N’envoyez jamais le fichier privé. Si l’outil manque, un administrateur peut ajouter la ligne publique complète à authorized_keys selon la procédure du serveur, en préservant les lignes existantes.

Sur un compte Linux habituel, .ssh est généralement réservé au propriétaire avec le mode 700 et authorized_keys avec le mode 600. L’appartenance, les permissions des répertoires parents, le chemin configuré et les politiques de sécurité comptent aussi. Le cours sur les permissions Linux et sudo explique la lecture de ces modes ; ne transposez pas directement ces modes aux listes de contrôle d’accès d’un client Windows.

Confirmer l’authentification réellement utilisée

Dans un nouveau terminal client, essayez la clé choisie :

ssh -v -o IdentitiesOnly=yes -i "$HOME/.ssh/linux-course-key" user@server.example

Lisez les messages d’authentification : une clé proposée n’est pas encore une clé acceptée, et une connexion réussie a pu finalement utiliser un mot de passe. IdentitiesOnly restreint les identités proposées selon la configuration ; il ne supprime pas à lui seul les autres méthodes d’authentification. Les options sont définies dans la référence de configuration du client OpenSSH.

Une phrase secrète de clé privée protège son usage sur le client ; elle n’est pas le mot de passe du compte serveur. Après une connexion réussie, vérifiez le compte et la machine puis revenez avec exit. Ne désactivez pas l’ancien moyen d’accès avant d’avoir confirmé la méthode voulue et conservé une récupération par console. Les journaux détaillés peuvent révéler des comptes, chemins et adresses : examinez-les avant de les partager.

Préparer des espaces de transfert sans écraser un fichier existant

L’atelier suivant utilise un fichier de texte sans données personnelles. Toutes les commandes de shell de cette partie sont lancées sur le client. Créez un nouveau répertoire local puis placez-vous dedans :

transfert=$(mktemp -d "$HOME/linux-ssh-transfer.XXXXXX") &&
cd -- "$transfert" &&
printf 'SSH transfer test\n' > transfer-test.txt

Ne continuez que si ces trois étapes ont réussi. Le répertoire neuf évite d’écraser un fichier local de même nom ; && empêche l’écriture si la création ou le changement de répertoire a échoué. Gardez ce terminal pour conserver le répertoire courant et la variable transfert.

Préparez aussi un nouveau répertoire distant avec sftp. La commande suivante ouvre une session depuis ce répertoire local :

sftp -i "$HOME/.ssh/linux-course-key" user@server.example

À l’invite sftp, entrez ces commandes, sans les taper dans le shell Bash :

pwd
lpwd
ls
mkdir linux-course-transfert
bye

pwd et ls concernent le serveur ; lpwd montre le répertoire du client. Dans cet atelier, la session distante doit commencer dans le répertoire personnel du compte et la session locale dans le nouveau dossier de pratique. Si la configuration vous place ailleurs, adaptez le chemin explicitement avant le transfert.

Si mkdir échoue parce que linux-course-transfert existe ou pour toute autre raison, ne poursuivez pas dans ce dossier. Choisissez un nouveau nom autorisé, recommencez sa création puis remplacez ce nom dans toutes les commandes suivantes. Ne supprimez pas un dossier existant pour libérer le nom de l’exercice. Seule une création réussie établit ici l’espace distant neuf.

Envoyer et récupérer un fichier avec scp

Après la création réussie du répertoire distant, envoyez le fichier puis récupérez-le dans un autre fichier local :

scp -i "$HOME/.ssh/linux-course-key" transfer-test.txt user@server.example:linux-course-transfert/transfer-test.txt

Attendez la réussite de l’envoi et lisez les erreurs éventuelles avant de poursuivre. La destination distante est relative au répertoire personnel utilisé pour la copie. Récupérez ensuite :

scp -i "$HOME/.ssh/linux-course-key" user@server.example:linux-course-transfert/transfer-test.txt ./transfer-returned.txt

Après le téléchargement réussi, comparez les octets :

cmp transfer-test.txt transfer-returned.txt
printf 'Comparaison scp : %s\n' "$?"

cmp sans différence n’affiche normalement rien et renvoie 0. Un état 1 signifie un contenu différent, un autre problème demande de lire le message, par exemple un fichier absent. Un transfert n’est donc pas validé simplement parce qu’une commande a été lancée. La comparaison porte sur ce fichier texte ; elle ne démontre pas la préservation de toutes les métadonnées.

Depuis OpenSSH 9.0, scp utilise SFTP par défaut pour le transfert, selon le manuel de scp. Un serveur ancien ou restreint peut avoir une compatibilité différente. Ne forcez pas l’ancien protocole ou des options relâchant les contrôles sans comprendre le besoin précis.

Transférer interactivement avec sftp

Depuis le même terminal client et le même répertoire local, rouvrez sftp avec la commande précédente. Après connexion, entrez :

pwd
lpwd
cd linux-course-transfert
ls
put transfer-test.txt transfer-sftp.txt
get transfer-sftp.txt transfer-sftp-returned.txt
bye

cd change le répertoire distant. put lit le fichier du répertoire local et l’envoie sous le nouveau nom distant transfer-sftp.txt ; get le récupère sous transfer-sftp-returned.txt dans le répertoire local. Si cd, put ou get échoue, arrêtez la séquence et examinez l’erreur avant d’utiliser l’étape suivante. Ces noms sont neufs dans les espaces de pratique préparés.

cmp transfer-test.txt transfer-sftp-returned.txt
printf 'Comparaison sftp : %s\n' "$?"

Attendez de nouveau 0 pour des contenus identiques. Le manuel de sftp distingue les commandes locales comme lpwd ou lls des commandes distantes comme pwd ou ls. SFTP désigne ici le protocole de transfert de fichiers sur SSH, distinct de FTP protégé par TLS.

Utiliser le bon port et interpréter un refus

Si l’administrateur a réellement configuré un autre port, ajoutez l’option à toutes les connexions correspondantes. Le numéro 2222 est un exemple, pas une consigne de changement du serveur. La commande de copie de clé ssh-copy-id utilise aussi -p minuscule.

Un délai ou un refus de connexion conduit à vérifier le nom, la route, le port, l’écoute et les politiques réseau. Un refus d’authentification conduit plutôt à examiner le compte, la clé acceptée, les permissions et la politique du serveur. Une connexion shell possible ne garantit pas l’autorisation d’utiliser le sous-système SFTP, et un compte limité à SFTP peut ne pas permettre un shell.

Nettoyer seulement les éléments créés pour l’exercice

Dans une nouvelle session sftp, relisez les noms du dossier distant avant de retirer les deux fichiers créés ici. Si vous avez changé un nom, adaptez uniquement ce chemin vérifié :

cd linux-course-transfert
ls
rm transfer-test.txt
rm transfer-sftp.txt
cd ..
rmdir linux-course-transfert
bye

Ne retirez pas un fichier ajouté par quelqu’un d’autre. rmdir doit refuser un répertoire encore non vide. Sur le client, après avoir vérifié que vous êtes toujours dans le répertoire neuf de l’exercice, les trois copies connues peuvent être retirées puis le dossier vide :

test -n "$transfert" &&
cd -- "$transfert" &&
pwd &&
rm -- transfer-test.txt transfer-returned.txt transfer-sftp-returned.txt &&
cd -- .. &&
rmdir -- "$transfert"

La clé personnelle est indépendante des fichiers transférés. Si elle était exclusivement destinée à cet exercice et ne doit plus permettre l’accès, faites retirer uniquement sa ligne publique des autorisations du compte selon la procédure prévue, puis gérez sa copie privée locale. Préservez les autres clés et un accès de récupération ; effacer toute la liste authorized_keys n’est pas un nettoyage ciblé.