Security Model of Online Server Monitor

The service uses a local agent model. Telegram is the control interface, the backend queues signed actions, and the agent on your Linux server reports metrics and executes only allowlisted maintenance tasks.

The backend stores server records, pairing tokens, recent metrics, thresholds and queued commands. It sends Telegram messages and accepts HTTPS requests from paired agents.

The agent reads local Linux health information, sends heartbeat and metrics over HTTPS, checks detected systemd services, and polls for signed command requests.

• Hostname and server identifier.
• Operating system, kernel and uptime.
• CPU, RAM, disk, inode and load average metrics.
• Discovered web domain names and SSL certificate expiry dates.
• Detected systemd service names and states.
• Telegram chat identifiers needed to deliver bot messages.

• No SSH passwords.
• No root passwords.
• No private SSH keys.
• No hosting panel passwords.
• No database passwords.
• No email passwords.
• No FTP passwords.
• No cloud provider credentials.
• No arbitrary public shell access.

The backend does not open SSH sessions to monitored servers. The installed agent connects outward over HTTPS, which keeps monitoring separate from password-based remote administration.

A pairing token is created in Telegram with /add_server, expires quickly, and is used only to register an agent. If the token expires, generate a new one.

Maintenance actions are queued by the backend, scoped to one server, short-lived, and handled by the local agent. Reboot requests require confirmation before they are queued.

• Restart detected systemd services.
• Clean old journal logs with controlled commands.
• Run logrotate through the agent path.
• Request a confirmed reboot.
• Change alert thresholds from Telegram.

Log cleanup is not a free-form shell box. It should use controlled journal and log rotation actions so Telegram users cannot submit arbitrary commands.

The main goal is to avoid turning a Telegram bot into an SSH password vault or a public command runner. The backend should not need reusable server login credentials, and the Telegram user should not be able to type arbitrary shell commands through chat.

A Telegram group can be useful for shared visibility, but every person in that group may see status cards and action buttons. Add the bot only to groups where participants are trusted to see server names, service states and maintenance prompts.

The local agent secret is server-side authentication material. Treat it like an API credential: do not paste it into support chats, screenshots, public tickets or documentation. If you suspect it leaked, reinstall the agent with a fresh pairing token and remove the old server record.

A restart button should restart a known service, not execute an arbitrary string. A log cleanup button should run a predictable cleanup action, not accept user-provided paths. This keeps Telegram actions narrow enough to review and explain.

If a monitored server is compromised, stop the local agent, remove or rotate its local secret, and inspect queued commands. If a Telegram chat is compromised, remove the bot from that chat, revoke the related server records, and pair the server again from a safe chat.

• Confirm no SSH passwords are stored in the bot.
• Confirm only trusted chats can manage servers.
• Confirm reboot requires explicit confirmation.
• Confirm unknown services are not exposed as restart buttons.
• Confirm support requests do not include private keys or passwords.

Remove the server from service storage and stop the local agent on the monitored server. If a server is compromised, revoke or rotate the local agent secret by reinstalling with a fresh pairing token.

• Use maintenance actions only on servers you control.
• Keep pairing tokens out of public chats.
• For data handling details, read the privacy policy.
• For legal usage rules, read the terms of use.