This for maintenance reporting. How do the hell they know if one of your HD has died ?

It's not mandatory. And the ssh key added enforces the source IP address of requests.

One way would be to publish a HTTP/JSON API for fetching a specific set of stats from a server given an authorization key, provide a reference implementation, and allow customers to build their own if they're not comfortable with that.

Root SSH logins don't seem like a particularly good solution for this problem.

Surprised to read this from a security guy.

1) discard time-tested crypto implementation

2) write your own.

3) run it as root so it can read sensors

4) feel safer

Everything aside, most of these colo machines are set to netboot in order to implement their rescue system. Never poked around, but wouldn't be surprised those DHCP requests hit other machines on the segment. OVH seem to be more sensible than most when it comes to network configuration, but I wouldn't be surprised this happens in other places (the difference between a $50 Ethernet switch and a $5000 Ethernet switch right there)

Edit: since some don't seem to understand the basics of security, or perhaps out of an ill-placed sense of loyalty: running a web server + CGI combo as root on an Ethernet segment exposed to other colo customers, in place of a 20 year old service designed for exactly this scenario, when its sole user already has hardware access (and reboot + netboot access) to the machine is fucking stupid. I'm making no argument here, just calling out terrible advice for what it is.

?!

Which bit didn't you understand?

Every single one of your numbered points.

1) discard REMOTE SHELL solely for OS statistics

2) write your own TINY WEB APPLICATION SERVED BY NGINX/APACHE

3) run it as SOME USER THAT can read STATISTICS DATA

4) BE safer

1.

> One way would be to publish a HTTP/JSON API for fetching a specific set of stats from a server

> given an authorization key

2.

> provide a reference implementation, and allow customers to build their own if they're not comfortable with that.

Implies 3: entire point of the implementation is to read sensors, which requires root, or further messing with the security properties of the base system (e.g. sudo), and expecting users to do this correctly.

So basically what you're advocating is to encourage users to run custom HTTP servers as root.

Edit: and I see you edited your comment, and now advocating running nginx as root.

I have no idea what you're talking about or who you think you're arguing with but it isn't me.

Especially amusing that whoever would say these crazy things you're saying would still be better off than giving remote root SSH away for stats collection.

Sheesh.

Hey, 'nknight, you appear to be hellbanned (starting 3 posts back). It seems to happen randomly to some people; you should just ping 'pg about it.

Edit Don't blame you. The hellbanning system Does Not Seem To Work.

I don't understand, from briefly looking at nknight's previous comments, I can't see a reason for that kind of punishment.

I'm not sure if you're aware or not, but you can fine-grain permissions to anything on the box however you like. There's even built-in documentation.

I do agree with your larger point that building your own here is undesirable, however the web server wouldn't have to have root by using IPC or other kinds of tricks.

In any case, wouldn't it be even more secure if the server just pushed stats outwards (syslog anyone?) instead of needing to accept any kind of commands via SSH/HTTP/S or otherwise?

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.

The SSH access is for deploying the rtm binary (setup, config, updates). Only one host is allowed to reach servers through ssh via the ssh key in question.

  # cat .ssh/authorized_keys2
  from="213.186.50.100" ssh-rsa AAAAB3NzaC[...]hBIuk57cDxs= root@cache.ovh.net

For harvesting data, the rtm binary is run by crontab, and does send msg. OVH are not polling the servers.

  # cat /etc/crontab
  */1 * * * * root /usr/local/rtm/bin/rtm 46 > /dev/null 2> /dev/null

If customers are not comfortable with that, they can opt out, according to the documentation (removing the ssh key and/or the rtm binary).

Why don't you use SNMPv3, which is purpose built for this stuff?

https://en.wikipedia.org/wiki/Simple_Network_Management_Prot...

And then why don't I find a large glass jar filled with live wriggling cockroaches and compete with my coworkers to see how many of them I can swallow whole?

SNMP is awful. SNMP implementations are scarier than web apps (though admittedly not as scary as SSH logins). SNMP is harder to secure. It would be much harder for customers to provide their own trusted implementation of SNMP. I could go on.

There's what SNMP was built for, and then what it actually does.

I've been (un)fortunate enough to implement it more than once. Only a certain class of clients demand it because they already have built a big SNMP infrastructure.

Porkchop might be a good starting point: https://github.com/disqus/porkchop

No. This is so their technicians can easily log into your servers and solve problems if you need them too. Lots of their customers are newbies so they sell technical help as a service.

It is documented here: http://help.ovh.co.uk/InstallOvhKey and http://help.ovh.co.uk/Intervention as well as the way to disable this "backdoor". Note that there is more information available if you switch to the French language...

While you are removing "backdoors", you secure your boot loader, right?

And I am sure you realize there is no way to secure windows server file system (off-line Password and Registry editors).

I usually don't worry about the NOC & DC staff, but since it is the topic here I am commenting.

The main reason I'm not so concerned is if they have physical access to the server they have root access anyway. At least this way I can see them logging in.

Ah yes, the "Systèmes d'exploitation".