Générer une clé SSH forte 💪

L'objectif de cet article est de

• faire comprendre l’intérêt des clés SSH (plutôt que des mots de passe)
• générer une paire de clés SSH forte avec l'algorithme ed25519
  avec passphrase sur Windows, Linux et macOS,
• utiliser Agent SSH pour faciliter l'utilisation des clés avec passphrases (évite de taper sa passphrase à chaque connexion)
• configuration SSH pour utiliser un bastion ou Jump host de façon transparente

Clé SSH plutôt que mot de passe 🤔 ?

L'accès SSH chiffre l'intégralité du trafic qui transite à travers la connexion, mais le point faible réside dans l'authentification par mot de passe, vulnérable aux attaques par force brute = ☠

Certes, Fail2Ban permet de bloquer temporairement les IP sources après plusieurs tentatives échouées, réduisant ainsi la surface d'attaque. Mais aujourd'hui, les attaquants diversifient leurs origines (botnets, proxies, VPN) et combinent attaques par dictionnaire avec des bases de mots de passe compromis (leaks) = ☠

La RFC 4252 déconseille l'authentification par mot de passe depuis 2006 (ça fait 20 ans 😅), privilégiant l'authentification par clé SSH (apparue en 1995 et largement adoptée au début des années 2000).

Le système de clés SSH repose sur la cryptographie asymétrique : chaque paire comprend deux clés mathématiquement liées et lors de la génération (paragraphes suivants), tu obtiens :

• Clé privée : strictement confidentielle, jamais partagée, à sécuriser au maximum
• Clé publique : peut être diffusée librement sans risque

Le principe : tu conserves la clé privée sur ton poste d'administration et tu déposes la clé publique sur le serveur cible. Plus besoin de mot de passe ! Enfin presque... Si un attaquant compromet ton poste et dérobe ta clé privée = ☠

C'est pourquoi il est impératif de protéger ta clé privée par une passphrase. Tu te demandes sans doute : quel intérêt si je dois saisir cette passphrase à chaque connexion 😑 ? C'est là qu'intervient le SSH Agent : c'est un exécutable/service installé sur ton poste qui mémorise ta passphrase une seule fois par session 😍

Résultat : un accès ultra sécurisé à ton serveur SSH 🎉

Pourquoi Ed25519

Ed25519 est aujourd'hui l'algorithme recommandé pour les nouvelles clés SSH. Il offre une sécurité équivalente à RSA 3000-4096 bits avec seulement 256 bits de clé.

Ed25519 est supporté depuis OpenSSH 6.5 (depuis 2014).
RSA 4096 bits reste pertinent pour les environnements legacy nécessitant une compatibilité maximale.

Avantages techniques de Ed25519 :

• Performance : génération et vérification de signatures nettement plus rapides que RSA
• Clés compactes : 68 caractères contre 3072 pour RSA, facilitant gestion et déploiement
• Robustesse : résistant aux failles PRNG et attaques par collision
• Signatures déterministes : contrairement à ECDSA, élimine les risques liés aux générateurs aléatoires défaillants

Générer sa clé SSH sous Linux, Windows ou macOS

Vérifier l'existence des pré-requis sous Windows

Sous Windows, le pré-requis est OpenSSH client, à vérifier dans un terminal lancé en Admin :

# Vérifier si OpenSSH.Client est disponible, nécessite les droits d'admin
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH.Client*'

# Si absent, l'installer en admin avec :
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0

Générer une clé SSH Ed25519 sous Windows (PowerShell)

Une fois la disponibilité d'OpenSSH vérifiée, la génération d'une clé Ed25519 se fait directement avec ssh-keygen dans PowerShell.

ssh-keygen -t ed25519 -f $env:USERPROFILE\.ssh\bastion -C "commentaire ici"

• Quand PowerShell demande la passphrase, entrer une phrase de passe longue et complexe (20+ caractères) puis confirmer.
• La clé privée sera dans %USERPROFILE%\.ssh\bastion et la clé publique dans %USERPROFILE%\.ssh\bastion.pub.

Générer une clé SSH Ed25519 sous Linux et macOS

Sous Linux, ssh-keygen est généralement déjà disponible avec OpenSSH.

ssh-keygen -t ed25519 -f ~/.ssh/bastion -C "commentaire ici"

