Authentification SSH par clé et certificat

Quatre étapes : générer la clé ou le certificat → configurer l’équipement → téléverser dans le cloud → vérifier la connexion.

À propos de la configuration

Les exemples suivants peuvent être adaptés à des clés et autorisations existantes. Les fichiers générés sont enregistrés dans le répertoire courant. La plateforme ne délivre ni ne renouvelle automatiquement les certificats.

Prérequis : équipement activé, Online, avec OpenSSH Server en cours d’exécution ; configuration JelinaCloud par un Master ou Admin de flotte via HTTPS.

Étape 1 : générer une clé SSH ou un certificat utilisateur OpenSSH

Une connexion par clé nécessite uniquement une paire utilisateur. Une connexion par certificat exige de générer d’abord la paire utilisateur, puis de signer un certificat.

Générer une clé utilisateur

Créez et ouvrez un dossier vide, par exemple JelinaSSH, puis ouvrez le terminal correspondant à votre système :

Windows

Saisissez powershell dans la barre d’adresse du dossier, appuyez sur Entrée et exécutez :

ssh-keygen -t ed25519 -a 64 -f jelina_operator -C "JelinaCloud-operator"

Si la commande est introuvable, installez « Client OpenSSH » dans les fonctionnalités facultatives de Windows, puis rouvrez PowerShell.

Linux

Dans le dossier, faites un clic droit et choisissez « Ouvrir dans un terminal », puis exécutez :

ssh-keygen -t ed25519 -a 64 -f jelina_operator -C "JelinaCloud-operator"

Si la commande manque, installez le client OpenSSH : openssh-client sur Ubuntu/Debian, openssh-clients sur Fedora/RHEL.

À Enter passphrase, choisissez la phrase secrète, puis répétez-la à Enter same passphrase again. Aucun caractère n’est affiché. Pour une clé sans phrase secrète, appuyez deux fois sur Entrée. Si Overwrite (y/n)? apparaît, saisissez n pour conserver les fichiers existants.

Le dossier contient ensuite :

Fichier	Rôle et destination
jelina_operator, sans extension	Clé privée utilisateur pour la connexion ; à téléverser dans le champ de clé privée
jelina_operator.pub	Clé publique ; à ajouter à l’équipement pour l’authentification par clé ou à transmettre à la CA pour signature

Si l’équipement exige une clé RSA

Utilisez cette commande, identique sous Windows et Linux :

ssh-keygen -t rsa -b 3072 -a 64 -f jelina_operator_rsa -C "JelinaCloud-operator"

Elle génère jelina_operator_rsa et jelina_operator_rsa.pub. Utilisez ces noms dans la suite.

Signer un certificat utilisateur

Transmettez jelina_operator.pub à l’administrateur de votre CA. Pour signer vous-même, placez cette clé publique dans le répertoire courant de l’ordinateur de gestion et exécutez les commandes dans l’ordre.

Windows

1. Générez la paire de clés CA et choisissez sa phrase secrète. Si une CA existe déjà, sautez cette étape et utilisez ses fichiers réels.

ssh-keygen -t ed25519 -a 64 -f ca_ed25519 -C "JelinaCloud-customer-CA"

2. Signez le certificat utilisateur en fournissant la phrase secrète de la clé privée CA :

ssh-keygen -s ca_ed25519 -I operator-access-001 -z 1 -n ops-alice -V "-1m:+8h" jelina_operator.pub

Linux

1. Générez la paire de clés CA et choisissez sa phrase secrète. Si une CA existe déjà, sautez cette étape et utilisez ses fichiers réels.

ssh-keygen -t ed25519 -a 64 -f ca_ed25519 -C "JelinaCloud-customer-CA"

2. Signez le certificat utilisateur en fournissant la phrase secrète de la clé privée CA :

ssh-keygen -s ca_ed25519 -I operator-access-001 -z 1 -n ops-alice -V "-1m:+8h" jelina_operator.pub

Le message Signed user key confirme la réussite. Fichiers concernés :

Fichier	Rôle et destination
ca_ed25519	Clé privée CA de signature ; conservée uniquement par l’émetteur, jamais envoyée au cloud ni à l’équipement
ca_ed25519.pub	Clé publique CA à ajouter à l’équipement à l’étape 2 pour établir la confiance
jelina_operator-cert.pub	Certificat utilisateur à téléverser avec la clé privée utilisateur

Le principal de cet exemple est ops-alice, avec expiration après 8 heures. Vous pouvez remplacer -V "-1m:+8h" par -V "-1m:+7d" ou une autre durée limitée. L’émetteur attribue et consigne le numéro de série -z 1. Pour afficher le certificat :

ssh-keygen -L -f jelina_operator-cert.pub

Étape 2 : configurer l’équipement

Sur l’équipement JelinaOS Linux, modifiez authorized_keys du compte réellement utilisé. Cet exemple emploie operator ; remplacez-le par un compte existant :

Compte	Fichier d’autorisation
operator, répertoire personnel /home/operator	/home/operator/.ssh/authorized_keys
root	/root/.ssh/authorized_keys

Créez le fichier s’il n’existe pas. Le répertoire .ssh doit avoir les permissions 700, le fichier 600, et appartenir au compte cible. Conservez le contenu existant et ajoutez l’autorisation sur une nouvelle ligne à la fin. Il n’est pas nécessaire de copier le certificat sur l’équipement.

Clé SSH

Ouvrez jelina_operator.pub dans un éditeur de texte, copiez toute la ligne et ajoutez-la à la fin du fichier d’autorisation :

ssh-ed25519 <clé-publique-utilisateur-Base64> JelinaCloud-operator

