Exécuter une passerelle Hermes Agent sur un VPS et vérifier une réponse Telegram privée

Un bot Telegram privé peut faciliter l’accès à un agent sur VPS, mais une passerelle connectée ne prouve pas que la bonne personne obtient une réponse. Ce guide part d’un répertoire de données Hermes Agent neuf, autorise un identifiant Telegram numérique, vérifie une vraie réponse et laisse à l’opérateur un arrêt contrôlé. Il suit les instructions Docker v0.22.2 et instructions Telegram de NousResearch, vérifiées le 19 octobre 2026. BIG CHANGE n’a ni exploité de VPS, ni téléchargé l’image, ni créé de bot, ni appelé un modèle pour ce guide.

Le grand changement

• Ce qui change : Une image Docker fixée par empreinte et vérifiée par version, avec un montage dédié /opt/data, rend identifiables le logiciel et l’état de cette passerelle.
• Pourquoi c’est important : Une liste d’identifiants Telegram numériques autorisés et une vraie réponse privée montrent si le compte prévu peut utiliser la passerelle.
• À surveiller : L’appairage ou des droits globaux peuvent élargir l’accès, et une demande inoffensive ne limite pas les outils de l’agent. Vérifiez droits, journaux, redémarrage et état arrêté.

Vous devez pouvoir administrer un VPS Linux par SSH, disposer de Docker Engine fonctionnel et d’un accès de récupération de l’hôte, d’un compte Telegram pouvant créer un bot via BotFather et d’un compte admissible chez un fournisseur de modèles Hermes. Comparez architecture et ressources au build officiel amd64 ou arm64 ; vérifiez accès et facturation avant l’assistant. Docker est supposé déjà opérationnel ; installation et pare-feu dépendent du système et du fournisseur. L’hôte doit joindre Telegram et le fournisseur de modèles. Réservez un répertoire privé pour l’état Hermes et limitez sa lecture : /opt/data contiendra identifiants secrets, sessions et journaux. Le manuel Docker décrit ce montage comme la source de vérité persistante.

1. Fixer l’image avant la configuration

Connectez-vous par SSH et gardez le même shell pour ces commandes. Le tag stable peut changer. Téléchargez-le, relevez son empreinte de dépôt et confirmez que l’image annonce elle-même la version 0.22.2. Arrêtez si la version diffère, l’empreinte manque, le répertoire contient déjà un état ou un conteneur nommé hermes existe. Actualisez les instructions pour la version réelle ou obtenez une image documentée correspondante avant de continuer. L’empreinte fixe l’image exécutée, sans prouver seule sa version.

set -eu
docker info >/dev/null
docker container inspect hermes >/dev/null 2>&1 && { echo 'Container hermes already exists; stop here.'; exit 1; }
HERMES_DATA="$HOME/.hermes"
if [ -e "$HERMES_DATA" ]; then echo 'Hermes data path already exists; stop here.'; exit 1; fi
mkdir -m 700 "$HERMES_DATA"
docker pull nousresearch/hermes-agent:stable
docker image inspect nousresearch/hermes-agent:stable --format '{{json .RepoDigests}}'
IMAGE_REF="$(docker image inspect nousresearch/hermes-agent:stable --format '{{index .RepoDigests 0}}')"
if ! printf '%s\n' "$IMAGE_REF" | grep -Eq '^nousresearch/hermes-agent@sha256:[0-9a-f]{64}$'; then
  echo 'No valid repository digest; stop here.'; exit 1
fi
printf 'Pinned image: %s\n' "$IMAGE_REF"
VERSION_OUTPUT="$(docker run --rm "$IMAGE_REF" --version)"
printf 'Image version: %s\n' "$VERSION_OUTPUT"
if ! printf '%s\n' "$VERSION_OUTPUT" | grep -Eq '(^|[^0-9])v?0[.]22[.]2([^0-9]|$)'; then
  echo 'Image version is not 0.22.2; stop here.'; exit 1
fi

set -eu arrête cette suite de commandes si Docker est indisponible, si le téléchargement ou l’inspection échoue, ou si la commande de version échoue. Les contrôles explicites arrêtent aussi une empreinte vide ou une autre version. Ne configurez rien après un tel résultat. Conservez la valeur enregistrée de nousresearch/hermes-agent@sha256:…. Configuration et passerelle utilisent ci-dessous IMAGE_REF, donc un changement ultérieur du tag ne remplace pas discrètement ce conteneur. Ces vérifications sont à effectuer sur le vrai VPS ; cet article ne fournit aucune empreinte d’image vérifiée. Utilisez un nouveau répertoire dédié sur le système de fichiers natif de l’hôte. N’exécutez jamais deux passerelles sur le même répertoire.

