TP-01-Authentification SSH

Module : Administration Linux

Chapitre : 3 — Gestion du réseau

Section de rattachement : 3.3.24 — Présentation SSH

Cours associé : → Revenir au cours Standard — 3.7 SSH : administration distante sécurisée

Objectif

Mettre en pratique SSH sans dépendre de Vagrant, en utilisant :

un poste Windows comme **client SSH** ;
une VM Linux Liora/AWS comme **serveur SSH** ;
une première authentification par **mot de passe** ;
puis une authentification par **paire de clés SSH** ;
enfin la désactivation du mot de passe afin de vérifier que seule la clé permet l'accès.

Architecture du TP

POSTE WINDOWS                         VM LINUX
Client SSH                            Serveur SSH (sshd)
     │                                     │
     │──────────── TCP / 22 ──────────────>│
     │                                     │
     │                               utilisateur
     │                                user-ssh

Remplacer `IP_PUBLIQUE_VM` par l'adresse IP publique de la VM fournie pour le TP.

1. Vérifier le serveur SSH

Sur la VM Linux :

sudo systemctl status ssh

Le service SSH doit être actif. Le poste Windows joue le rôle de client ; la VM Linux joue le rôle de serveur grâce au service sshd.

2. Créer un utilisateur dédié au TP

Sur la VM :

sudo adduser user-ssh

Définir un mot de passe temporaire pour cet utilisateur, puis vérifier sa création :

id user-ssh

3. Tester la connexion par mot de passe

Depuis Windows :

ssh user-ssh@IP_PUBLIQUE_VM

Sur une VM cloud configurée pour n'accepter que les clés, la connexion peut échouer avec :

Permission denied (publickey)

Vérifier la configuration effective de SSH :

sudo sshd -T | grep -E 'passwordauthentication|pubkeyauthentication'

Dans notre environnement, le résultat était :

pubkeyauthentication yes
passwordauthentication no

La configuration cloud désactivant le mot de passe se trouvait dans :

/etc/ssh/sshd_config.d/60-cloudimg-settings.conf

avec :

PasswordAuthentication no

4. Autoriser temporairement le mot de passe pour `user-ssh`

Ajouter dans /etc/ssh/sshd_config :

Match User user-ssh
    PasswordAuthentication yes

Cette exception est volontairement limitée à l'utilisateur du TP.

Vérifier la syntaxe :

sudo sshd -t

Aucune sortie signifie que la syntaxe est valide.

Vérifier ensuite la configuration réellement appliquée à cet utilisateur :

sudo sshd -T -C user=user-ssh,host=localhost,addr=IP_PUBLIQUE_VM | grep passwordauthentication

Résultat attendu :

passwordauthentication yes

Recharger SSH :

sudo systemctl reload ssh

5. Valider la connexion par mot de passe

Depuis Windows :

ssh user-ssh@IP_PUBLIQUE_VM

Saisir le mot de passe du compte user-ssh. La connexion doit fonctionner.

À ce stade, l'authentification repose sur le mot de passe du compte Linux.

6. Générer une paire de clés SSH sur Windows

Sur Windows :

ssh-keygen

Choisir par exemple comme nom :

id_ed25519_tpssh

Deux fichiers sont créés :

id_ed25519_tpssh       ← clé privée : reste sur le client
id_ed25519_tpssh.pub   ← clé publique : peut être copiée sur le serveur

Il est recommandé de protéger la clé privée avec une passphrase. En environnement réel, la clé privée doit rester dans un emplacement privé, par exemple C:\Users\<utilisateur>\.ssh\.

7. Préparer le compte Linux pour l'authentification par clé

Sur la VM :

sudo mkdir -p /home/user-ssh/.ssh
sudo touch /home/user-ssh/.ssh/authorized_keys
sudo chown -R user-ssh:user-ssh /home/user-ssh/.ssh

chown user-ssh:user-ssh définit respectivement le propriétaire et le groupe.

8. Installer la clé publique

Afficher sur Windows le contenu de :

id_ed25519_tpssh.pub

Copier la ligne complète de la clé publique dans :

/home/user-ssh/.ssh/authorized_keys

Le serveur connaît désormais la clé publique autorisée pour le compte user-ssh.

9. Appliquer des permissions restrictives

Sur Linux :

chmod 700 /home/user-ssh/.ssh
chmod 600 /home/user-ssh/.ssh/authorized_keys

Ce qui donne :

.ssh/             rwx------   700
authorized_keys   rw-------   600

Le droit x sur un répertoire permet notamment de le traverser. authorized_keys est un fichier de données : il n'a pas besoin d'être exécutable.

10. Désactiver de nouveau l'authentification par mot de passe

Retirer l'exception temporaire ajoutée précédemment :

Match User user-ssh
    PasswordAuthentication yes

Puis vérifier et recharger SSH :

sudo sshd -t
sudo systemctl reload ssh
sudo sshd -T | grep passwordauthentication

Résultat attendu :

passwordauthentication no

11. Vérifier que le mot de passe ne suffit plus

Depuis Windows :

ssh user-ssh@IP_PUBLIQUE_VM

Sans clé utilisable, le résultat attendu est :

Permission denied (publickey)

Cette étape confirme que l'authentification par mot de passe est de nouveau désactivée.

12. Se connecter avec la clé privée

Depuis le dossier contenant la clé privée :

ssh -i .\id_ed25519_tpssh user-ssh@IP_PUBLIQUE_VM

Si la clé privée est protégée par une passphrase, SSH la demande localement.

L'option `-i` désigne la **clé privée**, jamais le fichier `.pub`.

-i id_ed25519_tpssh       ✓
-i id_ed25519_tpssh.pub   ✗

13. Comprendre l'authentification par clé

WINDOWS                                  SERVEUR LINUX

Clé privée                               authorized_keys
id_ed25519_tpssh                         │
      │                                  │ clé publique
      │ signe des données SSH            │
      ├─────────────────────────────────>│
      │                                  │ vérifie la signature
      │                                  │ avec la clé publique
      │<──── authentification acceptée ──│

Le serveur ne possède jamais la clé privée. La présence d'une clé publique dans authorized_keys signifie que cette clé est autorisée pour le compte. Le client doit ensuite prouver qu'il possède la clé privée correspondante, en produisant une signature que le serveur vérifie avec la clé publique.

14. Comprendre le rôle de la passphrase

La passphrase n'est pas le mot de passe du compte Linux. Elle protège localement la clé privée. Elle n'est pas envoyée au serveur.

Un ssh-agent peut conserver temporairement une clé déverrouillée afin d'éviter de ressaisir sa passphrase à chaque connexion.

À retenir

`sshd` doit fonctionner sur le serveur.
SSH utilise par défaut TCP/22, sauf configuration différente.
`authorized_keys` contient les clés publiques autorisées pour un compte Linux.
La clé privée reste sur le client et ne doit jamais être copiée sur le serveur.
`ssh -i` désigne la clé privée à utiliser.
En authentification par clé, le client signe et le serveur vérifie la signature avec la clé publique.
Une passphrase protège la clé privée localement ; elle ne remplace pas le mot de passe Linux.
Le TP permet de constater concrètement la différence entre authentification SSH par mot de passe et authentification par clé.

Adaptation par rapport au TP Vagrant

Le poste Windows de l'apprenant remplace la machine cliente Vagrant. La VM Liora/AWS joue le rôle du serveur SSH. Il n'est donc plus nécessaire d'utiliser vagrant ssh client1 ni de disposer d'un environnement Vagrant préconfiguré : les mêmes notions SSH sont manipulées directement avec l'environnement réel de formation.