Comprendre ~/.ssh/authorized_keys : la base oubliée qui révèle la maturité d’un ingénieur IAM
Chez Ariovis, il existe une question récurrente posée à
chaque candidat ayant « Linux » dans son CV :
« Peux-tu m’expliquer ce qu’on met dans ~/.ssh/authorized_keys ? »
Nous la posons systématiquement. Pas pour piéger. Pas pour
faire du tri élitiste.
Nous la posons parce que cette seule question révèle si un candidat maîtrise ou
non le principe fondamental de toute authentification moderne : le
chiffrement asymétrique.
Et, étonnamment, 95 % des candidats se trompent :
confusion entre clés privées et publiques, mélange chiffrement et signature, ou
impossibilité d’expliquer le rôle du fichier.
Or comprendre ce mécanisme, ce n’est pas un point de détail.
C’est la base de ce qui gouverne aujourd’hui l’authentification :
- les
certificats, - la
PKI, - les
passkeys, - l’authentification
machine-à-machine, - le
Wi-Fi d’entreprise, - les
jonctions sécurisées entre services, - et
demain, toutes les authentifications sans mot de passe.
Ariovis en est convaincu : tout ingénieur identité doit
maîtriser Alice, Bob, leur clé publique, leur clé privée, et ce qui se passe
dans authorized_keys.
authorized_keys
: la porte d’entrée de l’authentification asymétrique
Le fichier ~/.ssh/authorized_keys, côté serveur, contient des
clés publiques.
Rien d’autre.
Lorsqu’un utilisateur se connecte en SSH, le serveur
consulte ce fichier pour vérifier :
« Est-ce que la clé publique correspondant à ce que tente de
prouver le client figure ici ? »
Si oui, le serveur défie le client en lui envoyant
une donnée à signer.
Seul celui qui possède la clé privée pourra produire une signature
valide.
En résumé :
- clé
publique → publiée, distribuée, placée dans authorized_keys - clé
privée → secrète, jamais transmise, jamais copiée, jamais diffusée
Le serveur ne voit jamais la clé privée.
Il reçoit une preuve mathématique que le client la détient.
C’est tout.
Mais tout repose là-dessus.
Pourquoi
cette question dit tout du niveau d’un ingénieur IAM
Si un candidat ne sait pas répondre clairement, cela signale
immédiatement :
- Une
incompréhension sur la séparation public/privé
→ Confusion classique : “on met la clé privée sur le serveur” (50% de nos
entretiens). - Une
méconnaissance du rôle du défi-réponse cryptographique
→ Le mécanisme derrière SSH, mais aussi derrière TLS ou WebAuthn. - Un
manque de maturité sur les concepts de base de la PKI
→ Or la PKI est le squelette de la cybersécurité moderne. - Une
incapacité à visualiser la chaîne de confiance
→ Indispensable pour juger de la qualité d’une architecture IAM.
Cette question simple permet à Ariovis de détecter non
seulement des compétences techniques, mais aussi la capacité à raisonner
dans un modèle de sécurité asymétrique — une qualité essentielle dans l’IAM
contemporain.
Ces
concepts gouvernent tout ce qui compte aujourd’hui dans l’IAM
✔ Passkeys / FIDO2
Le client stocke une clé privée dans le Secure Enclave.
Le serveur stocke une clé publique et vérifie une signature.
C’est le même modèle que SSH.
✔ Authentification machine à
machine
API, micro-services, containers : échanges de certificats,
vérification de signatures.
Le même mécanisme, simplement encapsulé dans TLS.
✔ PKI interne d’entreprise
Certificats utilisateurs, machines, serveurs : rien d’autre
que des paires public/privé correctement distribuées et validées.
Il est paradoxal de voir que la PKI reste un “gros mot”
dans certaines équipes infrastructure, alors qu’elle est littéralement au cœur
de tout ce qu’elles manipulent.
À Ariovis, nous voulons contribuer à lever ce malentendu.
Pourquoi
les ingénieurs IAM ne peuvent plus ignorer Alice et Bob
Depuis vingt ans, les écoles d’ingénieurs enseignent Alice,
Bob, clé publique, clé privée.
Mais dans la pratique, trop de jeunes (et moins jeunes) ingénieurs n’ont jamais
appliqué réellement ce modèle.
Pour un ingénieur IAM, c’est impossible aujourd’hui :
- Impossible
de concevoir une architecture sans comprendre les échanges de certificats. - Impossible
d’évaluer la sécurité d’un protocole sans saisir le modèle défi-réponse. - Impossible
de parler de Zero Trust sans maîtriser la signature cryptographique. - Impossible
de travailler sur les passkeys, le phishing-resistant MFA ou les tokens
OAuth signés sans comprendre ce qui se joue derrière.
authorized_keys est un prétexte.
Mais c’est le bon : simple, concret, immédiat.
Si vous comprenez authorized_keys, vous êtes capable de
comprendre FIDO2, JWT, TLS, S/MIME, SSH, SCIM signé, OAuth token binding…
Bref : tout ce que l’IAM moderne exige, la base même du passwordless.
Ce que Ariovis attend comme réponse en entretien
Une réponse claire ressemble à ceci :
« Dans ~/.ssh/authorized_keys, on place la clé publique
autorisée à se connecter.
Le serveur utilise cette clé publique pour vérifier que le client possède bien
la clé privée correspondante, via un mécanisme de signature.
C’est de l’authentification asymétrique : la clé privée reste toujours côté
client. »
L’entretien peut alors aller plus loin :
- Pourquoi
n’envoie-t-on jamais une clé privée ? - Comment
marche le défi-réponse ? - Qu’est-ce
qui empêche un acteur malveillant d’intercepter la session ? - Comment
protège-t-on la clé privée sur un laptop ?
Ces questions ne sont pas là pour “faire briller”.
Elles sont là pour valider que la personne comprend la colonne vertébrale de
l’identité numérique.
Conclusion : maîtriser la base pour comprendre l’avenir
Chez Ariovis, la conviction est simple :
sans compréhension solide du chiffrement asymétrique, impossible de
comprendre l’IAM moderne. Impossible de parler passwordless.
authorized_keys n’est qu’un petit fichier texte.
Mais il représente le point d’entrée vers :
- les
passkeys, - l’authentification
sans mot de passe, - la
PKI d’entreprise, - la
signature des tokens OAuth, - la
sécurité des API, - l’authentification
machine, - les
architectures Zero Trust.
C’est un sujet de base.
C’est un sujet d’avenir.
Et c’est un sujet que toute organisation doit intégrer dans sa culture
technique.
Ariovis continuera à le rappeler :
Comprendre Alice et Bob, ce n’est pas facultatif. C’est le socle de tout.