Gestion des accès distants

La gestion des accès distants centralise les identifiants SSH et les connexions. Elle remplace l’ancienne gestion des connexions distantes des flottes et existe aussi au niveau équipement.

Pages et permissions

Page	Contenu
Flotte → Accès distants → Connexions	Afficher les connexions actives et les interrompre selon les permissions
Flotte → Accès distants → Clés	Stocker les identifiants SSH partagés
Équipement → Accès distants	Identifiants dédiés, éléments hérités et confirmation d’identité d’hôte ; gestion des clés uniquement
Vue d’ensemble de l’équipement → Bureau à distance	Choisir un identifiant enregistré ou un mot de passe pour se connecter, sans téléversement

Master et Admin gèrent les identifiants et l’identité d’hôte. L’utilisation est réservée par défaut aux administrateurs ; ils peuvent l’ouvrir explicitement aux membres autorisés à se connecter à distance, y compris Developer. Observer consulte uniquement les métadonnées, sans connexion ni modification.

Le droit d’utilisation est distinct du droit d’administration : il ne permet pas de consulter ni télécharger la clé privée. Aucun rôle ne dispose d’une fonction d’affichage ou d’export de celle-ci. Les opérations enregistrent l’utilisateur réel de la connexion.

Première configuration

L’administrateur configure sur l’équipement la clé publique du compte système cible, ou la clé publique de la CA émettrice et les principaux autorisés.
Dans les clés de la flotte ou de l’équipement, cliquez sur « Ajouter des identifiants SSH » et renseignez nom, compte système et mode d’authentification.
Téléversez la clé privée utilisateur et, en mode certificat, le certificat émis à l’extérieur. Fournissez la phrase secrète d’une clé chiffrée. Ne téléversez pas la clé privée de CA.
Choisissez les membres autorisés, définissez éventuellement l’élément par défaut et enregistrez.
Sur la page de l’équipement, déclarez sa clé publique d’hôte et confirmez-la après vérification fiable de l’empreinte.
Dans « Bureau à distance », l’utilisateur choisit compte, mode et identifiants enregistrés, puis teste la connexion.

À l’enregistrement, l’algorithme est détecté automatiquement, la signature et la validité du certificat sont contrôlées, ainsi que sa correspondance avec la clé privée. L’enregistrement et les permissions constituent l’autorisation de connexion de la plateforme ; aucune autorisation publique ou CA séparée n’est nécessaire. L’utilisateur reste responsable des clés publiques, CA, principaux et restrictions d’authentification sur l’équipement.

L’équipement ne récupère pas les clés du cloud et n’a pas à communiquer de version ni d’état d’application. La plateforme ne modifie pas ses fichiers. Un enregistrement réussi signifie que la configuration cloud est sauvegardée ; le service SSH local valide la connexion réelle.

Le tutoriel Authentification SSH par clé et certificat couvre PowerShell et Linux, la génération des clés, la signature CA, les autorisations locales, le téléversement et la validation. Une clé SSH ordinaire ne nécessite pas de CA ; un certificat OpenSSH nécessite le certificat utilisateur et sa clé privée correspondante. La clé privée de CA reste toujours chez l’émetteur.

Priorité de l’équipement, héritage et valeurs par défaut

L’héritage est déterminé par le compte système cible et le mode d’authentification :

Si une configuration d’équipement existe, seuls ses identifiants sont utilisables ; ceux de la flotte sont indiqués comme remplacés.
Sinon, les identifiants de flotte s’appliquent sans option d’héritage à configurer.
Si l’élément de l’équipement est expiré, désactivé, révoqué ou inaccessible à l’utilisateur, il n’y a ni retour automatique à la flotte ni basculement vers un mot de passe.
Plusieurs éléments peuvent être stockés au même niveau avec un choix par défaut ; celui-ci ne contourne pas les contrôles de disponibilité et de permissions.

Les éléments hérités sont en lecture seule et se modifient dans la flotte. Désactivation et révocation conservent la priorité de l’équipement. Supprimer sa dernière configuration correspondante peut rétablir l’héritage ; vérifiez l’effet indiqué dans la confirmation.

Le périmètre des identifiants ne limite que l’accès JelinaCloud. Pour isoler localement différentes flottes ou comptes, configurez des clés, CA ou règles de principaux distinctes sur l’équipement.

Modifier, désactiver, révoquer et supprimer