• Accepter le chemin proposé ou valide celui indiqué, puis saisis une passphrase robuste et mémorisable.
• Les fichiers générés seront ~/.ssh/bastion (privée) et ~/.ssh/bastion.pub (publique), avec des permissions à laisser strictes sur la clé privée.

Ajouter une passphrase à une clé SSH existante

Si vous avez déjà une clé sans passphrase et que vous souhaitez lui ajouter une sécurité par passphrase :

ssh-keygen -p -f ~/.ssh/bastion

SSH Agent

Qu'est-ce que SSH Agent ?

Sans lui, chaque connexion SSH nécessite la saisie de la passphrase protégeant votre clé privée.
Vous déverrouillez votre clé 1 seule fois au démarrage de session, et l'agent la réutilise automatiquement pour toutes vos connexions SSH ultérieures 🤩.

Le SSH Agent est un gestionnaire de clés (process ou service) qui conserve vos clés privées déchiffrées en mémoire sécurisée.

Fonctionnement

L'agent tourne en arrière-plan comme un daemon et répond aux demandes d'authentification sans jamais exposer la clé privée elle-même. Seul l'agent accède à la clé en mémoire : les applications SSH lui envoient les données à signer, et il retourne uniquement la signature cryptographique.

Cette approche combine sécurité maximale (passphrase obligatoire, clé jamais exposée) et confort d'utilisation (saisie unique par session).

Configuration de SSH Agent sous Windows

Sous Windows, ssh-agent est un service système qui doit être activé explicitement.

Set-Service -Name ssh-agent -StartupType Automatic
Start-Service ssh-agent

# vérifier que le service est actif :
Get-Service ssh-agent

Une fois le service démarré, ajouter la clé bastion dans l'agent :

ssh-add $env:USERPROFILE\.ssh\bastion
# saisir la passphrase lorsqu'elle est demandé. 

# vérifier les clés chargées
ssh-add -l

💡 La clé reste en mémoire jusqu'au redémarrage du système ou arrêt manuel du service.

Configuration de SSH Agent sous Linux

Sur la plupart des distributions Linux, ssh-agent démarre automatiquement avec la session.
Pour un démarrage manuel ou en environnement serveur, ajouter dans ~/.profile ou ~/.bashrc :

if
[ -z "$(pgrep ssh-agent)" ]; then
    eval $(ssh-agent -s) > /dev/null
else
    export SSH_AGENT_PID=$(pgrep ssh-agent)
    export SSH_AUTH_SOCK=$(find ${TMPDIR:-/tmp}/ssh-* -name agent.*)
fi

Charge la clé ssh bastion dans l'agent :

bashssh-add ~/.ssh/bastion
# saisir la passphrase

# lister les clés chargées
bashssh-add -l

# supprimer toutes les clés de l'agent
bashssh-add -D

Configuration de SSH Agent sous macOS

macOS intègre ssh-agent nativement et le démarre automatiquement. Pour une intégration optimale avec le trousseau (Keychain), crée ou édite ~/.ssh/config :

textHost *
  AddKeysToAgent yes
  UseKeychain yes
  IdentityFile ~/.ssh/bastion

Charger la clé dans l'agent et stocke la passphrase dans le trousseau macOS :

bashssh-add --apple-use-keychain ~/.ssh/bastion

Entrer la passphrase une fois, le trousseau la mémorise et la fournit automatiquement à chaque démarrage, macOS recharge automatiquement les clés depuis le trousseau au démarrage, sans ressaisir la passphrase.

Bonnes pratiques de sécurité pour le SSH Agent

L'utilisation de ssh-agent ne diminue pas la sécurité si on respecte ces règles :

