Après avoir figé une session pour la réutiliser dans l’article tmuxp précédent, ce qui coince ensuite vient souvent moins des volets que de la façon de passer d’une session à l’autre.
En multi-hôtes, on perd souvent du temps à deux endroits : retrouver la bonne session, puis revalider le contexte après chaque bascule.
C’est là que tmux-sessionx peut aider.
1) Problème : gérer les sessions et revalider le contexte finit par ralentir
Quand le nombre d’hôtes monte, faire défiler les sessions à la main (next-session, previous-session) ne dit plus grand-chose.
Le coût revient souvent au même endroit : « Sur quel hôte suis-je ? » et « Est-ce bien la bonne session ? »
Le but est simple : choisir plus vite avec l’aperçu, puis retrouver plus vite le bon contexte après la bascule.
2) Ce que tmux-sessionx apporte ici
Ici, quelques commandes du popup font l’essentiel :
- Recherche fuzzy avec aperçu avant de changer de session.
Enterpour changer de session, ou saisie d’un nouveau nom +Enterpour créer une session.Ctrl-rpour renommer etAlt+Backspacepour supprimer une session en place.Ctrl-wpour le modewindowetCtrl-tpour le modetree, utiles pour d’autres vues de navigation.?pour afficher/masquer l’aperçu, puisCtrl-u/Ctrl-dpour faire défiler la sortie.
tmux-sessionx : raccourcis et options
Toutes les possibilités sont dans le projet officiel : omerxx/tmux-sessionx. Pour le détail du comportement et de la personnalisation, consultez dans le README les sections sur les raccourcis et la configuration.
3) Modèle de sessions pratique : base, une session par hôte et sensors
Un découpage simple en trois sessions marche bien :
basepour les fenêtres de pilotage partagées :main,tunnel,framework,editor,c2_server,dns,proxy.- Une session par hôte avec la même structure :
main,files,c2_client,revshell,brute_spray. sensorspour la visibilité centralisée et les transferts :net,monitors,transfer.
base, host et sensors sont juste des noms d’exemple. Gardez surtout des noms cohérents avec votre façon de travailler.
Optionnel : réserver un deuxième écran à `sensors`
Si vous avez un deuxième écran, garder la session sensors visible dessus peut réduire les changements de contexte pendant que vous passez d’une session hôte à l’autre. Sur un seul écran, gardez sensors épinglée et revenez-y avec tmux-sessionx quand nécessaire.
tmux-sessionx devient plus utile quand la liste des sessions reflète ces rôles, au lieu d’un simple empilement de shells. Sur la capture ci-dessous, sensors est sélectionnée, host reste juste à côté dans le sélecteur, et le texte d’aperçu provient des titres de volets définis dans le YAML.
Fichiers YAML utilisés dans ce modèle :
base.yaml(télécharger),host.yaml(télécharger),sensors.yaml(télécharger)
4) Pourquoi cela fonctionne bien avec tmux-sessionx
La liste des sessions reste compacte : une session de pilotage, une session sensors et des sessions hôte nommées node_IP.
tmuxp garde la même structure pour les sessions hôte, et tmux-sessionx s’appuie dessus pour la navigation. L’aperçu sert alors à vérifier le contexte avant la bascule, au lieu de devoir deviner.
Le mode window devient plus facile à parcourir quand des rôles répétés (main, files, revshell, brute_spray) restent cohérents d’une session hôte à l’autre.
5) Conventions de nommage
Une convention simple consiste à nommer les sessions sous la forme node_IP.
node n’est qu’un préfixe d’exemple. Remplacez-le par un nom ou un nom d’hôte si c’est plus parlant dans votre contexte.
$ tmux new-session -As node01_198_51_100_5Autres exemples : node02_198_51_100_23, node03_198_51_100_42.
Ce format rend la recherche plus prévisible et aide à distinguer des hôtes aux noms proches grâce au suffixe IP.
Vous pouvez aussi ajouter un préfixe :
int_Name_IPpour le contexte interne / après l’accès initial.ext_Name_IPpour le contexte externe / exposé à Internet.
