>I think the idea with rtop in particular is not to have it running headless ever, but you'd only use it interactively. There would not be a "monitoring server"

>I think the idea with rtop in particular is not to have it running headless ever, but you'd only use it interactively. There would not be a "monitoring server", at least not running rtop. Aah. I misunderstood. I've not figured out how to run a cluster without giving myself through one of my workstations or a jump box or something ssh access to all of them, so I'm generally okay with a program that automates some of that SSHing I do, like ansible; far more comfortable than I am with a box that is running some monitoring web frontend having any kind of access to my backend servers. (I usually try to give that box read-only access to the storage that another server which queries the agents writes to.) To be clear, I'm not super comfortable with this situation, but I don't see any way around of having my own login everywhere, or of making it so that if I do have my own login everywhere, my logging in from a compromised machine is not a game over. (as an aside, you and I mean different things by headless; usually when i say 'headless' - i mean 'the video port is disabled or unused' - all the servers I use are managed via serial console, and I would call them 'headless' - I think my usage is more standard than yours, but I could be wrong.) >If you wanted to use it this way, note that rtop currently sshes around places and then execs a bunch of local commands. That gives me both the heebies and the jeebies. I'd much rather deploy an rtop-server compiled binary and restrict the ssh key that rtop uses to connect with something like "command=/usr/bin/rtop-server" in the .ssh/authorized_keys file for the local user that will accept rtop-initiated ssh connections. Yeah, that is what I meant by "some sort of agent." - I personally make rather extensive use of the forced-command bit in ssh.