jhodgkin/homelab-monitor
1
0
Fork 0
Code Issues 1 Pull Requests Actions Packages Projects Releases Wiki Activity

SSH-based collector for .180 (OMV) and .171 (ripper) #8

New Issue
Closed
opened 2026-07-12 20:11:03 -06:00 by jhodgkin · 2 comments
jhodgkin commented 2026-07-12 20:11:03 -06:00
Owner
Copy Link
Copy Source

Proxmox doesn't see these two bare-metal boxes. Add a generic SshHostCollector reading df/free/uptime over the existing SSH trust (read-only commands only). Needs: SshHostCollector implementing the same collector interface as ProxmoxCollector.

Proxmox doesn't see these two bare-metal boxes. Add a generic SshHostCollector reading `df`/`free`/`uptime` over the existing SSH trust (read-only commands only). Needs: `SshHostCollector` implementing the same collector interface as ProxmoxCollector.
jhodgkin commented 2026-07-12 20:36:50 -06:00
Author
Owner
Copy Link
Copy Source

Starting this one: adding a generic SshHostCollector for .180 (omv) and .171 (ripper), the two bare-metal boxes Proxmox cannot see. Will reuse the existing SSH trust already used elsewhere in the homelab (read-only commands only).

Starting this one: adding a generic `SshHostCollector` for `.180` (omv) and `.171` (ripper), the two bare-metal boxes Proxmox cannot see. Will reuse the existing SSH trust already used elsewhere in the homelab (read-only commands only).
jhodgkin commented 2026-07-12 20:41:43 -06:00
Author
Owner
Copy Link
Copy Source

Done and deployed. SshHostCollector added, dedicated ed25519 key generated on CT122 (never leaves that host beyond the mounted container path), installed on omv and ripper with a forced authorized_keys command — the server always runs a fixed read-only stats script regardless of what the client requests, so a leaked key still can't do anything beyond producing those stats. Details + how to add another SSH-monitored host in docs/ssh-collector-key-setup.md.

Verified end-to-end: /api/hosts now returns ssh:omv and ssh:ripper with live CPU/mem/disk, numbers cross-checked against raw free/df output on both boxes. CPU is a load-average approximation (documented in code) since true utilization needs two /proc/stat samples.

Note: diskPaths in config/hosts.yaml is descriptive only — the remote forced-command scripts have to be updated by hand to match (documented, only 2 hosts so not worth automating yet).

Done and deployed. `SshHostCollector` added, dedicated ed25519 key generated on CT122 (never leaves that host beyond the mounted container path), installed on `omv` and `ripper` with a **forced authorized_keys command** — the server always runs a fixed read-only stats script regardless of what the client requests, so a leaked key still can't do anything beyond producing those stats. Details + how to add another SSH-monitored host in `docs/ssh-collector-key-setup.md`. Verified end-to-end: `/api/hosts` now returns `ssh:omv` and `ssh:ripper` with live CPU/mem/disk, numbers cross-checked against raw `free`/`df` output on both boxes. CPU is a load-average approximation (documented in code) since true utilization needs two `/proc/stat` samples. Note: `diskPaths` in `config/hosts.yaml` is descriptive only — the remote forced-command scripts have to be updated by hand to match (documented, only 2 hosts so not worth automating yet).
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
jhodgkin
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: jhodgkin/homelab-monitor#8
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?