# Accès SSH par clé à un hôte du laboratoire - Link: https://dpioch.aristeecampus.org/procedure/acces-ssh-par-cle-hote-laboratoire/ - Published: 2026-10-05T15:14:17+02:00 - Author: Admin 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 | Rôle | Responsabilité | | **Titulaire de la clé** | Génère la clé et conserve la partie privée, qui ne quitte jamais sa machine. | | **Administrateur virtualisation** | Dépose la clé publique depuis le nœud Proxmox, contrôle la configuration du serveur SSH, révoque la clé. | ## 4. Procédure ### Paramètres | Paramètre | Description | Valeur du cas de référence | | **CLIENT** | Machine qui se connecte | Client de référence, 10.10.80.10 | | **CTID** | Conteneur cible | 2013 (WatchTower, sur pve1) | | **HOTE** | Adresse du conteneur | 10.10.20.13 | | **COMMENTAIRE** | Identifiant de la clé | hermes-deploy@10.10.80.10 | ### 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 '' >> ~/.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=,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 ``` Attention **Accès temporaire par mot de passe.** Tant que le bastion Guacamole n’est pas déployé, un accès par mot de passe pour l’administrateur passe par un bloc `Match Address` limité au sous-réseau d’administration, placé en fin de fichier (les blocs `Match` doivent être les derniers) et commenté comme temporaire. Ce contournement existe sur deux hôtes du laboratoire, consigné comme écart ECA-01, et disparaît au déploiement de Guacamole. ### Diagnostic | Symptôme | Cause probable | Suite | | **Délai dépassé** | Flux bloqué par le pare-feu ou par l’hôte | Procédure d’ouverture d’un flux, section diagnostic. | | **Connection refused** | Service SSH arrêté ou port fermé sur l’hôte | Vérifier le service depuis la console `pct enter`. | | **Permission denied (publickey)** | Le réseau fonctionne : clé absente, coupée au collage, ou droits du fichier trop ouverts | Étapes 2 et 4. Ne pas modifier le pare-feu. | ### 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 | Contrôle | Critère d’acceptation | Statut | | **Connexion par clé** | Le test avec BatchMode affiche OK | ☐ | | **Fichier des clés** | cat -A montre une clé par ligne, sans ligne parasite | ☐ | | **Droits** | ~/.ssh en 700, authorized_keys en 600 | ☐ | | **Configuration effective** | sshd -T renvoie permitrootlogin without-password et passwordauthentication no | ☐ | | **Révocation** | La clé est retrouvable par son commentaire | ☐ | ## 8. Références et historique des révisions * [Ouverture d’un flux entre deux zones du pare-feu SRX300](https://dpioch.aristeecampus.org/procedure/ouverture-flux-inter-zones-srx300/): politique `hermes-deploy` et diagnostic réseau. * OpenSSH — pages de manuel sshd_config(5) et sshd(8) : directives Match, Include et option -T. | Version | Date | Modifications | | 1.0 | 05/10/2026 | Création à partir du cas d’accès par clé au conteneur de WatchTower ; démarche côté client SSH et administrateur. |