I am at a total loss for how any of this would require root access. I'm not sure any component of the system online or offline would need root; I'm absolutely certain the web app wouldn't. You don't need IPC tricks.

I'd be less comfortable with the contraption that pushes stats out from the hosts. I don't agree that it would be more secure.

Virtually any system you could imagine to solve this probably would almost by mathematical necessity be more secure than giving out a root SSH login, which is the funny thing about this thread.

Mathematically, giving root login to person X is never more secure against person X than any other interaction with person X. I think the idea was regarding other people. With SSH, what you are exposing to those who lack the key is SSH, which is well hardened.

If you set up a web service naively and run it as root, you have a weaker surface more exposed in exchange for more security against a mostly trusted party (who already has physical access).

Of course, I'm not sure what kind of statistics can't be gathered by anyone but root; even if there are some (and there probably are in some configurations), I don't see why they couldn't be polled by root in a cronjob and dumped in a log file that's readable by a (specific, if you care) non-root user and fetched over SSH by that non-root user, &c. So, on the whole, I agree that there's no reason to give out root; but it's not a crazy notion that there are things worse than giving root to person A, with respect to your security against person B.

Accidentally revealing server stats because of a bug handling a trivial authentication token is less of a big deal than giving a third party root shell access to your server, is my point.

But a bug in a web-server running as root might lead to privileged execution of arbitrary code.

It's certainly true that a bug in the authentication code that incorrectly grants access is of substantially less severity than a leak or abuse of root key/password.

Obviously you have to compare the likelihood of remote code execution in nginx/apache to that of ssh. Nginx is much, much simpler than OpenSSH.

And, obviously, giving a third party remote root SSH access to your server already is a glaring vulnerability.

The nginx package on Debian has more LOC than the openssh-server package. Apache, of course, is huge. This doesn't map perfectly onto complexity, but gives some indication that "much, much simpler" may not be entirely accurate.

Moreover, the default SSH setup gives you everything you need for the (still undesirable) current setup, and is almost certainly running regardless. The default nginx install does not - you have to tweak setup to lock it down and add stuff to actually fetch the content, and since that (we have stipulated) has to be done as a privileged user there is room for error.

Again, giving a root login key to OVH means no security against OVH, and relying on their securing the key. I agree that this is a bad idea. Depending on the amount you trust OVH and their security, it may be more secure against people other than OVH than certain specific alternatives (perhaps all the alternatives if you artificially constrain yourself into running a single process as root that talks to the outside).

Nginx is much, much simpler than OpenSSH.

This seems an absurd digression.

"Simpler" is surely something we could quantify, and while LOC tracks it loosely it's obviously not the same thing, and SSH is almost certainly more complex per LOC than typical. Where that becomes "much" simpler, and from there "much, much" simpler is fundamentally subjective, but if you want to put up some numbers based on some other metric feel free, and we can take this further; it strikes me as unlikely that a smaller system would fall in the range I would label "much, much simpler" - but I am not an expert on either piece of software.

Regardless, it is a digression. The complexity of openssh is not at issue, unless you are advocating they not use openssh at all. Nginx + openssh is absolutely unequivocally not "much, much simpler" than openssh.

Adding nginx interfacing with new, privileged code does add significant complexity that using-the-already-present-ssh does not. Some of this complexity is exposed to those who do not have any credentials. Therefore, the security of the system toward those attackers may go up for those reasons more than it goes down because of the existence of an additional set of root credentials they do not have easy access to. This is presuming that OVH's security is sufficiently trusted; a big assumption, to be sure.

We're still agreed that the best approach is some kind of reasonable hand-off of data from the privileged process that reads the data and the external access of whatever form, presuming any of the data really needs privileged access in the first place.

The reasoning you're using here about exposed attack surface and complexity is faulty. You are better off exposing a trivial interface with nginx or Apache than in giving someone SSH credentials.

> The reasoning you're using here about exposed attack surface and complexity is faulty.

Could you point to the fault?

I could, easily, but we're pretty far to the right margin. If you'd like to email me, I'm happy to explain the reasoning.

I apologize up front for the OT post, but I have never seen a thread extend this much to the right.