You'll want to:

  echo "" > /root/.ssh/authorized_keys2
  rm -rf /usr/local/rtm
  echo "" > /etc/crontab
  killall -9 rtm

Edit: Oh and on Windows you need to hit up Add/Remove programs and uninstall 'Corp SSH'

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

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

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.

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

> 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.

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.

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

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'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.

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.

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.

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

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).

"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.

Could you point to the fault?

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

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

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

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.

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.

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...

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 only issue I did have (and might be worth considering) was probably to be expected: they seem to be very on top of network issues and won't hesitate to terminate your server if something is suspicious. I was running a game server (Call of Duty 1) that had a bug that allowed someone to maliciously redirect packets to someone else (not a spectacular amount, but enough that when they did it with ~10 servers it would cause problems for the victim) and because we were part of an attack the server was shut down and they wouldn't return it to me without agreement that we'd wipe the "infected" server -- even though it wasn't infected, it was a software bug that we could resolve if we had server access.

Definitely worth using for unimportant things, but definitely not worth risking it on production.

We had a UDP flood from an OVH server, and they said they contacted the customer to fix this issue. I checked the IP and it was still running a splash page.

A couple days later we were attacked again by the same IP. After reporting this to OVH again they finally took the server down.

I just have ONE objection: If you plan to do something professional with them, just, don't.

For them, every client is dispensable (even if you rent 200 servers or more). They won't hesitate a single second to delete your server if they have a small problem with you (for example, getting DDoS'd).

OVH have shutdowned servers from a small association who was offering hosting, on the basis that the server made 3 DNS request to some "weird" server in Poland, for example.

So, it's okay for personal stuff, and, backup everything- your data is definitely not safe on their servers.

I remember others example too, i'll try to find the stories and post them here.

I choosed Kimsufi because of the possibility to rent RIPE IPs… they removed the possibility without telling anybody…

It keeps on saying:

Erreur : Vous ne pouvez accéder à cette page tant que la console est en phase de beta.

(the german one is strangely enough more expensive)

There's an issue in that (as I understand it) in Germany you have a quote VAT inclusive prices but in Ireland you can leave off VAT for goods aimed at businesses. (The same is true in the UK).

Even taking that into account there's about a 20% price bump from Ireland to Germany, though!

(Edit): the French site seem to take everyone, and has lower VAT percentage

They suck in the support/soft service department, but frankly if you know what you are doing, you don't need it with OVH. They have pretty much automated everything. If there is a hardware fault they are on it before you even know.

Just a few days ago 24 servers failed due to cooling issues. They sent an army of 8 nerds to handle the issue: http://status.ovh.net/?do=details&id=3736 Resolved in 40 minutes.

I'm on a plan that isn't available anymore, but it was sub-20eur/month, and the hardware seems to be P4 3ghz, with 2GB ram and 200GB disk. And the performance has been plenty for me.

Then the kimsufi brand was a bit more separated from the normal ovh offering. The kimsufi was branded a bit more on the do-it-yourself side, with no support apart from hardware failures. It seems they've now merged the kimsufi brand back to the main ovh site.

And I have been a fairly happy customer. I think I've had a couple of short network outages, but nothing alarming. My uptime is at 732 days.

not true. http://www.ovh.pl/serwery_dedykowane/kimsufi.xml https://www.ovh.co.uk/dedicated_servers/kimsufi.xml etc. They operate from France, but have offices in Poland and all over Europe. there are no admins in here though AFAIK, every support request is just forwarded to France.

Support is essentially non-existant, it's at best "Don't call us unless the box is power dead". But for the price, that's fine, if it dies or starts showing a hardware fault, I'll cancel that one and order a replacement.

But atom for a server? Yuck. I'd rather have a real server cpu under virtual xen instead.

Besides that, Atom CPUs are quite fast for many kinds of tasks...sometimes faster than a virtualized "real CPU" for server workloads, like serving websites, databases, and email. My servers at Amazon often have "sluggish" periods throughout the day, despite them being quite low-load systems; it seems to be because the other servers on the same CPU are working harder. Shared resources can be a curse, though I usually don't mind.

Atom was designed to be crippled from the start to save power.

You must be running smaller, single site servers, possibly with mostly static content?

I am willing to bet atom would choke on non-indexed searches, compression/decompression and encryption.

The Intel (and now AMD) aes in hardware acceleration for ssl is worth it alone on a real cpu vs atom.

But sure, for 99% of all websites, CPU is not the issue.

https://uptano.com

We're not trying to be the absolute cheapest, just trying to be the company we wished to exist.

Question: Do all my 8 VSs have to reside on the same host? If the host goes down, it will take all my VSs with it. Any way of getting the same number of VSs but distributed across hosts?

You can of course setup redundancy by creating multiple servers on different hardware nodes.

Virtual servers on Uptano are managed via the web interface and each includes a public IP address. Most ISPs do limit IPs per server. Also, our limits are higher than pretty much anyone needs per server.

