Guide complet pour mettre en place une autorité de certification SSH dans un contexte MSP, avec support multi-Yubikey et intégration dans l'infrastructure MIS.

Architecture allégée : la clé privée de la CA est stockée sur une Yubikey 5 NFC dédiée (slot PIV), pas sur disque. Un backup d'urgence (fichier classique chiffré) est conservé dans Bitwarden pour les cas de perte matérielle.

Réponse courte : oui, mais avec une distinction importante entre les rôles.

Côté Windows pour les techniciens :

• OpenSSH client/server est intégré nativement à Windows 10 (build 1809+) et Windows 11
• Vérification : Get-WindowsCapability -Online | ? Name -like 'OpenSSH*'
• Installation si absent : Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
• Pour les versions récentes d'OpenSSH (recommandé pour FIDO2) : winget install Microsoft.OpenSSH.Beta
• Le support FIDO2/Yubikey (ed25519-sk) fonctionne nativement
• L'utilisation des certificats SSH est transparente : il suffit de placer le -cert.pub à côté de la clé privée

Pour signer avec la Yubikey CA depuis Windows : Yubico fournit ykcs11.dll (inclus dans yubico-piv-tool) qui peut être utilisé comme provider PKCS#11 pour ssh-keygen -D. Marche aussi.

Cette documentation cible Debian 13 (codename Trixie), sortie le 9 août 2025. Quelques points importants pour notre cas d'usage SSH CA :

OpenSSH 10.0 : meilleurs algos par défaut, mais surtout :