• Toujours utiliser une passphrase forte (20+ caractères) sur les clés privées, utiliser si nécessaire un gestionnaire de mot de passe (KeepassX, VaultWarden ou autre).
• Verrouiller sa session lorsqu'on s'absentes (l'agent reste actif en arrière-plan)
• Utiliser ProxyJump (disponible depuis OpenSSH 7.3, 2016) pour rebondir via le bastion sans exposer l'agent, l'authentification vers le serveur final se fait directement depuis la machine locale, le bastion ne servant que de tunnel réseau sans accès aux clés.
  Ne jamais utiliser l'ancienne méthode (ssh-agent forwarding) qui expose les clés aux bastion (critique si compromis).

Utiliser plusieurs clés SSH permet de séparer les usages et de limiter l’impact en cas de compromission. Par exemple, une clé dédiée pour le bastion de rebond et une autre pour les serveurs cibles renforce l’isolement logique et facilite aussi la gestion et la rotation des clés.

Configuration SSH pour passer par un Bastion

Sécuriser l'accès à ses serveurs avec un Bastion

Un bastion (ou serveur de rebond ou Jump Host) est un serveur durci (très sécurisé) positionné à la frontière entre un réseau public et un réseau privé, servant de point d'entrée unique et contrôlé vers l'infrastructure interne.
Son rôle principal est de centraliser, sécuriser et auditer les accès en réduisant la surface d'attaque : au lieu d'exposer directement chaque serveur interne, seul le bastion est accessible depuis l'extérieur.

Le bastion remplit plusieurs fonctions de sécurité :

• Authentification centralisée : vérification des identités avant tout accès au réseau interne
• Traçabilité : journalisation de toutes les connexions et actions administratives
• Isolation : séparation physique ou logique entre les zones de confiance différentes
• Contrôle d'accès granulaire : filtrage des connexions selon les règles de sécurité définies

Le bastion ne porte généralement aucun autre service que SSH, ce qui permet de le désactiver rapidement sans impacter les applications en production. Cette approche limite drastiquement les vecteurs d'attaque possibles tout en conservant la capacité d'administrer l'infrastructure lorsque nécessaire

Utiliser 2 pairs de clés SSH

L’idée est d'avoir 1 clé pour atteindre le bastion par lequel on va rebondir, et 1 clé pour atteindre le serveur de destination.

Laisser le fichier ~/.ssh/config (ou équivalent sous Windows) diriger automatiquement vers la bonne clé selon la cible.

Sur les trois OS, le fichier de configuration .ssh/config est quasiment le même en contenu, seul le chemin de fichier change.

~/.ssh/config sous Linux

# Clé dédiée pour le bastion
Host bastion
    HostName bastion.example.com
    User monuser
    IdentityFile ~/.ssh/bastion
    IdentitiesOnly yes

# Clé dédiée pour les serveurs derrière le bastion
Host srv-*
    User monuser
    IdentityFile ~/.ssh/server
    IdentitiesOnly yes
    ProxyJump bastion

• Host bastion : définit l’alias utilisé avec ssh bastion.
• Host srv-* : couvre par exemple ssh srv-app1, ssh srv-db1, etc.
• ProxyJump bastion : utilise le bastion précédemment défini comme rebond automatique.

~/.ssh/config sous macOS

Sous macOS, le principe est identique, avec éventuellement l’intégration au trousseau (avec AddKeysToAgent yes et UseKeychain yes).

# Bastion
Host bastion
    HostName bastion.example.com
    User monuser
    IdentityFile ~/.ssh/bastion
    IdentitiesOnly yes
    AddKeysToAgent yes
    UseKeychain yes

# Serveurs derrière le bastion
Host srv-*
    User monuser
    IdentityFile ~/.ssh/server
    IdentitiesOnly yes
    AddKeysToAgent yes
    UseKeychain yes
    ProxyJump bastion

.ssh\config sous Windows

Sous Windows (OpenSSH intégré), le fichier de configuration se trouve en général dans %USERPROFILE%\.ssh\config. Le contenu est le même, seuls les chemins changent.

# Bastion
Host bastion
    HostName bastion.example.com
    User monuser
    IdentityFile C:\Users\MonUser\.ssh\bastion
    IdentitiesOnly yes

# Serveurs derrière le bastion
Host srv-*
    User monuser
    IdentityFile C:\Users\MonUser\.ssh\server
    IdentitiesOnly yes
    ProxyJump bastion

• IdentityFile pointe ici vers les chemins Windows complets.
• IdentitiesOnly yes force l’usage uniquement de la clé spécifiée, ce qui évite les fuites d’autres clés chargées dans l’agent.

Bonnes pratiques avec plusieurs clés en entreprise

• Définir 1 clé par contexte sensible (bastion, prod, pré-prod, etc.).
• Ne jamais réutiliser la clé du bastion pour les serveurs cibles. Cela permet notamment d'effectuer des rotations de la clé de bastion fréquemment.
• Coupler ces clés avec ssh-agent et des passphrases fortes pour garder le confort d’usage sans sacrifier la sécurité.