La promesse d’une IA pirate anonyme “sans compte, sans JavaScript, sans traces” peut sembler séduisante. Mais quand on regarde de près ce que le service permet réellement de produire, la confidentialité devient surtout un accélérateur de risque.
Une IA présentée comme “privée” et sans garde-fous
Le service testé par ZATAZ, baptisé DONG (pseudonyme), revendique une utilisation sans informations personnelles. Il ne demande pas de compte classique et annonce que les requêtes seraient exécutées hors ligne, directement sur le matériel de l’opérateur. L’identification reposerait sur un jeton, au format “DONGxxxxxx”, à conserver pour retrouver ses conversations.
Sur le papier, l’idée est claire : réduire les données persistantes et limiter les liens directs entre une identité civile et l’usage. L’historique pourrait aussi être effacé à tout moment, et les comptes supprimés après trois mois d’inactivité.
Jeton stylisé et bouclier barré pour illustrer l’absence de garde-fous d’une IA pirate anonyme
Le vrai sujet : ce que l’IA laisse faire
Le point le plus préoccupant concerne les capacités de génération observées pendant les tests. Là où une IA “grand public” applique généralement des garde-fous, DONG semble au contraire laisser passer des usages manifestement problématiques (ZATAZ cite notamment la génération de contenus sexuels extrêmes et la création d’un outil de type “info-stealer”).
Monétisation et orientation “blackmarket”
Autre signal : un modèle commercial avec des bandeaux publicitaires, facturés 1 000 $ par mois, qui renverraient vers des services pirates et des offres de blackmarket. Autrement dit, la confidentialité revendiquée ne sert pas seulement à “protéger l’utilisateur” : elle peut aussi faciliter l’écosystème.
Ce qu’on doit retenir (et surveiller)
Moins de traces ≠ moins de risques.
“Zéro filtre” est un drapeau rouge, surtout pour la génération de contenus.
La monétisation via la publicité peut indiquer une finalité d’audience.
Dans la veille cyber, ce type d’outil mérite une attention particulière : la promesse d’anonymat ne remplace pas l’évaluation des garde-fous et des usages réels. Prochaine étape : vérifier comment ces services évoluent et quels nouveaux mécanismes de contrôle (ou d’absence de contrôle) apparaissent.
Quand on se lance dans le self-hosting, on finit toujours par taper la même commande : ssh-keygen, Entrée trois fois, et hop… ça marche. Sauf que tes clés SSH ne sont pas un détail : ce sont littéralement les clés d’accès à tes serveurs. Et si tu les fabriques ou les organises mal, tu passes très vite de « un fichier volé » à « un accès permanent à tout ton parc ».
Dans ce guide, je te donne la méthode que j’applique sur mon homelab : bon format, bonne commande, passphrase obligatoire, organisation par usages, et ssh-agent bien configuré. Pas de théorie inutile : juste des décisions concrètes qui réduisent le risque.
1) Le bon format en 2026 : Ed25519, point
Si tu ne dois retenir qu’une chose : génère tes clés en Ed25519. La commande minimale est :
ssh-keygen -t ed25519
Pourquoi je pousse Ed25519 ? Parce que c’est un choix moderne, efficace et robuste dans l’écosystème OpenSSH. Et surtout : c’est le format que tu veux standardiser dans ton homelab, pour éviter les exceptions et les “ça marche chez moi” qui finissent par coûter cher.
Ce que tu évites
DSA : obsolète, à oublier.
ECDSA : acceptable en théorie, mais je préfère éviter les compromis et rester sur Ed25519.
RSA : utile uniquement pour l’interop avec un vieux système. Sinon, tu perds du temps à gérer un héritage.
Commande ssh-keygen en Ed25519 avec indicateurs de sécurité
2) La commande idéale, décortiquée
Voici la ligne que j’utilise et que je te recommande d’adopter comme standard :
ssh-keygen -t ed25519 -a 100 -C "moi@mon-pc" -f ~/.ssh/id_ed25519_mon_pc
Chaque option a un rôle. Et c’est précisément là que beaucoup de gens “génèrent n’importe comment” : ils laissent des valeurs par défaut sans comprendre ce qu’elles protègent.
-t ed25519 : le type de clé
On l’a vu : c’est ton standard. Pas de débat.
-a 100 : le blindage du fichier au repos
Ta clé privée n’est pas stockée en clair si tu mets une passphrase. Elle est chiffrée, et -a règle le coût de dérivation de la clé de chiffrement (KDF). Plus tu augmentes ce coût, plus un attaquant qui vole le fichier doit “payer” du temps pour tester des passphrases.
En pratique, 100 est un bon compromis : tu ne le sens presque pas à l’usage (une fois au déverrouillage), mais tu rends les essais beaucoup plus coûteux pour un attaquant.
Point important :-a ne sert à rien si tu ne mets pas de passphrase. Donc on enchaîne.
-C : un commentaire utile
Le commentaire (moi@mon-pc) n’ajoute pas de sécurité cryptographique. Mais il te sauve la vie quand tu retrouves une clé dans un authorized_keys six mois plus tard : tu sais à quoi elle correspond.
-f : le nom explicite qui évite le chaos
Le chemin de sortie (~/.ssh/id_ed25519_mon_pc) n’est pas qu’un détail. C’est l’organisation qui te permet de savoir quelle clé est où, et de révoquer vite quand une machine change.
Ce que je ne fais jamais : -N
Je ne passe jamais la passphrase en argument avec -N. Elle finirait dans l’historique de ton shell ou dans des logs. Tu la tapes au prompt, c’est plus sûr.
3) Passphrase obligatoire (et comment ne pas la rendre pénible)
Une clé SSH sans passphrase, c’est une clé privée qui peut ouvrir tes serveurs et qui traîne sur ton disque. Si un jour ta machine est compromise, la “sécurité au repos” disparaît.
Ma règle : toujours une passphrase forte. Et ensuite, on gère le confort avec ssh-agent.
Une clé SSH ne s’expire pas : attention aux clés oubliées dans authorized_keys
4) Le piège : une clé SSH n’expire jamais
Contrairement à un certificat TLS, une paire de clés SSH “classique” n’a pas de date de validité. Une fois que ta clé publique est dans authorized_keys, elle fonctionne indéfiniment jusqu’à ce que tu la retires.
Le vrai danger en homelab, ce n’est pas “la clé trop vieille”. C’est la clé oubliée : un ancien laptop revendu, une VM réinstallée, un téléphone perdu… et pourtant l’accès reste valide parce que personne n’a fait le ménage.
Deux solutions réalistes
Rotation manuelle : tu régénères tes paires périodiquement (par exemple une fois par an) et tu remplaces les clés publiques sur tes serveurs.
Certificats SSH : tu utilises une CA et des certificats avec une fenêtre de validité. Quand ça expire, le serveur refuse automatiquement.
Mon avis : pour un petit parc (un VPS + un NAS), monter une PKI complète peut être disproportionné. Mais dès que tu passes à plusieurs machines, l’approche certificats devient intéressante. Dans tous les cas, garde en tête une règle : audit régulier de qui a accès à quoi.
5) Combien de clés ? et combien de passphrases ?
On confond souvent deux décisions différentes : le nombre de clés et le nombre de passphrases. Elles ne répondent pas aux mêmes objectifs.
“Une clé par usage” ≠ “une clé par serveur”
Le bon découpage, ce n’est pas la destination (VPS, NAS, etc.). C’est le point de départ : quelle machine cliente et quel contexte.
Exemple de découpage sain :
PC → id_ed25519_pc (ouvre VPS, NAS, etc.)
Laptop → id_ed25519_laptop (ouvre VPS, NAS, etc.)
PC → id_ed25519_github (dédiée aux services tiers)
Pourquoi une clé dédiée pour GitHub / services tiers ? Parce que tu confies la clé publique à un tiers. Autant qu’elle ne soit pas réutilisée pour tes accès “maison”.
Une passphrase par machine (pas par clé)
La passphrase sert à protéger un fichier de clé privée volé. Si plusieurs clés vivent sur la même machine et partagent la même passphrase, un attaquant qui accède au disque pourra tenter cette passphrase pour toutes.
Mon conseil pragmatique : une passphrase forte et unique par machine cliente. Toutes les clés générées sur ce poste peuvent partager cette passphrase.
Deux exceptions où tu cloisonnes plus
Clé tierce (GitHub / services) : passphrase distincte si tu veux renforcer l’isolation.
Clé matérielle (ex. ed25519-sk) pour ton accès le plus sensible : la partie secrète ne peut pas être copiée depuis le disque. Là, la passphrase devient presque secondaire, parce que voler le fichier ne suffit plus.
6) ssh-agent : le confort sans sacrifier la sécurité
“Taper une passphrase à chaque connexion, c’est infernal.” Oui. Mais justement : on ne le fait pas. ssh-agent garde tes clés déchiffrées en mémoire le temps de la session.
Le but : tu tapes la passphrase une fois, puis tu enchaînes tes connexions sans friction.
ssh-agent garde les clés en mémoire pour éviter de retaper la passphrase
Résultat : à la première utilisation, SSH charge la clé dans l’agent. Ensuite, tu ne retapes pas la passphrase tant que l’agent vit.
Évite les mauvaises surprises : IdentitiesOnly yes
Quand tu as plusieurs clés, SSH peut essayer “trop de choses” et provoquer des refus côté serveur. Pour forcer la clé attendue, je recommande :
Host mon_serveur
HostName ton.ip.ou.domaine
User user_distant
IdentityFile ~/.ssh/id_ed25519_mon_pc
IdentitiesOnly yes
7) Bien gérer ssh-agent selon ton OS
Le problème n’est pas ssh-agent. Le problème, c’est le démarrage. Beaucoup de gens lancent ssh-add alors qu’aucun agent ne tourne, ou alors ils démarrent un agent sans appliquer les variables d’environnement.
Windows : l’agent persiste (souvent le plus simple)
Sur Windows, le service OpenSSH agent peut être configuré pour démarrer automatiquement. Ensuite, tu charges tes clés une fois, et elles reviennent après reboot.
Sur certaines configurations desktop, d’autres composants peuvent aussi gérer un agent. L’idée est de garder un contrôle clair sur “qui lance quoi”.
Mode ponctuel : le eval est obligatoire
Pour une tâche isolée, tu peux lancer un agent “jetable” dans ton terminal. Mais fais-le correctement :
eval "$(ssh-agent -s)"
Le eval applique les variables d’environnement dans ton shell courant. Sans ça, ton shell ne sait pas où joindre l’agent, et ssh-add échoue.
Arrêter proprement
Si tu as lancé l’agent proprement, tu peux le tuer avec :
ssh-agent -k
Si tu as lancé sans eval, tu peux te retrouver avec un agent qui tourne “dans le flou”. Dans ce cas, un nettoyage global peut être nécessaire :
pkill -u "$USER" ssh-agent
8) Sécurité ssh-agent : les deux réglages que je fais toujours
ssh-agent est pratique, mais il garde des clés déchiffrées en mémoire. Donc je limite l’exposition.
Timeout sur les clés sensibles
Tu peux demander à l’agent de purger une clé après un délai :
ssh-add -t 8h ~/.ssh/id_ed25519_mon_pc
Tu peux aussi mettre un comportement par défaut dans la config pour éviter les oublis.
Forwarding d’agent : prudence
Le forwarding d’agent (ForwardAgent yes ou ssh -A) permet au serveur distant d’utiliser ton agent pour rebondir ailleurs. C’est pratique, mais si le serveur est compromis, l’attaquant profite de ton agent tant que tu es connecté.
Je préfère une approche plus maîtrisée : ProxyJump pour le rebond, plutôt que le forwarding d’agent.
Nombre de clés : peu. Une par machine cliente, plus une dédiée aux services tiers.
Passphrases : une par machine (et éventuellement une distincte pour la clé tierce).
Confort : AddKeysToAgent yes + IdentitiesOnly yes quand nécessaire.
Rotation / nettoyage : les clés n’expirent pas, donc tu fais un audit et tu révoques vite.
Accès sensible : clé matérielle si tu veux le cran au-dessus.
Conclusion : reprendre le contrôle de tes accès
Les clés SSH ne sont pas un “détail de configuration”. Ce sont tes serrures. Et une serrure mal gérée, c’est un accès facile à long terme.
Si tu appliques cette méthode—Ed25519, passphrase, organisation claire, ssh-agent propre et audit régulier—tu réduis drastiquement le risque, tout en gardant un homelab fluide. La prochaine étape logique ? Faire l’inventaire de tes authorized_keys et vérifier que chaque clé correspond encore à une machine que tu contrôles.
L’ANSSI, agence nationale de la sécurité des systèmes d’information, propose régulièrement des fiches, bonnes pratiques, rappels sur les usages et précautions à prendre dans l’informatique.
Le hacking légal existe, il est possible soit en s’entraînant par le biais de machines virtuelles mises à disposition pour cibler une particularité comme https://www.vulnhub.com/, ou des sites qui mettent en place des challenges comme https://www.root-me.org/, ou soit par des plateformes de recherche de failles dites bug bounty que des entreprises peuvent utiliser pour vérifier leur sécurité contre rémunération, la plus connue en France https://bountyfactory.io/.
Si la sécurité informatique vous intéresse, il est obligatoire de passer par là, vous vous amuserez à mieux comprendre comment cela fonctionne, et pas de risque de voir monsieur le gendarme sonner chez vous à 6h du matin.
Et impossible de parler sécurité sans faire un peu de pub pour la communauté ZenK-Security.
Les générateurs de mots de passe et outils complets ont le vent en poupe.
Cependant un chercheur s’est amusé à les comparer selon différents critères et nous a établi ce rapport. Il montre les différentes solutions, compare les licences, protocoles, tout ça réunit dans un beau tableau.
A noter également qu’il fait de la publicité pour son générateur de mot de passe, qu’il est toujours bon d’avoir sous la main pour complexifier les attaques par dictionnaire ou bruteforce.
Et on n’oublie pas, un mot de passe différent par site, il doit être unique pour éviter de tout perdre en même temps !
Le passeport de conseils aux voyageurs vous présentera les principes de base, mais à appliquer pour vous prémunir de difficultés pendant un déplacement, et un rappel des bonnes pratiques pour bien comprendre par exemple que les mises à jour ne sont pas facultatives mais permettent de prévenir à certaines attaques.
Voilà, il n’y a pas d’âge pour se consacrer à la sécurité informatique.
Un enfant de 10 ans qui a trouvé une faille sur Instagram s’est vu remettre par Facebook la récompense prévue. J’ai toujours de la fascination pour ces jeunes enfants surdoués de la sécurité quand on sait quelle difficulté cela représente de trouver ce genre de faille.
En tombant sur l’article de Korben qui présente les services de Lavaboom (qui se veut l’héritier de Lavabit, un service de mail sécurisé, c’est-à-dire que toutes vos données sont chiffrées sur le serveur et donc seul vous y avez accès avec vos moyens d’authentification), j’ai poussé la curiosité à voir quels étaient justement les moyens d’authentification au nombre de 3 dans la version payante.
Le moyen supplémentaire dans la version payante (en plus de l’utilisation d’un mot de passe et d’un couple de clé privée/publique pour la version gratuite) est l’utilisation d’une clé matérielle USB YubiKey. Cette clé vous fournit un jeton OTP (one time password, mot de passe unique qui devient inutilisable après son utilisation) que vous fournissez lors de l’authentification. L’idée est plutôt sympa, pas forcément excessive, et nécessite donc l’usage d’une clé matérielle pour vous authentifier, au cas où une personne malveillante aurait récupéré votre mot de passe et votre clé privée.
Ce site met en place un exemple d’utilisation pour se connecter à sa machine Linux, technique que je vous invite à aller visiter pour bien comprendre le principe et son usage.
On peut d’ailleurs imaginer son utilisation en entreprise pour que les salariés se connectent au serveur, ou au réseau, je pense que les possibilités sont assez nombreuses et qu’il est possible de s’amuser avec.