2. Configurer le fournisseur et un expéditeur Telegram privé

Lancez l’assistant de configuration Docker avec le répertoire monté. Choisissez une voie de modèle permise par le compte, authentifiez-vous et inspectez le fournisseur/modèle obtenu. Accès et frais dépendent du compte. Un paramètre sauvegardé ne prouve pas qu’une requête au modèle a réussi.

docker run -it --rm -v "$HERMES_DATA:/opt/data" "$IMAGE_REF" setup

Dans Telegram, demandez à @BotFather un bot avec /newbot et gardez son jeton privé. Obtenez l’identifiant numérique Telegram de l’expéditeur, par exemple avec la méthode liée dans le manuel Telegram ; un nom d’utilisateur n’est pas un identifiant. L’assistant ou hermes gateway setup peut écrire le jeton et la liste d’autorisation. Manuellement, placez TELEGRAM_BOT_TOKEN=<private token> et TELEGRAM_ALLOWED_USERS=<your numeric ID> dans $HERMES_DATA/.env, qui apparaît sous /opt/data/.env dans le conteneur. N’inscrivez le jeton ni dans les commandes, ni dans l’historique, ni dans les notes partagées ou cet article.

Dans $HERMES_DATA/config.yaml (/opt/data/config.yaml dans le conteneur), réglez le comportement global pour les messages privés non autorisés :

unauthorized_dm_behavior: ignore

Après la sortie du conteneur de configuration, l’image officielle peut avoir attribué $HERMES_DATA à son UID d’exécution 10000. Son amorçage limite .env au mode 600 et resserre un fichier existant config.yaml à 640 ; une configuration créée pendant cet amorçage peut demander le même resserrement. Un utilisateur SSH ordinaire peut donc ne pas ouvrir ces fichiers. Si l’assistant n’a pas défini les clés nécessaires, un administrateur autorisé de l’hôte peut inspecter et modifier ces deux fichiers précis avec sudo, puis restaurer propriétaire d’exécution et modes privés. Un éditeur hôte lancé sous UID 10000 peut ne pas traverser un $HOME appartenant à l’utilisateur de connexion ; la commande utilise donc l’administration de l’hôte. Sur un hôte disposant de sudo et vi, utilisez-la après vérification non secrète du propriétaire et des modes. Ne continuez pas avec un autre UID ou un fichier manquant ; réglez d’abord l’accès propre à l’hôte.

sudo stat -c '%u:%g %a %n' "$HERMES_DATA" "$HERMES_DATA/.env" "$HERMES_DATA/config.yaml"
# Expected: directory owner 10000 and mode 700; .env owner 10000 and mode 600.
# config.yaml should have owner 10000; its first-boot mode can vary.
sudo vi "$HERMES_DATA/.env"
sudo vi "$HERMES_DATA/config.yaml"
sudo chown 10000:10000 "$HERMES_DATA/.env" "$HERMES_DATA/config.yaml"
sudo chmod 700 "$HERMES_DATA"
sudo chmod 600 "$HERMES_DATA/.env"
sudo chmod 640 "$HERMES_DATA/config.yaml"
sudo stat -c '%u:%g %a %n' "$HERMES_DATA" "$HERMES_DATA/.env" "$HERMES_DATA/config.yaml"

La sortie finale de stat doit montrer UID/GID 10000 pour les deux fichiers, le mode du répertoire 700, .env le mode 600 et config.yaml le mode 640 ; elle affiche des métadonnées, pas les secrets. Le chown ne cible que ces deux fichiers, y compris un remplacement créé par l’éditeur. Si sudo ou vi manque, suivez la procédure d’administration autorisée de l’hôte avec la même vérification du propriétaire et des modes. Ne rendez pas le répertoire lisible par tous et ne remappez pas l’utilisateur du conteneur pour cette recette.

