Générer un mot de passe pour SSH, API ou serveur dev en 2026 : longueur, entropie, automatisation

Un mot de passe SSH ou une clé API n’est pas un mot de passe de site grand public : il est rarement saisi à la main, souvent automatisé, et protège un accès dont la compromission peut coûter une infrastructure entière. Ce guide donne la longueur cible, l’alphabet à privilégier, et la méthode pour générer ces secrets côté client puis les injecter dans votre flux dev sans jamais les coller dans un terminal partagé.

La règle 128 bits

Pour tout secret « machine » (mot de passe SSH non-clé, clé API symétrique, mot de passe root serveur, secret JWT) : viser 128 bits d’entropie minimum. C’est le seuil au-dessus duquel la force brute brute n’a plus de sens même contre un attaquant État, pour les 30 prochaines années.

Pourquoi 128 bits et pas 80 ?

Un secret machine n’a pas la contrainte de mémorisation d’un mot de passe humain. Vous ne le tapez jamais. Le seul coût marginal de passer de 80 à 128 bits est zéro.
Les secrets machines sont souvent stockés longtemps (config server qui reste 3 à 5 ans). 80 bits aujourd’hui peuvent devenir cassables dans 10 ans.
En cas de fuite par log accidentel, l’attaquant a parfois des semaines ou des mois pour cracker. 128 bits restent hors d’atteinte.

Type d’usage	Entropie cible	Caractères équivalents (alphabet 95)	Caractères équivalents (alphabet 64 base64)
Mot de passe humain (mémorisé)	64-80 bits	10-13	11-14
Mot de passe SSH non-clé	128 bits	20	22
Clé API symétrique	128 bits	20	22
Secret JWT, cookie de session	256 bits	40	43
Clé de chiffrement long terme	256 bits	40	43

Alphabet : 95 caractères ASCII vs 64 base64 vs 16 hex

Le choix de l’alphabet a une incidence directe sur la longueur et la robustesse à la copie.

Alphabet 95 — ASCII imprimables complet

