Comprendre WALLIX · WCE 12

WALLIX : proxy SSH, clés, forwarding et canaux

Comprendre coffre de clés, agent forwarding, Kerberos, multicanal et vérification des clés d’hôte dans le proxy SSH WALLIX.

Thomas SAUTIER · Publié le · Révisions de certification

Références et objectifs de certification (1)

Ce guide aborde le périmètre Bastion 12. Les menus, options et compatibilités peuvent évoluer avec les correctifs et la version d’Access Manager : vérifiez la documentation correspondant à votre environnement avant une configuration.

Comprendre le fonctionnement

Le proxy SSH peut utiliser une clé du coffre, un agent utilisateur ou un mécanisme Kerberos selon la configuration. Une clé d’utilisateur authentifie un compte ; une clé d’hôte identifie le serveur. Accepter la première ne justifie pas d’ignorer un changement de la seconde.

Le multicanal permet plusieurs usages sur une connexion TCP, par exemple shell et SFTP vers une même cible. La fermeture du shell n’implique pas toujours celle de tous les canaux. La politique de déconnexion doit correspondre au contrôle d’accès attendu.

Repère visuelWALLIX : proxy SSH, clés, forwarding et canaux
WALLIX : proxy SSH, clés, forwarding et canaux Le proxy vérifie l’accès au serveur et sa clé d’hôte. Une connexion peut porter plusieurs canaux dont la fermeture dépend de la politique. 01 Client SSH Clé ou identité 02 Proxy SSH Politique et confiance 03 Serveur Clé d’hôte vérifiée 04 Canaux Shell et transferts
Le proxy vérifie l’accès au serveur et sa clé d’hôte. Une connexion peut porter plusieurs canaux dont la fermeture dépend de la politique.

Construire et vérifier la configuration

  1. Identifier la méthode secondaire : mot de passe, clé du coffre, agent forwarding ou Kerberos pris en charge.
  2. Contrôler séparément algorithmes côté client et côté cible. Éviter un affaiblissement global pour un seul serveur ancien.
  3. Définir stockage et vérification de la clé d’hôte. Valider la clé initiale et toute rotation par un canal fiable.
  4. Choisir multicanal, fermeture forcée, keepalive et délai d’inactivité. Limiter les sous-protocoles aux usages autorisés.
  5. Tester shell, SFTP ou SCP concernés, fermeture du shell et changement de clé. Activer les logs détaillés seulement sur le périmètre et la durée nécessaires.

Les choix à retenir

Reliez chaque réglage à son effet sur l’accès et à la vérification associée.

WALLIX : proxy SSH, clés, forwarding et canaux : points de décision
ÉlémentRôle ou effetVérification
Clé du coffreAuthentifie le compte cibleClé publique installée sur le serveur
Agent forwardingDélègue des signatures via l’agentExposition et confiance maîtrisées
Clé d’hôteIdentifie le serveurEmpreinte validée
MulticanalMaintient plusieurs usagesÉtat des canaux après fermeture

Diagnostiquer sans masquer le problème

Un message de clé d’hôte modifiée n’est pas un mauvais mot de passe. Vérifier rotation, nouvelle installation ou mauvaise cible avant de remplacer la confiance stockée.

Log all kbd peut inclure des entrées normalement sans écho, donc des secrets. Le niveau libssh DEBUG est très verbeux. Tester aussi le retour au sélecteur, ICAP et le mode transparent avec son routage prévu.

Exercice de compréhension

Un transfert continue après la fermeture du shell SSH. Quelle fonction peut l’expliquer ?

Voir le corrigé

Le multicanal et la politique de fermeture des canaux. Vérifier Force shell disconnection et les sous-protocoles ouverts ; l’arrêt du shell seul ne démontre pas l’arrêt de tous les usages.

Pour approfondir

Continuer le parcours WCE 12

Retrouver les 14 guides du parcours WCE 12

Un autre angle sur ces sujets

Découvrir l’accompagnement WALLIX de Samhan

Échange

Un projet d’accès privilégiés ?

Échangeons sur vos identités, vos flux d’administration et vos contraintes d’exploitation.