3.3 KiB
VPS Contabo — Accès supervision Claude (claude-oversight, sudo NOPASSWD, alerte connexion)
Date : 2026-07-05 Instance : hermes-nyora Tags : nyora, vps, contabo, securite, acces, supervision
Décision
Nabil a demandé un accès root pour que Claude puisse vérifier/cadrer/intervenir en cas de problème grave sur le VPS. Root SSH direct (PermitRootLogin yes) écarté — mauvaise pratique même pour un accès de confiance, ça ouvre une porte système au lieu d'un compte individuel traçable.
Solution retenue
User dédié claude-oversight, sudo NOPASSWD: ALL (capacité root équivalente), PermitRootLogin reste désactivé. ForceCommand sur ce user exécute un wrapper qui envoie une alerte Telegram à Nabil AVANT d'ouvrir le shell — connexion toujours visible, jamais silencieuse.
Politique d'usage
Nyora reste l'exécutant par défaut de toute opération sur ce VPS (setup, maintenance, backup). claude-oversight sert exclusivement à la vérification a posteriori et à l'intervention d'urgence — pas à l'exécution routinière, pour éviter la désynchronisation entre deux acteurs qui modifient la même machine.
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.