1.8 KiB
1.8 KiB
title, created, updated, type, tags, confidence, contested, sources
| title | created | updated | type | tags | confidence | contested | sources | ||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Clés SSH | 2026-06-06 | 2026-06-06 | concept |
|
high | false |
|
🔑 Clés SSH
Définition Courte
Paire de clés cryptographiques (une privée gardée secrète, une publique partagée) utilisée pour l'authentification forte à un serveur SSH, en remplacement des mots de passe.
Explication Détaillée
Algorithmes recommandés en 2024+ :
- Ed25519 : moderne, rapide, signatures courtes. Recommandé par défaut.
- ECDSA (NIST P-256) : alternative, bien supportée.
- RSA 4096 bits : toujours sûr, mais plus lent.
- DSA : cassé, à ne plus utiliser.
Workflow :
- Génération :
ssh-keygen -t ed25519 -C "commentaire". - Déploiement :
ssh-copy-id user@serveur(ou via~/.ssh/authorized_keys). - Connexion : le serveur challenge avec un truc que seule la clé privée peut signer.
Concepts avancés :
- passphrase : protection supplémentaire de la clé privée.
- ssh-agent : déverrouille la clé en mémoire pour la session.
- agent forwarding : permet de rebondir via plusieurs serveurs.
- AuthorizedKeysCommand : gestion centralisée (LDAP, Vault).
Cas d'Usage
- Accès SSH à un VPS.
- Authentification Git (GitHub, GitLab).
- Déploiement CI/CD (clés de déploiement).
- Backup automatisé (rsync via SSH).
Outils Liés
- OpenSSH (cf. openssh).
- 1Password / Bitwarden : gestion moderne des clés.
- HashiCorp Vault SSH : rotation automatique.
Pages Liées
Questions Ouvertes
- Faut-il adopter massivement les passkeys au détriment des clés SSH ?
- Comment gérer les clés SSH dans une équipe de 10+ devs sans Vault ?