Inclut majuscules, minuscules, chiffres et tous symboles ASCII (!"#$%&'()*+,-./:;<=>?@[\]^_\{|}~`). 6,57 bits/caractère.

Avantage : densité d’entropie maximale, longueur minimale.
Inconvénient : certains symboles cassent les fichiers de config ($, &, \, ', " mal échappés). Risque de bug shell quand on met un mot de passe en variable d’environnement non quotée.

Notre générateur côté client propose un mode « ASCII complet » et un mode « ASCII safe-shell » qui exclut les caractères problématiques (', ", \, $, `, ;, espaces).

Alphabet 64 — Base64 URL-safe

Lettres + chiffres + - et _. 6,00 bits/caractère.

Avantage : aucun caractère spécial à échapper, transit propre dans URLs, fichiers de config, variables d’env. Choix par défaut pour les clés API et tokens.
Inconvénient : 9 % moins dense qu’alphabet 95 (mais on s’en fiche pour un secret machine).

Alphabet 16 — Hexadécimal

0-9a-f. 4 bits/caractère.

Avantage : universel, jamais d’échappement, lisible humainement, copiable sans erreur.
Inconvénient : 39 % moins dense. Un secret 128 bits = 32 caractères hex. Acceptable pour les clés où la longueur n’est pas un problème.

Recommandation par usage

Secret	Alphabet recommandé	Longueur 128 bits
Mot de passe SSH non-clé	ASCII safe-shell (90 chars)	20 caractères
API key client public	base64 URL-safe (64)	22 caractères
Secret JWT signing	base64 URL-safe (64)	43 caractères (256 bits)
Clé de chiffrement at-rest	hex (16)	64 caractères (256 bits)
Mot de passe root sur VM	ASCII safe-shell (90)	20 caractères

Méthode : générer côté client puis injecter sans terminal partagé

L’erreur classique du dev pressé : générer un secret avec openssl rand -base64 24 dans un shell partagé (tmux session enregistrée, écran partagé Zoom, machine de bureau avec lignecmd visible). Le secret est exposé.

La méthode propre 2026 :

1. Générer dans le navigateur

Ouvrez le générateur de mot de passe, sélectionnez « ASCII safe-shell » ou « base64 URL-safe » selon le cas, longueur 20-22, cliquez « Générer ». Le secret est tiré par crypto.getRandomValues() du navigateur — la même primitive cryptographique qu’utilise OpenSSL, mais isolée dans l’onglet courant. Aucun upload, aucun log.

Voir pourquoi un générateur côté client est plus sûr.

2. Stocker dans un coffre

Ajoutez le secret à un coffre Bitwarden ou KeePass. Dans Bitwarden, créez un item « Secure note » (et non « login »), avec le serveur ou l’API en titre. Le coffre est chiffré localement avant synchro.

3. Injecter via Bitwarden CLI

C’est la pièce manquante des dev habituels : Bitwarden propose un CLI (bw) qui permet d’injecter un secret directement dans une variable d’environnement à l’exécution, sans jamais le coller dans le shell ni l’écrire dans ~/.zsh_history.

# Une seule fois, login
bw login

# Pour chaque session de travail, déverrouiller et exporter la session
export BW_SESSION=$(bw unlock --raw)

# Récupérer un secret par son nom et l'injecter
export DB_PASSWORD=$(bw get password "prod-db-master")
psql -h prod-db.example.com -U app

Avantages :

Le secret n’apparaît jamais en clair dans le shell ou l’historique.
Si vous fermez le terminal sans bw lock, la session BW reste valide jusqu’à expiration (configurable, défaut 5 min). Verrouillage automatique en fin de session.
L’audit Bitwarden trace chaque accès au secret.

4. Pour une CI/CD : passer par un secret manager dédié

bw est parfait pour le poste dev, pas pour la prod. En CI/CD :

GitLab / GitHub Secrets pour les secrets liés au pipeline.
HashiCorp Vault ou AWS Secrets Manager pour les secrets long terme avec rotation.
doppler.com ou infisical.com pour une approche SaaS centralisée.

Le générateur côté client reste utile pour le bootstrap initial : générer la première fois la clé API qui sera ensuite stockée dans le secret manager.

Cas particuliers

Mot de passe SSH avec clé publique

Si vous utilisez SSH avec clé publique (ssh-keygen -t ed25519), votre clé privée est protégée par une passphrase. Cette passphrase est saisie à la main au déverrouillage de la clé — elle a donc la contrainte de mémorisation d’un mot de passe humain.

Recommandation : passphrase Diceware 6 mots (77 bits). Voir Diceware combien de mots.
Stocker la passphrase dans le coffre Bitwarden « Secure note » liée à la clé.
Charger la clé via ssh-add au début de session pour ne pas resaisir.

Clé API tierce (Stripe, GitHub, OpenAI)

Vous ne générez pas ces clés vous-même : le service les génère pour vous, à 256 bits déjà bien forme. Votre travail est juste de les stocker proprement :

Coffre Bitwarden « Secure note » avec un nom explicite (Stripe live secret key).
Tag « production » pour distinguer des clés de test.
Régénérer la clé tous les 90 jours si le service le permet (Stripe, OpenAI).
Surveiller les fuites GitHub via Bitwarden / GitHub Secret Scanning.

Mot de passe d’un fichier 7zip ou VeraCrypt

Vous le saisissez à la main au déchiffrement. C’est un cas humain, pas machine. Recommandation : passphrase Diceware 7 mots (90 bits) — robuste contre brute force, mémorisable, saisie acceptable une fois par jour.

Token de session courte durée (cookies, JWT)

Généré côté serveur, jamais côté client. Le générateur côté client est non-pertinent pour ce cas — utilisez la primitive crypto du framework backend (crypto.randomBytes(32) en Node, secrets.token_urlsafe(32) en Python).

Anti-patterns dev qui exposent des secrets

Coller un secret dans un commit (« merge il faudra que je l’enlève »). Le secret reste dans l’historique git pour toujours, même après git revert. À traiter par git filter-repo ou rotation immédiate du secret.
Stocker le secret dans .env poussé sur GitHub. .env doit toujours être dans .gitignore. En cas d’accident : rotation immédiate.
Utiliser un secret faible « pour le dev » sans le rotater avant la prod. La promotion dev → prod transforme un secret faible en mot de passe production exposé.
Réutiliser le même secret entre dev et prod. Une fuite dev compromet la prod.
Secret en argument de ligne de commande : visible via ps aux. Toujours passer les secrets par variable d’environnement, jamais en argument.
Logger les secrets accidentellement (console.log(req.headers)). Auditer les logs pour les patterns Authorization:, api_key=, Bearer.

FAQ

`openssl rand -base64 32` est-il aussi sûr qu’un générateur côté client navigateur ?

Oui, à condition que /dev/urandom soit propre sur la machine (pas de container nouvellement créé sans entropie). Le générateur côté client ajoute un avantage UX : pas besoin d’avoir OpenSSL installé, sortie directe dans le presse-papier, mode safe-shell intégré pour exclure les caractères problématiques.

Puis-je utiliser le même mot de passe pour 5 serveurs « identiques » de la même infra ?

Non. Un par serveur. La compromission d’un (par fuite log, ou par employé partant) ne doit jamais propager. Bitwarden CLI permet de gérer 50 secrets distincts sans friction de saisie.

Combien de temps un secret API doit-il rester valide ?

Pour un secret long terme (clé root): rotation manuelle annuelle. Pour un secret applicatif (clé API service-to-service) : 90 jours typiques. Pour un token de session : 1 heure (refresh token longue durée). La règle : plus le périmètre est large, plus la rotation doit être fréquente.

Faut-il chiffrer le coffre Bitwarden avec un mot de passe maître spécial pour les secrets dev ?

Pas un mot de passe distinct, mais le mot de passe maître général doit être à 7 mots Diceware minimum si vous y stockez des secrets infra critiques. Activer 2FA matériel (YubiKey) sur le compte Bitwarden.

Les passkeys remplacent-elles les mots de passe SSH ?

Pas encore en 2026. Les passkeys ciblent l’authentification web utilisateur. Pour SSH, la clé publique ed25519 reste la référence. Les hardware tokens (YubiKey en mode FIDO2 SSH) commencent à se déployer côté pro.

Ce qu’il faut retenir

Pour un secret machine en 2026 :

128 bits minimum, jamais moins.
Alphabet base64 URL-safe par défaut (compatibilité shell, URLs, configs), ASCII safe-shell pour les mots de passe SSH non-clé.
Génération côté client dans le navigateur (cf l’outil sur cette page) puis stockage immédiat dans un coffre chiffré (Bitwarden, KeePass).
Injection via Bitwarden CLI plutôt que copier-coller dans le terminal — zéro trace d’historique.
Rotation 90 jours pour les secrets applicatifs, annuelle pour les secrets root.

Pour aller plus loin sur le matériel qui exécute ce flux dev (smartphone, ordinateur, comparatifs hardware), lire le comparatif des smartphones 2026 — utile pour choisir un appareil avec gestion d’authentification matérielle propre.

Étape suivante : ouvrez le générateur de mot de passe côté client, passez en mode « base64 URL-safe » longueur 22, générez 3 secrets pour vos accès SSH/API du moment, transférez-les directement dans Bitwarden, puis configurez bw CLI sur votre poste pour les injecter sans jamais les coller au shell. Configuration en 15 minutes, sécurité gagnée pour des années.