• Les clés DSA ne sont plus supportées du tout, même avec les options de compat (HostKeyAlgorithms, PubkeyAcceptedAlgorithms). Aucun impact pour nous (on n'utilise que Ed25519/ECCP384), mais à savoir si tu te connectes à de très vieux équipements.
• Le support FIDO2 (libfido2) est plus mature qu'en Bookworm.
• Les algorithmes post-quantum (mlkem768x25519-sha256) sont disponibles par défaut pour le key exchange.

• Full support jusqu'à août 2028
• LTS jusqu'à juin 2030

C'est donc une base saine pour démarrer une infra MSP qui doit vivre 4-5 ans sans upgrade majeur.

┌──────────────────────────┐
│  Poste de signature      │
│  (laptop MIS Vincent)    │
│                          │
│  ┌────────────────────┐  │     ┌─────────────────────────┐
│  │ Yubikey CA dédiée  │──┼────►│ ssh-keygen -s           │
│  │ (slot PIV 9c)      │  │     │ via PKCS#11             │
│  │ ECCP384            │  │     │ → certificat signé      │
│  │ touch CACHED       │  │     └─────────────────────────┘
│  └────────────────────┘  │
│                          │
│  ┌────────────────────┐  │
│  │ Fichier emergency  │  │  (utilisé uniquement si
│  │ chiffré age        │  │   Yubikey CA perdue)
│  │ dans Bitwarden     │  │
│  └────────────────────┘  │
└──────────────────────────┘
              │
              │ déploiement via Ansible
              ▼
┌──────────────────────────────────┐
│  Serveurs clients                │
│  /etc/ssh/mis-users-ca.pub       │ ← contient 2 lignes :
│  (200+ VMs)                      │   1. Yubikey CA pub
│                                  │   2. Emergency CA pub
│  /etc/ssh/mis-revoked-keys       │ ← KRL pour révocations
└──────────────────────────────────┘

Le principe :

• La CA quotidienne vit sur Yubikey PIV → clé privée non-extractible, touch + PIN obligatoires
• La CA emergency est un fichier classique chiffré avec age, stocké dans Bitwarden
• Les deux clés publiques sont déployées sur les serveurs comme CAs valides
• En cas de perte de la Yubikey CA, on déchiffre l'emergency, on s'en sert pour signer en attendant la nouvelle Yubikey, puis on révoque (rolling rotation)

• 1x Yubikey 5 NFC dédiée à la CA (~50 €). À séparer de tes Yubikeys SSH d'authentification quotidienne. Cette Yubikey reste rangée la plupart du temps, branchée uniquement pour signer.
• Ton laptop MIS comme poste de signature (Linux, macOS ou Windows)

Sur Debian / Ubuntu / WSL2 :

sudo apt update
sudo apt install -y \
    openssh-client \
    yubikey-manager \
    opensc \
    age

Sur macOS (Homebrew) :

brew install yubikey-manager opensc age openssh

Sur Windows :

# Yubikey Manager : https://www.yubico.com/support/download/yubikey-manager/
# Installer aussi yubico-piv-tool qui contient ykcs11.dll
# OpenSSH inclus avec Windows 10/11 (sinon : Add-WindowsCapability)
# age : winget install FiloSottile.age

Cette information est cruciale pour les commandes de signature. Note le chemin selon ton OS :

Vérification rapide qu'il existe :

# Linux/macOS
ls -la $PKCS11_PATH

Pour la suite du document, on utilisera la variable $PKCS11 à adapter à ton chemin :

export PKCS11=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so

⚠️ Yubikey CA branchée. Vérifie que c'est la bonne (pas une Yubikey SSH du quotidien) :

ykman info
# Doit afficher le serial number de la Yubikey CA

PIN PIV (8 caractères minimum, sera demandé à chaque session de signature) :

ykman piv access change-pin
# Default PIN: 123456
# New PIN: [choisir 8+ chars]

PUK (utilisé pour débloquer si trop d'échecs PIN, à conserver précieusement) :

ykman piv access change-puk
# Default PUK: 12345678
# New PUK: [générer 8 chars aléatoires]

Management Key (utilisée pour les opérations admin PIV, on la protège avec le PIN) :

ykman piv access change-management-key --algorithm AES256 --generate --protect
# --protect = stocke la management key chiffrée par le PIN

📋 Notes à conserver dans Bitwarden, entrée “MIS Yubikey CA” :

• Serial number de la Yubikey
• PIN PIV
• PUK
• (la management key est protégée par le PIN, pas besoin de la stocker à part)

# Yubikey CA branchée
mkdir -p ~/mis-ssh-ca && cd ~/mis-ssh-ca
chmod 700 .
 
# Génération de la paire ECCP384 dans le slot 9c (Digital Signature)
ykman piv keys generate \
  --algorithm ECCP384 \
  --pin-policy ONCE \
  --touch-policy CACHED \
  9c \
  mis-users-ca-yubi-cert.pub
# → demande le PIN
# → demande le touch

Décortiquons les options :

Alternative plus stricte : –touch-policy ALWAYS exige un touch à chaque signature. Plus sûr mais pénible pour signer plusieurs certifs d'affilée (enrôlement de plusieurs Yubikeys d'un nouveau tech). CACHED est un bon compromis.

PIV exige qu'un certificat X.509 soit présent dans le slot, même s'il ne sert à rien dans notre usage SSH :

ykman piv certificates generate \
  --subject "CN=MIS Users CA,O=Make IT Simple,C=BE" \
  --valid-days 3650 \
  9c \
  mis-users-ca-yubi-cert.pub
# → demande le PIN

C'est cette clé publique qui sera déployée sur tous les serveurs comme CA principale acceptée :

ssh-keygen -D $PKCS11 -e > mis-users-ca-yubi.pub
 
# Inspection
cat mis-users-ca-yubi.pub
# Doit afficher : ecdsa-sha2-nistp384 AAAA...
 
# Renommer avec un commentaire explicite (facultatif)
sed -i 's|$| MIS Users CA - Yubikey|' mis-users-ca-yubi.pub

La CA emergency est une clé privée Ed25519 classique, mais qui ne doit jamais exister en clair sur ton laptop après génération. La meilleure approche : un container Docker éphémère sans réseau, qui ne laisse aucune trace après destruction.

Pourquoi pas juste sur ton laptop ? Parce qu'entre la génération en clair et le chiffrement age, la clé existe en clair sur ton disque. Avec un container sans réseau, aucun process tiers (même un éventuel malware) ne peut exfiltrer pendant cette fenêtre.

Génération via Docker :

# Lancement d'un container Debian 13 minimal, SANS RÉSEAU
docker run --rm -it \
  --network none \
  --hostname offline-ca-gen \
  -v ~/mis-ssh-ca:/output \
  debian:trixie-slim bash

Dans le container (aucun accès Internet possible) :

# Installation des outils (depuis le cache APT du container, pas Internet)
# Si l'image n'a pas les paquets, faire docker build préalable (voir note ci-dessous)
apt-get install -y openssh-client age coreutils 2>/dev/null || echo "Image sans cache, voir note"
 
cd /tmp
 
# Génération Ed25519 classique
ssh-keygen -t ed25519 -a 200 \
  -f mis-users-ca-emergency \
  -C "MIS Users CA - EMERGENCY USE ONLY" \
  -N ''
 
# Chiffrement avec age - passphrase en interactif (PAS en argument !)
age --passphrase \
  -o mis-users-ca-emergency.age \
  mis-users-ca-emergency
# → entrer une passphrase TRÈS robuste (Diceware 6-8 mots recommandé)
 
# Effacement sécurisé de la version en clair
shred -u mis-users-ca-emergency
 
# Copie des fichiers finaux vers l'hôte via le volume monté
cp mis-users-ca-emergency.age /output/
cp mis-users-ca-emergency.pub /output/
 
# Sortie du container → destruction automatique (--rm)
exit

Note : si debian:trixie-slim n'a pas les paquets en cache, prépare une image avec les outils inclus une fois pour toutes :

# À faire une seule fois, sur ton hôte
cat > /tmp/Dockerfile <<'EOF'
FROM debian:trixie-slim
RUN apt-get update && \
    apt-get install -y --no-install-recommends \
        openssh-client age coreutils && \
    rm -rf /var/lib/apt/lists/*
EOF
 
docker build -t mis-ca-gen:latest -f /tmp/Dockerfile /tmp/
 
# Puis utiliser cette image (en remplaçant debian:trixie-slim) :
docker run --rm -it --network none -v ~/mis-ssh-ca:/output mis-ca-gen:latest bash

Variante Podman rootless (si tu préfères ne pas dépendre d'un daemon Docker root) :

podman run --rm -it --network none -v ~/mis-ssh-ca:/output:Z mis-ca-gen:latest bash

Résultat sur ton hôte :

ls -la ~/mis-ssh-ca/
# mis-users-ca-emergency.age       ← clé privée DOUBLEMENT chiffrable (age + Bitwarden)
# mis-users-ca-emergency.pub       ← clé publique (pas un secret)
# mis-users-ca-yubi.pub            ← clé publique de la Yubikey CA
# mis-users-ca-yubi-cert.pub       ← cert X.509 PIV (inutile pour SSH)

Même approche pour la CA d'hôtes, si tu décides de la mettre en place :

• Soit sur la même Yubikey dans le slot 9a (Authentication) ou 9d (Key Management)
• Soit avec un fichier classique chiffré, plus simple pour démarrer

Comme tu as décidé de ne pas faire les certifs machines tout de suite, on saute cette étape pour le moment. À reprendre quand tu te lanceras dans les certifs d'hôtes.

Principe : la clé emergency est protégée par deux couches indépendantes :

Clé privée Ed25519 (claire)
        ↓ couche 1 : chiffrement age (passphrase forte)
Fichier .age (illisible sans passphrase age)
        ↓ couche 2 : attachment dans Bitwarden (chiffré par master password)
Coffre Bitwarden (illisible sans master password)

Pour que cette défense en profondeur fonctionne, les deux secrets doivent être stockés à des endroits différents : sinon une seule compromission donne accès à tout.

Entrée “MIS SSH CA - Master Backup” :

Notes (champ texte de l'entrée) :

═══════════════════════════════════════════════
PROCÉDURE DE RÉCUPÉRATION D'URGENCE

1. Récupérer la passphrase age :
   - Coffre bureau MIS, enveloppe scellée "CA Emergency"
   - OU coffre backup (maison Vincent / coffre bancaire)

2. Télécharger mis-users-ca-emergency.age depuis cette entrée

3. Sur container éphémère :
     docker run --rm -it --network none -v $PWD:/work mis-ca-gen bash
     cd /work
     age --decrypt mis-users-ca-emergency.age > recovery-key
     chmod 600 recovery-key
     # utiliser pour signer (voir Phase 9 du runbook)
     shred -u recovery-key
     exit

═══════════════════════════════════════════════
INFOS YUBIKEY CA

Serial number    : [serial à compléter]
PIN PIV          : [PIN à compléter]
PUK              : [PUK à compléter]
Algorithme       : ECCP384
Slot             : 9c
Touch policy     : CACHED
PIN policy       : ONCE

═══════════════════════════════════════════════
FINGERPRINTS (vérification d'intégrité)

Yubikey CA pub   : [ssh-keygen -l -f mis-users-ca-yubi.pub]
Emergency CA pub : [ssh-keygen -l -f mis-users-ca-emergency.pub]

═══════════════════════════════════════════════

Attachments (fichiers attachés à l'entrée) :

Ce qui ne doit JAMAIS aller dans Bitwarden :

• ❌ La passphrase age (sinon couche 1 + couche 2 = même point de défaillance)
• ❌ La clé privée emergency en clair
• ❌ Un export PKCS#12 de la Yubikey (impossible techniquement, mais à ne pas chercher à faire)

La passphrase age uniquement. À écrire à la main sur papier :

• Localisation principale : coffre physique au bureau MIS, dans une enveloppe scellée “CA Emergency - Vincent uniquement”
• Localisation backup : coffre physique à la maison de Vincent (ou coffre bancaire), même enveloppe

Format recommandé : passphrase Diceware 6-8 mots, plus facile à recopier sans erreur qu'une chaîne aléatoire.

Exemple : correct horse battery staple winter coffee (à remplacer évidemment).

Approche avancée (optionnelle) : Shamir Secret Sharing avec ssss-split pour découper la passphrase en N parts dont K nécessaires. Exemple : 3 parts, 2 nécessaires, distribuées entre Vincent + associé + avocat de confiance. Sécurité maximale, mais à mettre en place quand tout le reste est rodé.

En complément (ceinture-bretelles) :

• Clé USB chiffrée LUKS dans coffre physique avec une copie de tout ~/mis-ssh-ca/
• À refaire à chaque rotation/renouvellement de CA
• La passphrase LUKS est encore un secret différent (toujours pas dans Bitwarden)

⚠️ Avant de tout ranger dans le coffre et de considérer le setup terminé, tu dois faire un test de récupération complet. C'est l'étape qui te garantit que le jour J, la procédure fonctionnera vraiment.

# 1. Dans un dossier temporaire de test
mkdir /tmp/test-recovery && cd /tmp/test-recovery
 
# 2. Copier le .age depuis Bitwarden (téléchargement de l'attachment)
# OU depuis ~/mis-ssh-ca/ si encore dispo
cp ~/mis-ssh-ca/mis-users-ca-emergency.age .
 
# 3. Aller récupérer le papier dans le coffre, lire la passphrase
#    (Geste réel, pas une simulation : tu dois vérifier que la passphrase
#     est bien lisible et que tu peux la recopier sans erreur)
 
# 4. Déchiffrer en utilisant la passphrase du papier
age --decrypt mis-users-ca-emergency.age > recovery-key
# → entrer la passphrase telle qu'écrite sur papier
 
# 5. Vérifier que la clé déchiffrée est bien la bonne
ssh-keygen -y -f recovery-key > recovered.pub
diff recovered.pub ~/mis-ssh-ca/mis-users-ca-emergency.pub
# Sortie attendue : VIDE (les deux fichiers sont identiques)
# Si différents → la passphrase a été mal recopiée OU le .age est corrompu
 
# 6. Nettoyage immédiat
shred -u recovery-key recovered.pub
cd .. && rm -rf /tmp/test-recovery

Si le test réussit, tu as validé :

• ✅ La passphrase est correctement écrite sur papier (lisible, sans erreur)
• ✅ Le fichier .age dans Bitwarden n'est pas corrompu
• ✅ Tu sais exécuter la procédure (le geste compte autant que le savoir)
• ✅ Les fingerprints correspondent

Si le test échoue, NE PAS continuer. Identifier le problème (passphrase mal recopiée ? mauvais fichier .age ?) et regénérer si nécessaire.

À refaire annuellement dans le cadre du drill de récupération (voir checklist en fin de doc).

Sur ton poste de signature, prépare un fichier qui contient les deux clés publiques (Yubikey + emergency) que tu vas déployer sur tous les serveurs :

cd ~/mis-ssh-ca
cat mis-users-ca-yubi.pub mis-users-ca-emergency.pub > mis-users-ca-deploy.pub
 
cat mis-users-ca-deploy.pub
# Doit contenir 2 lignes :
# ecdsa-sha2-nistp384 AAAA... MIS Users CA - Yubikey
# ssh-ed25519 AAAA... MIS Users CA - EMERGENCY USE ONLY

C'est ce fichier mis-users-ca-deploy.pub qui sera distribué sur tout le parc. OpenSSH accepte plusieurs CAs dans un même TrustedUserCAKeys, une par ligne.

Sur un serveur client (Debian 13 provisionné via cloud-init) :

# Copie du fichier de CAs
scp ~/mis-ssh-ca/mis-users-ca-deploy.pub mis-admin@srv01.acme.lan:/tmp/
 
# Côté serveur, déploiement
ssh mis-admin@srv01.acme.lan
sudo install -o root -g root -m 0644 /tmp/mis-users-ca-deploy.pub /etc/ssh/mis-users-ca.pub
 
# Création d'un KRL vide initial
sudo ssh-keygen -k -f /etc/ssh/mis-revoked-keys
sudo chmod 644 /etc/ssh/mis-revoked-keys
 
# Configuration sshd
sudo tee -a /etc/ssh/sshd_config <<'EOF'
 
# ===== MIS SSH CA =====
TrustedUserCAKeys /etc/ssh/mis-users-ca.pub
RevokedKeys /etc/ssh/mis-revoked-keys
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
# ======================
EOF
 
# Test et reload
sudo sshd -t && sudo systemctl reload ssh

À industrialiser via Ansible (voir Phase 7).

Sur Windows (PowerShell, Yubikey du tech branchée) :

# Définition d'un PIN FIDO2 si pas déjà fait (via Yubikey Manager GUI)
 
ssh-keygen -t ed25519-sk -O resident -O application=ssh:mis -O verify-required `
  -f $env:USERPROFILE\.ssh\id_ed25519_sk_yubi1 `
  -C "vincent@yubi-primary"

Sur Linux/macOS :

ssh-keygen -t ed25519-sk -O resident -O application=ssh:mis -O verify-required \
  -f ~/.ssh/id_ed25519_sk_yubi1 \
  -C "vincent@yubi-primary"

Résultat : id_ed25519_sk_yubi1 (stub) et id_ed25519_sk_yubi1.pub (clé publique).

Le tech envoie sa .pub au poste de signature. Yubikey CA branchée :

cd ~/mis-ssh-ca
export PKCS11=/usr/lib/x86_64-linux-gnu/opensc-pkcs11.so
 
# Variables
PUBKEY=/tmp/vincent-yubi-primary.pub
CERT_ID="vincent-yubi-primary-$(date +%Y)"
PRINCIPALS="mis-admin,vincent"
VALIDITY="+52w"
SERIAL=1001
 
ssh-keygen -s mis-users-ca-yubi.pub \
  -D $PKCS11 \
  -I "$CERT_ID" \
  -n "$PRINCIPALS" \
  -V "$VALIDITY" \
  -z $SERIAL \
  -O clear \
  -O no-port-forwarding \
  -O no-agent-forwarding \
  -O permit-pty \
  "$PUBKEY"
 
# → demande le PIN PIV (1x par session grâce à --pin-policy ONCE)
# → demande le touch sur la Yubikey CA
# → fichier vincent-yubi-primary-cert.pub généré à côté de la .pub

Note importante : avec -D $PKCS11, l'argument -s n'est pas la clé privée (qui est sur la Yubikey) mais la clé publique de la CA. C'est elle qui permet à ssh-keygen d'identifier laquelle utiliser sur le token.

Renvoyer le -cert.pub au technicien.

Le tech place le -cert.pub à côté de sa clé :

~/.ssh/
├── id_ed25519_sk_yubi1
├── id_ed25519_sk_yubi1.pub
└── id_ed25519_sk_yubi1-cert.pub    ← nouveau

Vérification du contenu du certificat :

ssh-keygen -L -f ~/.ssh/id_ed25519_sk_yubi1-cert.pub

Doit afficher : Signing CA (ECDSA SHA256:… = ta Yubikey CA), Principals, Valid from/to.

ssh -i ~/.ssh/id_ed25519_sk_yubi1 mis-admin@srv01.acme.lan
# → PIN FIDO2 demandé (côté Yubikey du tech)
# → touch Yubikey du tech
# → connecté

Répéter Étape 4.1 à 4.4 avec la deuxième Yubikey du tech. Utiliser :

• Serial différent (-z 1002)
• Identifiant unique (vincent-yubi-backup-2026)

Host *.acme.lan acme-* *.mis.lan
    User mis-admin
    IdentityFile ~/.ssh/id_ed25519_sk_yubi1
    IdentityFile ~/.ssh/id_ed25519_sk_yubi2
    IdentitiesOnly yes
    CertificateFile ~/.ssh/id_ed25519_sk_yubi1-cert.pub
    CertificateFile ~/.ssh/id_ed25519_sk_yubi2-cert.pub

Yubikey CA branchée sur le poste de signature :

cd ~/mis-ssh-ca
 
# Spec de révocation
cat > /tmp/krl-spec.txt <<'EOF'
# Révocation par serial
serial: 1002
 
# Alternative : par identifiant
# id: vincent-yubi-backup-2026
 
# Alternative : par hash de clé publique
# sha256: SHA256:xxxxx
EOF
 
# Génération/mise à jour de la KRL via Yubikey
ssh-keygen -k -f mis-revoked-keys \
  -s mis-users-ca-yubi.pub \
  -D $PKCS11 \
  -u /tmp/krl-spec.txt
# -u = update (ajoute au KRL existant)
# → demande PIN + touch

ansible-playbook -i inventory.yml mis-update-krl.yml

En quelques minutes, la Yubikey backup n'est plus utilisable sur aucun serveur MIS. Aucune modification de sshd_config ni d'authorized_keys n'est requise.

Refaire l'étape 4.2 (signature) avec un nouvel identifiant vincent-yubi-primary-2027 et envoyer le nouveau -cert.pub au tech. Le tech remplace son ancien -cert.pub.

Cron Odoo qui scanne les certificats expirant dans 30 jours et :

1. Notifie le tech par mail
2. Propose un wizard de renouvellement
3. Si le tech accepte, déclenche une demande de signature (qui attend que tu branches la Yubikey CA + valides physiquement)
4. Envoie le nouveau -cert.pub au tech

playbooks/mis-ssh-ca-deploy.yml :

---
- name: Deploy MIS SSH CA on all client servers
  hosts: all_clients
  become: true
  vars:
    ca_pub_path: files/mis-users-ca-deploy.pub   # contient les 2 CAs (Yubikey + emergency)
    krl_path: files/mis-revoked-keys
  
  tasks:
    - name: Deploy MIS users CA public keys
      copy:
        src: "{{ ca_pub_path }}"
        dest: /etc/ssh/mis-users-ca.pub
        owner: root
        group: root
        mode: '0644'
      notify: reload sshd
    
    - name: Deploy current KRL
      copy:
        src: "{{ krl_path }}"
        dest: /etc/ssh/mis-revoked-keys
        owner: root
        group: root
        mode: '0644'
      notify: reload sshd
    
    - name: Configure sshd for MIS CA
      blockinfile:
        path: /etc/ssh/sshd_config
        marker: "# {mark} MIS CA managed by Ansible"
        block: |
          TrustedUserCAKeys /etc/ssh/mis-users-ca.pub
          RevokedKeys /etc/ssh/mis-revoked-keys
          PasswordAuthentication no
          KbdInteractiveAuthentication no
        validate: 'sshd -t -f %s'
      notify: reload sshd
    
    - name: Ensure mis-admin user exists
      user:
        name: mis-admin
        groups: sudo
        append: yes
        shell: /bin/bash
        state: present
    
    - name: Sudo NOPASSWD for mis-admin
      copy:
        content: "mis-admin ALL=(ALL) NOPASSWD:ALL\n"
        dest: /etc/sudoers.d/mis-admin
        mode: '0440'
        validate: 'visudo -cf %s'
  
  handlers:
    - name: reload sshd
      systemd:
        name: ssh
        state: reloaded

playbooks/mis-update-krl.yml :

---
- name: Update MIS SSH KRL on all client servers
  hosts: all_clients
  become: true
  
  tasks:
    - name: Deploy updated KRL
      copy:
        src: files/mis-revoked-keys
        dest: /etc/ssh/mis-revoked-keys
        mode: '0644'
      notify: reload sshd
  
  handlers:
    - name: reload sshd
      systemd:
        name: ssh
        state: reloaded

⚠️ Ne JAMAIS sauter cette étape.

C'est un parachute indépendant de la CA SSH (ni Yubikey, ni emergency CA). Le compte break-glass utilise une clé SSH classique, pour le cas où toute la PKI CA serait inaccessible (perte Yubikey + Bitwarden corrompu + papier coffre perdu, scénario apocalypse).

# Sur un poste sûr, génération d'une clé classique pour le parachute
ssh-keygen -t ed25519 -a 200 -f mis-breakglass -C "MIS BREAK-GLASS - DO NOT USE"
# Choisir une passphrase ultra-robuste
 
# Stocker mis-breakglass (privé) :
#   - Chiffré dans Bitwarden (attachment) - entrée distincte de la CA
#   - Sur clé USB chiffrée dans coffre physique
#   - Supprimer du disque local après stockage sécurisé
 
# Garder mis-breakglass.pub pour déploiement

Intégrer la clé publique dans le template cloud-init / virt-customize de tous les serveurs :

virt-customize -a debian-13-genericcloud-amd64.qcow2 \
  --run-command 'useradd -m -s /bin/bash mis-breakglass' \
  --ssh-inject mis-breakglass:file:/path/to/mis-breakglass.pub \
  --run-command 'echo "mis-breakglass ALL=(ALL) NOPASSWD:ALL" > /etc/sudoers.d/mis-breakglass' \
  ...

Workflow :

1. Acheter une nouvelle Yubikey 5 NFC dédiée à la CA
2. Déchiffrer temporairement l'emergency :

```bash

 cd ~/mis-ssh-ca
 age --decrypt mis-users-ca-emergency.age > /tmp/emergency-key
 chmod 600 /tmp/emergency-key
 ```
- **Utiliser l'emergency CA pour signer une nouvelle CA Yubikey** (chaîne de confiance temporaire) :
 ```bash
 # Préparer la nouvelle Yubikey (Étapes 1.4 + 2.1 à 2.3)
 # Tu obtiens mis-users-ca-yubi-NEW.pub
 ```
- Mettre à jour ''mis-users-ca-deploy.pub'' pour inclure la **nouvelle** Yubikey CA + l'emergency (toujours) :
 ```bash
 cat mis-users-ca-yubi-NEW.pub mis-users-ca-emergency.pub > mis-users-ca-deploy.pub
 ```
- Déployer via Ansible sur tout le parc
- Révoquer l'ancienne Yubikey CA via KRL (signature avec la NEW Yubikey) :
 ```bash
 cat > /tmp/krl-revoke-old-ca.txt <<'EOF'
 # Révocation de l'ancienne CA Yubikey perdue
 sha256: SHA256:<fingerprint de mis-users-ca-yubi-OLD.pub>
 EOF
 
 ssh-keygen -k -f mis-revoked-keys \
   -s mis-users-ca-yubi-NEW.pub \
   -D $PKCS11 \
   -u /tmp/krl-revoke-old-ca.txt
 ```
- **Effacement sécurisé** du fichier emergency en clair :
 ```bash
 shred -u /tmp/emergency-key
 ```
- Mise à jour de l'entrée Bitwarden avec le nouveau serial Yubikey

Important : tous les certificats utilisateurs signés par l'ancienne Yubikey CA sont toujours valides (puisque l'ancienne CA est encore dans le déploiement jusqu'à révocation, et que la révocation cible le pub de la CA, pas les certifs signés). Pour invalider tous les certifs émis par l'ancienne CA, supprimer son .pub du déploiement et redéployer.

Scénario apocalypse : Yubikey CA perdue + Bitwarden inaccessible + papier coffre détruit.

1. Connexion sur chaque serveur via SSH avec mis-breakglass :

```bash

 ssh -i ~/.bitwarden-recovered/mis-breakglass mis-breakglass@srv01.acme.lan
 ```
- Régénération complète d'une nouvelle CA (depuis zéro, Phase 2)
- Déploiement manuel du nouveau ''mis-users-ca.pub'' sur chaque serveur via ''mis-breakglass''
- Re-signature de toutes les Yubikeys techniciens
- Rotation du break-glass aussi (puisqu'il a servi)

À tester : faire un drill annuel de récupération sur un environnement de staging pour valider que la procédure marche avant d'en avoir vraiment besoin.

# Inspecter un certificat utilisateur
ssh-keygen -L -f id_ed25519_sk_yubi1-cert.pub
 
# Voir l'état PIV de la Yubikey CA
ykman piv info
 
# Voir le slot 9c (où vit la CA)
ykman piv keys metadata 9c
 
# Voir la KRL active sur un serveur
ssh-keygen -Q -f /etc/ssh/mis-revoked-keys -t krl
 
# Tester un certif spécifique contre la KRL
ssh-keygen -Q -f /etc/ssh/mis-revoked-keys -t krl id_ed25519_sk_yubi1-cert.pub
# Output: "id_ed25519_sk_yubi1-cert.pub: ok" ou "REVOKED"
 
# Côté serveur, voir les connexions par certificat
journalctl -u ssh | grep "Accepted publickey.*ID"
 
# Lister les clés publiques visibles via PKCS#11 (avec Yubikey CA branchée)
ssh-keygen -D $PKCS11 -e
 
# Tester une signature sans toucher à un fichier
echo "test" | ssh-keygen -Y sign -n test -f mis-users-ca-yubi.pub -D $PKCS11

ssh-keygen -s CA_PUBLIC_KEY \
  -D PKCS11_PROVIDER \
  -I CERT_IDENTIFIER \
  -n PRINCIPAL1,PRINCIPAL2 \
  -V "+VALIDITY" \
  -z SERIAL \
  -O OPTION1 \
  -O OPTION2 \
  USER_PUBLIC_KEY.pub

• OpenSSH manual ssh-keygen(1) : man ssh-keygen (sections CERTIFICATES et KEY REVOCATION LISTS)
• Documentation officielle Yubico FIDO2 SSH : https://developers.yubico.com/SSH/
• Documentation Yubico PIV : https://developers.yubico.com/PIV/Guides/SSH//with//PIV//and//PKCS11.html
• Documentation age : https://age-encryption.org/
• Format des certificats SSH (technique) : PROTOCOL.certkeys dans le code OpenSSH

• [ ] Yubikey 5 NFC dédiée à la CA commandée
• [ ] Yubikeys 5 NFC techniciens commandées (2 par tech minimum)
• [ ] Bitwarden ready avec entrée “MIS SSH CA - Master Backup”
• [ ] Coffre physique identifié pour passphrase + clé USB de backup
• [ ] OpenSSH + yubikey-manager + opensc + age installés sur le poste de signature

• [ ] PINs PIV de la Yubikey CA configurés (PIN + PUK + management key)
• [ ] CA principale générée sur Yubikey (slot 9c, ECCP384)
• [ ] Clé publique Yubikey CA exportée (mis-users-ca-yubi.pub)
• [ ] Image Docker mis-ca-gen préparée
• [ ] Emergency CA générée dans container éphémère + chiffrée avec age
• [ ] Bitwarden : entrée “MIS SSH CA - Master Backup” avec attachments
• [ ] Passphrase age écrite sur papier dans coffre bureau MIS
• [ ] Passphrase age (copie) dans coffre backup (maison ou bancaire)
• [ ] Backup additionnel sur clé USB LUKS dans coffre
• [ ] Test de récupération validé (Étape 2.7) avant rangement définitif

• [ ] Compte break-glass mis-breakglass créé et clé déployée partout (indépendant CA)
• [ ] Playbook Ansible mis-ssh-ca-deploy.yml testé sur 1-2 serveurs
• [ ] Fichier mis-users-ca-deploy.pub contient les 2 CAs (Yubikey + emergency)
• [ ] Déploiement progressif sur le parc complet

• [ ] Premières Yubikeys enrôlées (toi en priorité)
• [ ] Tests de connexion validés
• [ ] Configuration ~/.ssh/config documentée pour les techs

• [ ] Module Odoo makeitsimple_ssh_ca (modèles + wizards)
• [ ] Intégration Semaphore pour déploiement KRL
• [ ] Cron de notification d'expiration des certifs
• [ ] Drill de récupération annuel (cas 1 emergency) testé en staging

Document maintenu par Make IT Simple - dernière révision : 2026