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.