From 63a7dfcc141b509c4c11f41fa76e5dad82777f04 Mon Sep 17 00:00:00 2001 From: bolbol Date: Thu, 30 Jul 2026 15:57:48 +0000 Subject: [PATCH] docs: correction - alerte Telegram MCP-level deja active, pas de gap --- .../vps-contabo-acces-claude-supervision.md | 21 ++++++++++--------- 1 file changed, 11 insertions(+), 10 deletions(-) diff --git a/hermes-nyora/vps-contabo-acces-claude-supervision.md b/hermes-nyora/vps-contabo-acces-claude-supervision.md index 6965960..a7d0f21 100644 --- a/hermes-nyora/vps-contabo-acces-claude-supervision.md +++ b/hermes-nyora/vps-contabo-acces-claude-supervision.md @@ -39,13 +39,14 @@ aucun agent n'a de sudo). Fichier `/etc/sudoers.d/claude-oversight-full`, valide par `visudo -c` avant activation. Verifie : `sudo -n whoami` -> root, lecture `/etc/shadow` reussie. -**Gap de securite trouve en verifiant** : le garde-fou d'alerte Telegram -original (`/etc/profile.d/claude-oversight-login-alert.sh`, toujours present) -ne couvre QUE les sessions interactives (`[ -t 0 ]`) -- et de toute facon -`/etc/profile.d/` n'est pas source du tout pour `ssh host "commande"` -non-interactif, qui est exactement le mode d'usage de mcp-vps:run_command. -**L'usage routinier via mcp-vps ne declenche donc aucune alerte actuellement**, -contrairement a l'intention originale ("connexion toujours visible, jamais -silencieuse"). Pas corrige a ce stade -- pose comme question ouverte a Nabil -(cf session Claude du 30/07) plutot que decide unilateralement, le -compromis bruit-Telegram-par-commande-vs-visibilite etant un vrai arbitrage. +**Fausse alerte corrigee (30/07/2026, meme session)** : le script +`/etc/profile.d/claude-oversight-login-alert.sh` (SSH interactif host-level) +ne couvre effectivement pas `ssh host "commande"` non-interactif -- mais ce +n'est PAS un gap, une autre couche d'alerte existe deja et couvre ce cas : +le **serveur MCP mcp-vps lui-meme** envoie une alerte Telegram (bot +HermesPerso_bot) a chaque nouvelle session MCP ("nouvelle session MCP depuis +<IP> (Claude-User)") -- confirme par Nabil, alerte recue a 16h52 le 30/07. +Granularite par session (pas par commande individuelle), ce qui est le bon +niveau -- une alerte par run_command aurait ete du bruit permanent. Rien a +corriger ; la transparence "jamais d'intervention silencieuse" est deja +assuree, juste a une couche differente de celle initialement inspectee.