Pendant l’édition, préservez les paramètres du fournisseur. Vérifiez qu’aucun remplacement Telegram spécifique de unauthorized_dm_behavior ne définit pair, et qu’aucun paramètre global GATEWAY_ALLOWED_USERS ou GATEWAY_ALLOW_ALL_USERS n’accorde davantage d’accès. Dans config.yaml, vérifiez aussi que ni gateway.allow_all_users ni le paramètre de premier niveau allow_all_users n’est vrai et qu’aucune liste globale ou Telegram n’ajoute d’expéditeur. N’utilisez pas * dans les listes Telegram, n’ajoutez pas de listes de groupes et n’approuvez aucun code d’appairage. Un répertoire neuf évite les droits hérités ; s’il contient déjà des données, arrêtez et inspectez au lieu d’écraser. Gardez la confidentialité de groupe BotFather activée, n’ajoutez le bot à aucun groupe et ne le nommez pas administrateur. Le manuel d’accès à la passerelle décrit listes et droits persistants d’appairage comme deux accès distincts. Le manuel de sécurité décrit ignore comme supprimant silencieusement les messages privés non autorisés.

La liste contrôle qui peut entamer une conversation, pas ce qu’un agent autorisé peut faire. Les sessions Telegram Hermes incluent par défaut des outils de terminal. Examinez permissions, montages Docker, accès fournisseur et politique hôte avant d’autoriser l’expéditeur. Une demande de test inoffensive n’est qu’un test.

3. Démarrer la passerelle et vérifier la première réponse

Démarrez un seul conteneur nommé depuis l’empreinte enregistrée. La commande Docker publiée inclut une option -p 8642:8642 pour l’API ; omettez-la ici, car un message Telegram privé n’a besoin d’aucun port API ou tableau de bord public. L’image supervise la passerelle, tandis que la politique Docker unless-stopped régit le redémarrage du conteneur au démarrage de Docker. Le répertoire monté conserve configuration et sessions lors du redémarrage.

docker run -d --name hermes --restart unless-stopped \
  -v "$HERMES_DATA:/opt/data" "$IMAGE_REF" gateway run
if ! {
  docker inspect hermes --format '{{.Image}} {{.State.Status}}' &&
  [ "$(docker inspect hermes --format '{{.State.Status}}')" = running ] &&
  docker logs --tail 50 hermes &&
  docker exec -u hermes hermes hermes pairing list
}; then
  echo 'State, logs or pairing check failed; stopping before any message.'
  docker stop hermes || true
  docker inspect hermes --format '{{.State.Status}}' || true
  exit 1
fi

Confirmez que le conteneur est running, cherchez une connexion Telegram et des erreurs fournisseur dans les journaux, puis inspectez l’appairage avant toute demande. Si une lecture initiale échoue, le bloc arrête la passerelle et affiche son état ; un résultat CLI ou d’autorisation inconnu ne donne pas le feu vert. Confirmez exited avant d’enquêter ; n’envoyez rien et ne redémarrez pas si l’état est incertain. Aucun autre expéditeur ne doit être approuvé. S’il y en a un, arrêtez et vérifiez l’état arrêté. docker exec ne fonctionne pas sur un conteneur arrêté, et l’entrée habituelle de l’image peut restaurer une passerelle précédemment active. Pour une installation neuve à UID par défaut, le contrôle hors ligne suivant lance uniquement la CLI Hermes fixée, sous UID 10000 et sans réseau, en évitant le démarrage de la passerelle. C’est une adaptation des commandes et du point d’entrée documentés, non une commande testée par BIG CHANGE. Ne l’utilisez qu’après confirmation que l’UID actif et le propriétaire des données valent 10000. Si propriétaire, UID, sortie CLI ou droits sont incertains, laissez la passerelle arrêtée et résolvez avant tout redémarrage.

if [ "$(docker exec -u hermes hermes id -u)" != 10000 ] || [ "$(stat -c %u "$HERMES_DATA")" != 10000 ]; then
  echo 'Runtime UID or data owner differs; stop for a host-specific repair.'; docker stop hermes; exit 1
fi
docker stop hermes
if [ "$(docker inspect hermes --format '{{.State.Status}}')" != exited ]; then
  echo 'Container is not exited; do not mount state in another container.'; exit 1
fi
docker run --rm --network none --user 10000:10000 \
  --entrypoint /opt/hermes/.venv/bin/hermes \
  -v "$HERMES_DATA:/opt/data" "$IMAGE_REF" pairing list