Opération	Comportement
Modifier	Changer le nom, les membres autorisés et le choix par défaut, sans réafficher clé privée ni phrase secrète
Mettre à jour clé ou certificat	Téléverser une nouvelle clé, un certificat facultatif et la phrase secrète nécessaire, sans changer compte, périmètre ou mode
Désactiver / activer	Désactivation réversible ; nouvelles connexions bloquées, connexions existantes revérifiées puis fermées
Révoquer	Élément non réactivable et clé privée chiffrée effacée ; autres éléments indépendants et confiance locale inchangés
Supprimer	Effacer le contenu chiffré et conserver les métadonnées d’audit ; une suppression locale peut rétablir l’héritage de flotte

JelinaCloud ne délivre ni ne renouvelle automatiquement les certificats utilisateur. Avant expiration, demandez-en un nouveau à votre administrateur CA, mettez-le à jour dans la page et vérifiez-le. Modifier une date dans l’interface ne prolonge pas le certificat.

Les opérations ne concernent que les connexions via JelinaCloud. Elles ne nettoient pas automatiquement authorized_keys, les CA ou la KRL locale. Pour bloquer SSH direct, l’administrateur doit révoquer les accès et supprimer les anciennes autorisations sur l’équipement.

Confirmer l’identité d’hôte

Les connexions par clé et certificat exigent la vérification de l’identité de l’équipement, distincte du certificat utilisateur et de sa CA émettrice.

Sur l’équipement ou par un canal fiable, exécutez cat /etc/ssh/ssh_host_*_key.pub pour récupérer les clés publiques d’hôte existantes.
Dans les accès distants de l’équipement, ouvrez « Identité d’hôte », cliquez sur « Déclarer une clé publique d’hôte » et collez une ligne à la fois.
Exécutez ssh-keygen -lf <fichier-de-clé-publique-hôte> -E sha256 sur l’équipement et comparez l’empreinte complète avec la page.
Si elles correspondent, cliquez sur « Vérifier et confirmer ». Déclarez et vérifiez chaque algorithme séparément.

Seules les clés publiques d’hôte sont acceptées, à l’exclusion des clés utilisateur, certificats, clés publiques CA et clés privées. Algorithmes pris en charge : Ed25519, ECDSA nistp256/384/521 et RSA de 2048 à 8192 bits. L’algorithme est détecté automatiquement ; le serveur choisit la clé confirmée selon la négociation réelle, sans modifier guacd ni demander un choix à l’utilisateur.

Après réinstallation ou changement d’identité, une nouvelle vérification fiable est requise. L’état Online ne suffit pas à approuver automatiquement une nouvelle clé.

Paramètres et quotas de connexion

La page ne gère que les identifiants et l’identité d’hôte. Elle ne propose plus d’édition distincte des clés publiques, autorisations CA, certificats personnels ou stratégies de flotte/équipement. L’administrateur de l’équipement définit quels comptes acceptent quelles clés ou quels principaux CA.

L’administrateur de plateforme gère le port par défaut et les modes globalement autorisés ; la page de connexion affiche les modes disponibles. Pour limiter les authentifications SSH directes, par exemple par mot de passe, modifiez la configuration SSH de l’équipement.

Les quotas, plafonds par utilisateur et équipement, délais d’inactivité et durées maximales restent limités par l’offre de l’organisation et la capacité serveur. Le tenant voit les valeurs effectives en lecture seule et ne peut pas les augmenter.

Connexions actives et journal des opérations

La gestion affiche les connexions actives et permet leur interruption selon les droits. Les sessions résident en mémoire du service, sans historique persistant ; les opérations utilisent les journaux existants. Après redémarrage du service ou nettoyage de l’état, une ancienne connexion ne peut pas être reprise : reconnectez-vous.

Protection des clés et transfert d’équipement

Clés privées et phrases secrètes sont chiffrées. La liste affiche uniquement nom, compte, périmètre, algorithme, validité, permissions et état. La clé privée CA reste chez votre émetteur et n’est pas téléversée. La plateforme ne conserve pas la clé privée dans le cache du navigateur pour les connexions répétées.

Après transfert vers une autre flotte ou organisation, les anciens identifiants dédiés et autorisations deviennent inutilisables, et leur contenu chiffré est effacé. Un retour ne les restaure pas automatiquement. Reconfigurez les identifiants du périmètre actuel et vérifiez l’hôte ; l’administrateur reste responsable des anciennes relations de confiance sur l’équipement.