Surveiller sans agent : monitoring SSH minimaliste

Je vais être honnête, au début je pensais que « sans agent » voulait forcément dire « moins bien ». Et puis tu te retrouves avec 30 VPS, 12 machines chez des clients, 3 Raspberry Pi qui rendent service dans un coin… et tu n’as aucune envie d’installer encore un daemon de monitoring, encore une clé API, encore un service qui casse au prochain upgrade.

Parfois tu veux juste un truc simple. SSH, quelques commandes, un état de santé lisible. Et basta.

Dans cet article, je te montre comment mettre en place un monitoring minimaliste via SSH, sans agent, avec des checks utiles, un peu d’historique, et des alertes basiques. Pas un remplaçant complet de Zabbix ou Prometheus, non. Mais un filet de sécurité léger, robuste, et franchement pratique.

Objectif : depuis une seule machine de supervision, interroger des serveurs en SSH, exécuter des checks, produire un rapport, et déclencher une alerte si ça déraille.

Pourquoi « sans agent » peut être une bonne idée

Déjà, un agent ça veut dire :

• un service à installer
• des ports à ouvrir parfois
• des dépendances
• une config à maintenir
• des upgrades qui finissent en « why is it down »

Alors que SSH, tu l’as déjà. Et il est déjà audité, déjà contrôlé, déjà dans tes process. Le monitoring sans agent, c’est un peu la version « couteau suisse » : tu perds en finesse, tu gagnes en simplicité.

Cas d’usage typiques :

• serveurs clients où tu veux rester discret
• environnements très verrouillés
• petites infra perso
• besoin de checks ponctuels ou de garde fou
• monitoring de pré production temporaire

Et puis… si tu lis ce blog, tu sais que j’aime bien les approches pragmatiques. Sur Le Blog Tech Pro de Samyn-Antoy ABASSE, on alterne souvent entre sysadmin et business en ligne, mais au fond c’est la même logique : faire simple, utile, actionnable.

D'ailleurs, si tu cherches à approfondir tes connaissances sur le diagnostic des services systèmes en utilisant systemd tout en évitant les douleurs habituelles liées à sa configuration et son utilisation cet article pourrait t'apporter beaucoup d'informations utiles.

Pré requis : une machine de supervision et des clés SSH propres

On va partir sur une machine « superviseur » (un VPS, un serveur interne, même un laptop si tu veux au début).

1) Créer une clé dédiée monitoring

Sur la machine de supervision :

bash ssh-keygen -t ed25519 -f ~/.ssh/monitoring_ed25519 -C "monitoring@superviseur"

2) Pousser la clé sur chaque serveur

bash ssh-copy-id -i ~/.ssh/monitoring_ed25519.pub user@serveur1

Oui, tu peux aussi gérer ça à la main dans ~/.ssh/authorized_keys si tu préfères.

3) Durcir un peu l’accès

Sur les serveurs, dans ~/.ssh/authorized_keys, tu peux restreindre :

• une IP source (option from="x.x.x.x")
• des commandes autorisées (option command="...") mais attention, c’est vite contraignant si tu fais plusieurs checks
• pas de PTY (no-pty)
• pas de forwarding (no-agent-forwarding,no-port-forwarding,no-X11-forwarding)

Exemple (à adapter) :

text from="203.0.113.10",no-pty,no-agent-forwarding,no-port-forwarding,no-X11-forwarding ssh-ed25519 AAAA...

La philosophie des checks : peu, mais fiables

Un monitoring minimaliste ne doit pas chercher à tout faire. Il doit surtout détecter :

• la machine répond elle ?
• disque bientôt plein ?
• RAM explosive ?
• load incohérent ?
• services critiques down ?
• certificat TLS qui expire bientôt ? (optionnel)
• mises à jour de sécurité en attente ? (optionnel)

On va construire ça proprement, avec un script qui :

1. se connecte en SSH
2. exécute des commandes standard
3. parse le résultat
4. écrit un log
5. déclenche une alerte si seuil dépassé

Script bash minimaliste : checks essentiels via SSH

Crée un fichier monitor_ssh.sh sur la machine de supervision.

Note : je reste volontairement en bash, parce que c’est partout. Tu pourras migrer en Python plus tard si tu veux.

bash #!/usr/bin/env bash set -euo pipefail