Utilisez le contenu réel du fichier, pas l’espace réservé. Une clé RSA commence par ssh-rsa et doit également être copiée sur une ligne entière.

Certificat utilisateur OpenSSH

Ouvrez ca_ed25519.pub et copiez toute la ligne. À la fin du fichier d’autorisation, saisissez le préfixe suivant, ajoutez un espace puis collez la clé publique CA :

cert-authority,principals="ops-alice",no-agent-forwarding

Le résultat doit tenir sur une seule ligne :

cert-authority,principals="ops-alice",no-agent-forwarding ssh-ed25519 <clé-publique-CA-Base64> JelinaCloud-customer-CA

Remplacez l’espace réservé par la clé publique CA réelle. ops-alice doit correspondre à la valeur -n de la signature. L’équipement reçoit la clé publique CA et le préfixe d’autorisation ; le certificat utilisateur et sa clé privée seront envoyés au cloud à l’étape suivante.

Sous Windows, faites un clic droit sur la clé publique puis « Ouvrir avec → Bloc-notes ». Modifier uniquement authorized_keys ne nécessite généralement pas de redémarrer SSH. Un chemin personnalisé doit suivre la configuration de l’équipement.

Étape 3 : configurer JelinaCloud et téléverser les identifiants

Téléversement des identifiants

1. Ouvrez « Accès distants → Clés » de la flotte ou « Accès distants » de l’équipement, puis cliquez sur « Ajouter des identifiants SSH ».
2. Saisissez le nom et le compte système de l’équipement, par exemple operator ou root, choisissez le mode et téléversez les fichiers :

Mode	Fichiers à téléverser
Clé SSH	Champ clé privée : jelina_operator
Certificat utilisateur OpenSSH	Clé privée : jelina_operator ; certificat : jelina_operator-cert.pub

3. Si nécessaire, renseignez la phrase secrète de la clé privée utilisateur, choisissez les membres autorisés et l’élément par défaut, puis enregistrez.

Stockez les identifiants partagés dans la flotte et les identifiants dédiés dans l’équipement. Ne téléversez pas la clé privée CA. Après sauvegarde, confirmez l’identité d’hôte.

Confirmation de l’identité d’hôte

La clé publique d’hôte identifie l’équipement cible et diffère des clés utilisateur et CA. Lisez les clés existantes sur l’équipement :

cat /etc/ssh/ssh_host_*_key.pub

Dans « Accès distants → Identité d’hôte », déclarez chaque ligne, comparez l’empreinte complète SHA256: puis cliquez sur « Vérifier et confirmer ». Si plusieurs algorithmes sont proposés, vérifiez-les séparément.

Afficher les empreintes des clés d’hôte

Sur l’équipement ou par un canal de gestion fiable, exécutez les commandes pour les fichiers réellement présents et ignorez les autres :

ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

ssh-keygen -lf /etc/ssh/ssh_host_ecdsa_key.pub -E sha256

ssh-keygen -lf /etc/ssh/ssh_host_rsa_key.pub -E sha256

Après réinstallation ou changement de clé d’hôte, vérifiez de nouveau les empreintes.

Étape 4 : choisir les identifiants et vérifier la connexion

1. Dans la vue d’ensemble, ouvrez « Bureau à distance », sélectionnez SSH et indiquez le compte système.
2. Choisissez « Clé SSH » ou « Certificat utilisateur OpenSSH », puis un identifiant enregistré.
3. Vérifiez les délais d’inactivité et de durée maximale, puis cliquez sur « Connexion ». Aucun nouveau téléversement ni saisie de phrase secrète n’est nécessaire.
4. Dans le terminal, exécutez la commande suivante et vérifiez que le compte retourné est celui attendu :

whoami

Pour un compte et un mode donnés, les identifiants de l’équipement priment. Ceux de la flotte s’appliquent uniquement en l’absence de configuration locale. Aucun repli automatique n’a lieu si les identifiants de l’équipement sont expirés, désactivés, révoqués ou non autorisés.

Après expiration, faites signer un nouveau certificat puis utilisez « Mettre à jour clé/certificat » dans la gestion des clés. La plateforme ne renouvelle pas automatiquement les certificats et ne modifie pas les autorisations locales.

Formats pris en charge et questions fréquentes

• Clés utilisateur et CA : Ed25519 ou RSA de 2048 à 8192 bits. Les clés privées doivent être au format OpenSSH-v1. Chaque clé privée ou certificat est limité à 64 KiB.
• Les certificats utilisateur doivent avoir une période de validité définie et des principaux non vides. Signatures acceptées : Ed25519 et RSA SHA-256/SHA-512. SHA-1, critical options, clés utilisateur ECDSA, X.509 et certificats d’hôte SSH sont refusés.
• Clés d’hôte : Ed25519, ECDSA nistp256/384/521 ou RSA de 2048 à 8192 bits. RDP et VNC conservent l’authentification par mot de passe.

Problème	Vérifications
Aucun identifiant disponible	Compte, mode, permissions et remplacement par l’équipement
Clé ou phrase secrète incorrecte	Utiliser la clé privée utilisateur correspondante et sa phrase secrète, jamais la clé privée CA
Certificat refusé par l’équipement	Préfixe d’autorisation CA, principaux, validité, heure locale et restrictions du compte SSH
Identité d’hôte non confirmée ou modifiée	Revérifier la clé d’hôte correspondant à l’algorithme négocié
Déconnexion automatique	Délais d’inactivité et maximal affichés, validité du certificat et état de l’équipement

Voir Gestion des accès distants pour les autres fonctions d’administration.