SSH Server Watchdog

Monitor remote servers via SSH — check service health (PM2, systemd, Docker), database status (MongoDB, MySQL, PostgreSQL), disk space, memory, and auto-rest...

Security Scan

The skill claims broad SSH monitoring for many services but actually contains a Windows/MongoDB‑focused watchdog, undeclared credential needs, and insecure usage patterns (password-in-expect, hard-coded paths/hosts), so its requirements and instructions do not match its description.

Purpose & Capability

The manifest and SKILL.md advertise generic SSH monitoring (PM2, systemd, Docker, MySQL, PostgreSQL, MongoDB) but the included code is a MongoDB‑focused Node.js watchdog targeted at Windows (hard-coded Windows paths, D:\ logs, 'net start/stop'), and even includes comments with a specific internal host (10.0.0.213) and SSH admin string. The implementation is much narrower and environment-specific than the description suggests.

Instruction Scope

Runtime instructions tell the agent to run SSH commands and optionally use expect with plaintext passwords (example expect snippet). SKILL.md instructs copying the included JS file to remote servers and running npm install and pm2 — which is consistent — but it also omits declaring the environment variables the script reads (TELEGRAM_BOT_TOKEN, TELEGRAM_CHAT_ID). The expect usage and examples encourage handling plaintext passwords and exposing credentials in commands.

Install Mechanism

No install spec in registry (instruction-only), but SKILL.md instructs the user to npm install the mongodb npm package on the target. That is a standard, traceable install mechanism (npm) — no arbitrary URL downloads — but it does write files to the target server and installs a persistent PM2-managed process.

Credentials

The skill declares no required env vars, yet the included script reads TELEGRAM_BOT_TOKEN and TELEGRAM_CHAT_ID from environment and uses local filesystem paths (C:\ProgramData..., D:\ProPower_System...) and a hard-coded default chatId. The SKILL.md also requires 'expect' locally for password SSH but 'expect' is not declared. These undeclared credential/binary requirements and hard-coded internal host/path values are disproportionate to a generic monitoring skill.

Persistence & Privilege

The skill instructs deploying a persistent PM2 process (pm2 start ...; pm2 save). That is expected for a watchdog and the registry flags do not force always:true. However, the persistent process will run with whatever privileges the user gives it on the target server (it executes service restart commands), so privilege and blast radius depend on how it's installed and which account is used.

What to consider before installing

This skill is suspicious because it claims broad SSH/server monitoring but only ships a Windows‑focused MongoDB watchdog with hard-coded paths, an internal host mention, and undeclared environment/credential needs. Before installing: 1) Do not use password-in-expect in production — it exposes plaintext passwords; prefer key-based SSH and avoid embedding passwords in commands. 2) Inspect and (preferably) modify scripts locally: remove hard-coded IPs, default chat IDs, and Windows-specific paths; set TELEGRAM_BOT_TOKEN/TELEGRAM_CHAT_ID explicitly and securely. 3) Test in an isolated environment first (non-production VM) to verify behavior and restart logic; limit auto-restart frequency to avoid restart loops. 4) Be cautious about granting the watchdog an account that can restart services — prefer a dedicated low-privilege service account. 5) If you only need generic PM2/systemd/Docker/MySQL/Postgres monitoring, this package does not provide that out of the box; treat it as a MongoDB/Windows artifact and only install after auditing and adapting its code. If you cannot audit code yourself, do not deploy it to production.

Server Watchdog

Monitor and auto-heal remote servers via SSH. Check services, databases, disk, memory — restart what's down, alert what's wrong.

Prerequisites

• SSH access to target server (password or key-based)
• expect available locally (for password-based SSH)
• Target server runs PM2, systemd, or Docker for service management

Quick Reference

Check PM2 services

ssh user@host "pm2 list"
ssh user@host "pm2 logs --lines 20 --nostream"

Check MongoDB

# Windows
ssh user@host "net start | findstr MongoDB"
ssh user@host "powershell -Command \"(Test-NetConnection -ComputerName 127.0.0.1 -Port 27017).TcpTestSucceeded\""

# Linux
ssh user@host "systemctl status mongod"
ssh user@host "mongosh --eval 'db.runCommand({ping:1})' --quiet"

Check disk & memory

# Linux
ssh user@host "df -h && free -h"

# Windows
ssh user@host "powershell -Command \"Get-PSDrive -PSProvider FileSystem | Select Root,Used,Free; \$os=Get-CimInstance Win32_OperatingSystem; Write-Output ('RAM: '+[math]::Round((\$os.TotalVisibleMemorySize-\$os.FreePhysicalMemory)/1MB,1)+'GB / '+[math]::Round(\$os.TotalVisibleMemorySize/1MB,1)+'GB')\""

Workflow

1. Diagnose — SSH in, check service status, logs, disk, memory
2. Identify — Parse logs for errors, crashes, OOM, or unclean shutdowns
3. Fix — Restart crashed services (pm2 restart, net start, systemctl restart)
4. Verify — Confirm service is back up and responding
5. Alert — Notify user via messaging with summary

Crash Analysis

When a service is down, check these in order:

1. Service logs — pm2 logs, journalctl -u service, Windows Event Log
2. Application logs — Check log files at configured paths
3. System events — OOM killer, unexpected shutdowns, disk full
4. Database logs — MongoDB: check mongod.log for Fatal ("s":"F") entries

MongoDB crash patterns

"s":"F" — Fatal error (crash)
"Unhandled exception" — Internal bug (often FTDC related)
"Detected unclean shutdown" — Process killed without graceful shutdown
"WiredTiger error" — Storage engine corruption

Auto-Heal Recipes

PM2 service restart

pm2 restart <service-name>
pm2 save  # persist across reboots

MongoDB (Windows)

net stop MongoDB
timeout /t 5
net start MongoDB

MongoDB (Linux)

sudo systemctl restart mongod

Deploy watchdog service

For persistent monitoring, deploy the included watchdog script:

1. Copy scripts/mongodb-watchdog.js to target server
2. Install: npm init -y && npm install mongodb
3. Start: pm2 start mongodb-watchdog.js --name mongodb-watchdog
4. Save: pm2 save

SSH with password (via expect)

When key-based auth isn't available:

expect -c 'set timeout 20
spawn ssh -o StrictHostKeyChecking=no user@host "COMMAND"
expect {
    "password:" { send "PASSWORD\r"; exp_continue }
    eof
}
'

Alert Template

🚨 Server Alert — [hostname]

⏰ Time: [timestamp]
❌ Issue: [service] is DOWN
📋 Cause: [crash reason from logs]
🔄 Action: Auto-restarted [service]
✅ Status: [service] is back online

📊 System Health:
• Memory: X GB / Y GB
• Disk: Z% used
• Services: N/N online