KEY="${HOME}/.ssh/monitoring_ed25519" SSH_OPTS=(-i "$KEY" -o BatchMode=yes -o ConnectTimeout=5 -o StrictHostKeyChecking=accept-new)

HOSTS_FILE="./hosts.txt" OUT_DIR="./reports" TS="$(date +%F_%H%M%S)" mkdir -p "$OUT_DIR"

DISK_WARN=80 DISK_CRIT=90 LOAD_WARN=2.0 RAM_WARN=85

alert() {

echo "ALERTE : $*" >&2 }

check_host() { local host="$1" local user="$2"

echo "" echo "== ${host} =="

if ! ssh "${SSH_OPTS[@]}" "${user}@${host}" "echo ok" >/dev/null 2>&1; then alert "${host} injoignable en SSH" echo "${host};ssh;DOWN" >> "${OUT_DIR}/status_${TS}.csv" return 0 fi

local uptime uptime="$(ssh "${SSH_OPTS[@]}" "${user}@${host}" "uptime -p" 2>/dev/null || true)"

local load1 load1="$(ssh "${SSH_OPTS[@]}" "${user}@${host}" "awk '{print $1}' /proc/loadavg" 2>/dev/null || echo "0")"

local ram_used ram_used="$(ssh "${SSH_OPTS[@]}" "${user}@${host}" "free | awk '/Mem:/ {printf("%.0f", ($3/$2)*100)}'" 2>/dev/null || echo "0")"

local disks disks="$(ssh "${SSH_OPTS[@]}" "${user}@${host}" "df -PTh | awk 'NR>1 && $2 !~ /tmpfs|devtmpfs/ {print $6";"$5";"$7}'" 2>/dev/null || true)"

{ echo "host : ${host}" echo "uptime : ${uptime}" echo "load1 : ${load1}" echo "ram_used_pct : ${ram_used}" echo "disks :" echo "${disks}" | sed 's/^/ - /' } | tee "${OUT_DIR}/${host}_${TS}.txt"

awk -v l="$load1" -v w="$LOAD_WARN" 'BEGIN{exit (l>w)?0:1}' && alert "${host} load élevé : ${load1} > ${LOAD_WARN}" || true

if [ "${ram_used}" -ge "${RAM_WARN}" ]; then alert "${host} RAM élevée : ${ram_used}% >= ${RAM_WARN}%" fi

while IFS=';' read -r mount usedp path; do [ -z "${mount}" ] && continue local used="${usedp%%%}" if [ "${used}" -ge "${DISK_CRIT}" ]; then alert "${host} disque critique

Ajouter un check de service critique (systemd)

Tu veux savoir si nginx, ssh, docker sont actifs, sans te prendre la tête.

Ajoute dans le script, après le ping SSH :

bash services="ssh nginx docker" for s in $services; do state="$(ssh "${SSH_OPTS[@]}" "${user}@${host}" "systemctl is-active $s 2>/dev/null || true")" if [ "$state" != "active" ]; then alert "${host} service down : ${s} = ${state}" fi done

Oui, et si ce n’est pas systemd (Alpine avec OpenRC, vieux Debian, conteneur), tu adaptes. Mais l’idée reste.

Alertes propres : mail, ntfy ou Telegram (simple, efficace)

Le plus minimal, c’est le mail via mailx. Mais perso, pour du « vite fait bien fait », j’aime bien ntfy.

Exemple ntfy.sh

Dans alert() :

bash alert() { local msg="$*" echo "ALERTE : $msg" >&2 curl -s -X POST -d "$msg" "https://ntfy.sh/ton_topic_monitoring" >/dev/null || true }

Et voilà. Tu reçois des push sur mobile si tu as l’app.

Cron : exécuter toutes les 5 minutes

Édite la crontab :

bash crontab -e

Ajoute :

cron */5 * * * * /home/superviseur/monitoring/monitor_ssh.sh >> /home/superviseur/monitoring/cron.log 2>&1

Petit détail important : si tu relies ça à des alertes push, pense à éviter le spam. Deux solutions simples :

• n’alerter qu’en cas de changement d’état (UP vers DOWN, etc.)
• regrouper les alertes dans un seul message par run

Là, notre version est brute. Ça fait le job. Mais oui, ça peut parler un peu trop.

Variante « encore plus minimaliste » : une seule ligne par serveur

Si tu veux juste un tableau lisible, tu peux sortir une ligne style :

bash ssh user@host 'echo "$(hostname);$(uptime -p);$(awk "{print $1}" /proc/loadavg);$(free | awk "/Mem:/ {printf("%.0f", ($3/$2)*100)}")%"'

Tu mets ça dans une boucle, tu rediriges vers un CSV. Et tu as ton mini dashboard.

Ce que tu gagnes, ce que tu perds (soyons clairs)

Tu gagnes :

• zéro agent
• déploiement immédiat
• facilité de debug
• portabilité énorme
• contrôle total sur ce qui est exécuté

Tu perds :

• métriques temps réel fine
• auto découverte
• graphes natifs
• gestion avancée d’événements
• scalabilité « très grosse infra » sans optimiser

Pour beaucoup de freelances, petites équipes, ou projets clients, ce compromis est parfait.

Petit bonus : garder ça propre dans un repo

Tu mets ton dossier monitoring/ dans un repo Git privé, avec :

• monitor_ssh.sh
• hosts.txt (ou un hosts.example.txt)
• README.md
• une doc rapide « comment ajouter un serveur »

Si tu veux, tu peux même publier une version anonymisée sur GitHub et la lier sur ton portfolio. Sur monblog-sa-abasse.blogspot.com, je partage souvent ce genre de workflow simple qui améliore la qualité de service sans complexifier la vie, donc si tu veux d’autres scripts sysadmin productifs, tu peux garder le site en favoris et passer de temps en temps.

Conclusion : le monitoring SSH minimaliste, c’est un filet de sécurité

Ce n’est pas glamour. Ce n’est pas un « observability stack ». Mais c’est un filet de sécurité qui tient sur quelques fichiers, que tu comprends, que tu dépannes en 2 minutes, et qui marche même dans des environnements un peu pénibles.

Si tu devais retenir une approche :

1. clés SSH dédiées
2. checks simples : SSH, disque, RAM, load, services
3. alertes basiques mais utiles
4. cron, logs, et un minimum d’historique

Et ensuite seulement, si l’infra grossit, tu passes à plus lourd. Mais au moins tu ne pars pas de zéro.

Questions fréquemment posées

Pourquoi choisir un monitoring sans agent via SSH ?

Le monitoring sans agent via SSH offre une simplicité et une robustesse accrues en évitant l'installation de services supplémentaires, la gestion de ports ouverts, et les dépendances complexes. Il s'intègre facilement dans des environnements verrouillés ou petits, tout en fournissant des checks essentiels sans surcharge.

Quels sont les prérequis pour mettre en place un monitoring minimaliste SSH ?

Il faut disposer d'une machine de supervision (VPS, serveur interne ou laptop) avec une clé SSH dédiée créée via ssh-keygen, puis déployer cette clé sur chaque serveur à surveiller avec ssh-copy-id. Il est aussi recommandé de durcir l'accès SSH sur les serveurs cibles pour renforcer la sécurité.

Quels types de checks peut-on réaliser avec ce monitoring minimaliste ?

Les checks essentiels incluent la vérification de la disponibilité du serveur, l'espace disque disponible, l'utilisation mémoire (RAM), la charge système (load), l'état des services critiques, ainsi que des options comme le suivi des certificats TLS expirants ou des mises à jour de sécurité en attente.

Comment sécuriser les accès SSH utilisés pour le monitoring ?

Sur les serveurs surveillés, il est possible de restreindre les accès dans le fichier ~/.ssh/authorized_keys en limitant les IP sources autorisées, en interdisant l'ouverture de pseudo-terminaux (no-pty), et en désactivant le forwarding d'agent, de ports et X11. Ces mesures renforcent la sécurité tout en permettant les checks nécessaires.

Ce monitoring SSH sans agent peut-il remplacer Zabbix ou Prometheus ?

Non, ce système minimaliste ne vise pas à remplacer des solutions complètes comme Zabbix ou Prometheus. Il s'agit plutôt d'un filet de sécurité léger et pragmatique qui fournit des alertes basiques et un état de santé lisible pour des infrastructures petites ou spécifiques où simplicité et fiabilité priment.

Comment fonctionne le script bash pour les checks via SSH ?

Le script bash se connecte aux serveurs via SSH, exécute des commandes standard pour récupérer des métriques clés, analyse ces résultats, écrit un log localement, et déclenche une alerte si certains seuils critiques sont dépassés. Cette approche garantit un monitoring simple mais efficace sans agents supplémentaires.