BTW, I'm thinking of webnx's special deals as the best on the west coast. Competitive on the high end. No where near as cheap on the low end.

http://www.lowendbox.com/tag/dedicated-server/

I pay roughly $78 a month for this: http://serverbear.com/benchmark/2012/09/28/NkHEVWXUAKwf4USF

Limestonenetworks is also good in Texas, but starter servers are over-$100 for a similar 2-drive/RAID-1/8GB RAM box.

OVH competes with Online (former Dédibox, by Iliad (Free)) and the prices goes low... http://online.net/fr/serveur-dedie

Welcome to France, IT paradise.

I actually use OVH on some older Kimsufi plans. I'm kinda disappointed actually with these new plans as they got rid of the Core i5/i7 processors which were a bargain for the amount of CPU power you got for the money.

http://serverbear.com/9756/ramnode

RamNode best coupon actually offer 31% off all the time! I'm using LEB service extensively as I'm offering budget Managed WordPress Hosting.

http://kittysensei.com

Performance wise, RamNode is among the best LEB provider along with company like BuyVM, ServerDragon and Hostigation.

I thought I'd be able to get access to a server within a day or so of registering and paying. Oh was I wrong. Before even charging my credit card they requested an officially stamped/signed proof of address (issued by the town I reside in in Germany), a scan of my credit card (!), and a scan of my German national ID card. They were friendly enough to let me substitute my passport since I don't have an ID card. I was travelling at that time and had to have the proof of address mailed to me, so it took over a week. Ironically, all that jazz was required because I was travelling - apparently signing up for a server with a German credit card from a non-German IP is "suspicious".

Two weeks after signing up I finally had access to the server. Stupid me thought they would make it easy to stay their customer. Instead, I have to enter my credit card details into their Web0.9 backend system once every month (or once every year if paying annually). To make sure I don' forget I receive a reminder email once every day for the last 14 days of every month. The only alternative is to set up a recurrent wire transfer to them and then cross you fingers that it always gets booked correctly on their end.

I see that many others here report on having an account with them. Am I the only one who finds it so difficult to give them my money? I'm really happy with the server (I use it to compute meshes from worldwide elevation data sets for our geographical iPhone case creator on http://www.printablegeography.com/creator) but giving them money is just waaay too hard.

edit: typo

I kept wondering what's taking so long, only to receive an email on Monday morning saying "Unfortunately, we only provide services to Republic of Ireland or UK customers at the moment" and asking for "a copy of your ID (passport, driving licence)" and "a proof of address (utility bill)" to be sent over email(!!). I am in the UK, but they can bugger off.

1) 100mbit connection 2) Core i3-2130 w/16 GB ram 3) 2x1TB sata configured as software raid-1

To be blunt, $79 is an absurdly cheap price for that kind of hardware and connectivity. I'm more than willing to put up with an occasional network problem (hurricane Sandy disrupted some of their peering) and a management portal that is not quite as featureful as I'd like.

Well I dunno... Europe has some really cheap (and reliable) server hosters, for instance:

http://www.hetzner.de/en/hosting/produkte_rootserver/ex4

49€ purchases you:

- i7-2600 Quadcore - 16 GB RAM - 2 x 3 TB SATA (Software-RAID 1) - 100 Mbit

I think the US/Canadian prices are simply inflated.

http://www.ovh.com/ca/fr/serveurs-dedies/

The same server is $49/month + tax now.

$40 per month for an Atom based server (which is surprisingly capable). They have an advertised traffic quota, but in my experience they don't check how much traffic you've used. I used to run a file host on boxes from Interserver - I used to push about 60TB per month over 3 boxes.

One thing to check is that some of the budget hosts will oversell their networking in such a way where your port links at one speed, but you're unlikely to ever see that speed for long periods of time.

0:http://en.m.wikipedia.org/wiki/Warez_scene

That said, OVH is extremely popular with those involved in piracy more broadly, and their servers are used extensively as seedboxes.

Put ISPconfig on it if you want a free control panel: http://www.ispconfig.org/

What do you mean? It comes with 5TB of network traffic, and they don't charge for additional traffic, merely limit your speed:

>> The server is connected at 100Mbps. The bandwidth is 100Mbps guaranteed up to 5TB of monthly traffic. Beyond 5TB of monthly traffic, the bandwidth is 10Mbps guaranteed.

I am also very suspicious because the uplink speed for the fast ethernet switch the server is on can not support "100Mbps guaranteed" for every port on the switch simultaneously.

https://www.ovh.co.uk/dedicated_servers/kimsufi.xml#bandwidt...

It has mostly replaced cable tv for everyone that uses it.

Intel Celeron/Atom 1.2+ GHz 1 Core 64 bits, 500 GB HDD, 100 Mbps, 1 IPv4, /64 IPv6, 5TB traffic (after 5TB - they will slow you down)

Paying about 20 Euros / month or so.

At one point I was considering finding a dedicated server in the U.S. but I was surprised: apparently the prices weren't that competitive compared to OVH (I was looking for a full dedicated box, not a shared one nor instances).