# For a listed unwanted Telegram user, read the exact numeric ID first:
printf 'Unwanted numeric Telegram user ID: '; IFS= read -r UNWANTED_ID
if ! printf '%s\n' "$UNWANTED_ID" | grep -Eq '^[0-9]+$'; then echo 'Invalid ID; leave gateway stopped.'; exit 1; fi
docker run --rm --network none --user 10000:10000 \
  --entrypoint /opt/hermes/.venv/bin/hermes \
  -v "$HERMES_DATA:/opt/data" "$IMAGE_REF" pairing revoke telegram "$UNWANTED_ID"
docker run --rm --network none --user 10000:10000 \
  --entrypoint /opt/hermes/.venv/bin/hermes \
  -v "$HERMES_DATA:/opt/data" "$IMAGE_REF" pairing list

Confirmez que l’identifiant indésirable est absent de la liste finale. Inspectez $HERMES_DATA/.env et config.yaml en privé pour d’autres listes de plateforme ou globales, * ou des paramètres autorisant tout, et retirez les droits indésirables par la configuration documentée. La passerelle reste arrêtée jusqu’au contrôle de tous les accès. Retirer une entrée ne révoque pas un appairage indépendant ou un droit global. Après cette vérification, docker start hermes reprend volontairement le conteneur initial ; contrôlez journaux et appairage avant de lui écrire.

Depuis le compte autorisé, ouvrez une conversation privée avec le bot et envoyez une demande inoffensive, par exemple « Réponds par une brève salutation. » Confirmez une vraie réponse et inspectez le journal ou la session correspondante. Message envoyé, indicateur de saisie, statut ou configuration terminée ne sont pas une réponse. La commande Telegram /whoami peut afficher la portée active de messagerie ; elle ne prouve pas l’autorisation de l’hôte. Ne gardez que des preuves non sensibles.

Sans réponse, lisez d’abord l’état du conteneur et docker logs --tail 50 hermes. Vérifiez jeton, valeur numérique exacte de TELEGRAM_ALLOWED_USERS, authentification et admissibilité du fournisseur, et connexion sortante. Si le tour est incertain, examinez conversation et journaux avant un autre message. Le démarrage à froid documenté peut abandonner des mises à jour en attente, et l’antidoublon est limité à la mémoire. Aucun acheminement exactement une fois n’est garanti.

4. Vérifier redémarrage, arrêt et récupération

Après la fin du premier échange, redémarrez le même conteneur, consultez les nouveaux journaux et l’état conservé sous /opt/data, puis envoyez une nouvelle demande privée inoffensive et confirmez la réponse. Arrêtez le conteneur et lisez l’état Docker. exited indique l’arrêt ; une conversation silencieuse ne suffit pas. docker start hermes permet de reprendre volontairement plus tard.

docker restart hermes
docker logs --tail 50 hermes
docker inspect hermes --format '{{.State.Status}}'
# After the restarted gateway is ready, send a new private test message.
docker stop hermes
docker inspect hermes --format '{{.State.Status}}'
# Expected after stop: exited
# When intentionally resuming later: docker start hermes

Si le redémarrage échoue, vérifiez état et journaux Docker, puis $HERMES_DATA/logs/gateways/default/current et $HERMES_DATA/logs/container-boot.log, le montage, le propriétaire et l’image/version fixée. Les notes de version v0.22.2 décrivent une correction de disponibilité au démarrage ; elles n’établissent pas ce qui s’est produit chez vous. Ne supprimez pas les données pour réparer. Si le jeton fuit, arrêtez, révoquez-le dans BotFather, remplacez-le en privé dans le fichier monté .env, puis revérifiez l’accès avant redémarrage. Révoquez aussi les appairages indésirables et inspectez les listes effectives.

Hébergement VPS et modèle peuvent coûter séparément. Vérifiez votre offre, vos limites et frais réels ; ni durée, ni quota gratuit, ni disponibilité cible ne sont promis. Telegram et le fournisseur traitent les messages ; le répertoire hôte conserve secrets et conversations. Ce contrôle concerne un hôte, un bot et une première réponse. D’autres guides BIG CHANGE couvrent la sauvegarde et la restauration Hermes et un travail Hermes récurrent.

Sources et lectures complémentaires

Les instructions de configuration Docker, configuration Telegram, l’accès à la passerelle, la sécurité et la version v0.22.2 sont les sources primaires de NousResearch. Le démarrage rapide explique la configuration du fournisseur. Ces liens documentent la procédure, pas une exploitation de VPS ou bot par BIG CHANGE.