Accès SSH par clé à un hôte du laboratoire

Version

1.0

Date d’édition

05/10/2026

Ouvrir un accès SSH par clé à un conteneur du laboratoire, sans mot de passe, vérifiable et révocable.

1. Objet

Dans le laboratoire, l’accès aux conteneurs se fait par clé : la connexion root par mot de passe est refusée. Cette procédure décrit l’ajout d’une clé pour un nouveau client, la lecture de la configuration réellement appliquée par le serveur SSH, puis la révocation.

Le cas de référence utilise un client SSH du VLAN 80 et le conteneur de WatchTower (CTID 2013, sur pve1). Les commandes décrivent une procédure d’administration : l’identifiant historique de la clé est conservé dans les exemples.

2. Périmètre et prérequis

Périmètre

Couvert : génération de la clé, dépôt, test, contrôle du fichier des clés, configuration effective du serveur, révocation.

Hors périmètre : ouverture du flux sur le pare-feu (procédure « Ouverture d’un flux entre deux zones du pare-feu SRX300 »), bastion d’administration Guacamole, envisagé.

Prérequis

• Un accès au nœud Proxmox qui héberge le conteneur, avec la commande pct.
• Le flux SSH autorisé de la zone du client vers celle du conteneur. Dans l’exemple : politique hermes-deploy, de lab vers srv, service junos-ssh.

3. Rôles et responsabilités

4. Procédure

Paramètres

1. Générer la clé sur le client

Avant la génération : vérifier si le fichier cible existe déjà et ne pas écraser une clé utilisée. L’exemple ci-dessous crée une clé sans phrase de passe pour un usage automatisé ; pour un usage interactif, protéger la clé par une phrase de passe et conserver un accès de secours.

ssh-keygen -t ed25519 -N "" -C "hermes-deploy@10.10.80.10" -f ~/.ssh/id_ed25519 -q
cat ~/.ssh/id_ed25519.pub

Le commentaire identifie le titulaire dans le fichier des clés autorisées : c’est lui qui permet de retrouver la clé et de la révoquer. Une clé sans phrase de passe n’est admise que pour un agent automatisé ; une personne protège sa clé par une phrase de passe.

2. Déposer la clé publique dans le conteneur

# sur le nœud Proxmox qui héberge le conteneur
pct enter 2013
# dans le conteneur : une seule ligne, la clé publique complète
mkdir -p ~/.ssh
echo '<clé publique>' >> ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

Le dépôt passe par pct : il n’exige aucun accès SSH préalable. Ajouter une clé ne retire aucun accès existant.

3. Tester la connexion sans mot de passe

# depuis le client
ssh -o BatchMode=yes -o ConnectTimeout=5 root@10.10.20.13 true && echo OK

BatchMode désactive les demandes interactives. Un résultat positif confirme une authentification non interactive, mais pas nécessairement l’utilisation de la clé visée si un agent SSH ou une autre méthode est disponible. Vérifier la clé réellement utilisée et valider au préalable l’empreinte du serveur.

4. Contrôler le fichier des clés

# dans le conteneur : chaque fin de ligne apparaît sous la forme $
cat -A ~/.ssh/authorized_keys
# supprimer une ligne parasite qui ne contient que le commentaire
sed -i '/^ *hermes-deploy@10.10.80.10$/d' ~/.ssh/authorized_keys

Un collage dans un terminal coupe souvent la clé en deux : le commentaire se retrouve seul sur une ligne invalide.

5. Lire la configuration effective du serveur SSH

sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'
# pour un client donné
sshd -T -C addr=<adresse_du_client>,user=root,host=x | grep -Ei 'passwordauthentication|permitrootlogin'

Ne pas se fier à la lecture de sshd_config : les fichiers de /etc/ssh/sshd_config.d/ sont inclus en tête et, pour chaque directive, la première valeur lue l’emporte. Sur le conteneur de WatchTower, le fichier 10-watchtower.conf fixe :

PermitRootLogin prohibit-password
PasswordAuthentication no

Après toute modification, contrôler la syntaxe avant de recharger :

sshd -t && systemctl reload ssh

Diagnostic

Révocation et retour arrière

Avant le retrait : sauvegarder authorized_keys, conserver une session de secours et vérifier l’empreinte de la clé concernée. Le commentaire est un repère modifiable, pas un identifiant cryptographique ; la commande de suppression retire toutes les lignes qui correspondent à son motif. Contrôler ensuite les accès conservés et le refus de la clé révoquée.

# dans le conteneur : retirer la clé, repérée par son commentaire
sed -i '/hermes-deploy@10.10.80.10/d' ~/.ssh/authorized_keys

Si l’accès n’a plus d’usage, retirer aussi la politique correspondante sur le pare-feu.

5. Intégration réseau

• Le client et le conteneur sont dans deux zones différentes : lab pour le client de référence, srv pour WatchTower. Le flux SSH est ouvert par la politique hermes-deploy, limitée à ces deux hôtes.
• Dans le cas documenté au 5 octobre 2026, le seul autre flux de ce client vers la zone serveurs est HTTPS vers le proxy inverse pour l’API de n8n (politique hermes-n8n).

6. Durcissement et sécurité

• Une clé par titulaire, avec un commentaire qui l’identifie ; jamais de clé partagée.
• La partie privée reste sur la machine du titulaire ; seule la partie publique circule.
• Connexion root par mot de passe refusée ; la console pct enter reste la voie de reprise.
• Écart documenté : la clé du client de référence ouvre un accès root au conteneur de WatchTower. Un compte dédié aux droits limités et une journalisation centralisée sont à prévoir ; leur mise en place n’est pas établie par cette procédure.

7. Vérifications finales

8. Références et historique des révisions

• Ouverture d’un flux entre deux zones du pare-feu SRX300 : politique hermes-deploy et diagnostic réseau.
• OpenSSH — pages de manuel sshd_config(5) et sshd(8) : directives Match, Include et option -T.