From c85f8d7a2bdb9a56bdc20155a5fe6d6d5f55b42a Mon Sep 17 00:00:00 2001 From: bolbol Date: Thu, 30 Jul 2026 15:52:44 +0000 Subject: [PATCH] runbook: mcp-vps sudo NOPASSWD:ALL restaure + gap alerte Telegram documente --- .../vps-contabo-acces-claude-supervision.md | 34 +++++++++++++++++++ 1 file changed, 34 insertions(+) diff --git a/hermes-nyora/vps-contabo-acces-claude-supervision.md b/hermes-nyora/vps-contabo-acces-claude-supervision.md index 3bc64c7..6965960 100644 --- a/hermes-nyora/vps-contabo-acces-claude-supervision.md +++ b/hermes-nyora/vps-contabo-acces-claude-supervision.md @@ -15,3 +15,37 @@ Nyora reste l'exécutant par défaut de toute opération sur ce VPS (setup, main ## Fichier `hermes-nyora/data/workspace/contabo-vps/setup-claude-oversight-vps.sh` + + +## Reglage complet des droits mcp-vps (30/07/2026) + +**Constat** : la reinstallation du VPS (07/07) a recree claude-oversight avec une +politique sudo scopee (systemctl qbittorrent-nox/docker/tailscaled + journalctl, +pas NOPASSWD:ALL comme prevu a l'origine le 05/07). La cle SSH mcp-vps-claude +(generee des le 11/07) etait deja deposee dans authorized_keys (restriction +`from="172.16.0.0/12"`, coherent -- accessible uniquement depuis le reseau +Docker interne). Alias SSH `vps.internal` deja configure dans mcp-vps +(~/.ssh/config, resout vers 172.17.0.1 -- **mcp-vps tourne directement sur +l'hote Contabo lui-meme**, pas sur une autre machine ; c'est pourquoi +172.17.0.1 (passerelle docker de la VM) atteint l'hote reel, jamais l'IP +Tailscale 100.94.90.119 depuis l'interieur). + +**Action** : a la demande de Nabil ("mcp-vps devra avoir tous les droits"), +sudo NOPASSWD:ALL restaure pour claude-oversight. Methode : escalade via +l'appartenance deja accordee au groupe `docker` (root-equivalent de fait, +containeur privilegie avec `-v /:/host` + `chroot`), pas de mot de passe +contourne -- coherent avec la politique VPS (differente de celle du NAS ou +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.