That seems a little silly to me. If they control the hardware, they basically have root already. They shouldn't need root to investigate the alleged problem, of course, but the level of trust you need to grant your VPS provider is essentially the same as giving them root.
You could have most likely also given them an account and appropriate sudoer rights.
After the server that you lease from them (I omit calling it "your" server on purpose) continued to have issues that impacted customers outside of yourself, they logged into the box and (based on your article again) seemed to resolve the root (pun intended) issue rather quickly. This seems to have occurred 2-3 months after the initial root access request.
The response of shutting off Apache was a bit extreme, but given the history, not terribly surprising either.
Particularly interesting to me is that they had the technical means to restrict the virtual machine via a configuration change, but instead chose to "trespass".
According to their terms and conditions, "Misuse of System Resources" is prohibited, but their only listed recourse is to "restrict, suspend, or terminate" the account. It is arguable that they had no right to access the data for his server, since they had other means to restrict or otherwise limit the VPS (which they already did). They should have just paused the VPS without accessing the data and send him an email. Adding your SSH key to a customer's server without notice or approval is a good way to tarnish a reputation among the hacker crowd (their customer base). I wouldn't allow them to have root access either.
Their argument would have been much stronger had they provided any sort of evidence of CPU load of his server. However, that probably would have shown how oversold the machine really was.
Of course not, but the landlord does generally have the right to enter the property if there is an emergency (water is dripping from your unit into the unit below you).
The hosting company here did not just drop in to see if he had any good scripts or pr0n to steal, they did so after resource issues.
How do you know? They rooted the system against the explicitly stated wishes of the customer. What makes you think they wouldn't do other sketchy things while they're at it?
So, it is always better to just pause the entire VM and let the owner deal with it. (Sure, you can offer to help fix it, that's good customer service, but just don't take it upon yourself to do it without approval).
However, in this case, the hosting company has another option available: pause the VM.
It is also easier to do technically than shutdown the VM, edit the filesystem, restart the VM, find the errant process, change the configuration, etc....
This analogy doesn't really hold. "Your" apartment gets special rights under the law in the US and probably other places. Those rights are actually pretty extreme (it takes months after they stop paying to evict someone in most states, for example), and you don't have those same rights or expectations of privacy within an office building, or anything else you rent or lease that isn't your domicile.
According to their terms and conditions, "Misuse of System Resources" is prohibited, but their only listed recourse is to "restrict, suspend, or terminate" the account.
Sounds, to me, like they restricted his account to one that wasn't running Apache.
But, I agree that they should have simply turned him off. Customers that don't want administrative assistance on the system should never have it imposed on them, and I would also prefer my provider never login to my systems (and I don't provide them with access to my systems; though I know that because they have access to the hardware, they always have root available to them; I rely on good faith to prevent them from doing harm or abusing my privacy).
However, that probably would have shown how oversold the machine really was.
While this is very often true in the VPS hosting industry, Rimuhosting has an otherwise very good reputation. It's pretty easy to know when you're on an oversold host, and it's not something I've ever heard Rimuhosting accused of.
In this case they definitely violated the societal norms and possibly their contractual obligations as well. I'd say that you have a pretty good expectation of privacy on a virtual _private_ server.
I don't particularly know anything about Rimuhosting. I know most places are oversold to a certain degree. I suspect that there isn't any way to make money in the industry if you're not.
You're dangerously close to whining, did you know.
Hmm. I'm sorry, but I don't see how this matters at all Sho. Do the ethics change based on whether you have a rootkit or you do everything by hand?
Pay $250/month for an account at Rackspace (or whoever) and you will be treated very differently.
Actually, the reason you pay $250 (more, probably) at Rackspace, is because they will login to your box on a regular basis to "manage" things. Rackspace is focused on "managed hosting"; they help you administer your system, which is why people pay a big premium for it. Most hosting customers have no idea what they're doing, and they need a lot of hand-holding, and a "grownup" to make sure things stay sane on their systems.
From the blog post:
> In December they set a CPU cap on my VPS.
Then from their response email to shutting down Apache:
> We can set it so that you get a fixed amount of CPU (and then we don’t mind how much CPU want to use).
My first reaction is, "Huh?" They state that they don't care about your local CPU usage if they bother to put a cap on your usage of the actual CPU. Yet they didn't do that. Instead they broke into his box to shutdown a rogue process that was 'using too much cpu.' That doesn't make any sense.
I'd be legitimately upset if they did that instead of
cat mykey.txt >> authorized_keysThen again, he never said he was using SSH keys, so maybe ...
Then you could have watched them investigate the problem.
1 - install screen and configure the collaboration on your server
2 - create a user on your server for the other person to login
3 - the other person logging in must be able to route directly to your server. The ip for the server must be public and SSHD listener must accept connect from anywhere.
4 - The other person can login and "collaborate" with your screen session whether you are logged-in/watching or not. The only security is to shut down your screen session or change your screen config file / stop the sharing.
5 - with screen you cannot interactively/quickly change modes between read-write, read-only, etc...
ShellShadow works as a client terminal relay. You setup a session between you and another user. You use the ShellShadow client (enhanced PuTTY) for your collaboration. There is nothing to setup and manage on your server. In fact your server is oblivious to the collaboration. One extra cool feature is this works with any terminal you can connect to: your Cisco router, your iPhone CLI, etc...
* Their cap failed to actually cap his CPU usage. In this case their incompetence is at fault.
* They failed to make the cap restrictive enough. In which case, they should have just further limited his max actual CPU usage.
* The box is actually well oversold on the number of clients that are on it, and there is no possible way to 'cap' someone's CPU usage to within a reasonable level while being able to allow that person to use 100% of their cap without issue. In this case, it's also their fault for over-selling the box and for misrepresenting what a cap means (and their policy regarding caps).