I'm not sure about that. Since the VM is virtual, you could say that they don't own the VM, they own the machine the VM runs on. They can control and manipulate the VM via the container for running them (Xen in this case). But since the VM doesn't physically exist, it could be argued that they don't actually own it, they only rent server capacity to run the VM.
Now, I know that you could similarly argue that they were only reading/modifying a disk image that existed on their server, but that isn't as much fun to argue.
I think that everyone here can agree that this was a dumb move by Rimuhosting. And I'm not sure what the contractual arrangement is when you buy a VPS from them... but what they have posted online doesn't make this very clear.
The question of ownership is interesting in this era of cloud computing (and not at all clear). I think it's clear that they own the bare metal. I think it's also clear that you own your data. However, where those mix is an interesting question. At what point is their (uninvited) intervention in a customer's VM warranted outside of their normal management options in the VM container (Xen)? At what point is the intervention too much?
Does the company matter? I can imagine everyone being up in arms if Amazon tried the same thing with an EC2 instance.
Of course this could all be alleviated by using a dedicated server... but even then, if the hosting company owns the hardware, would it be okay for them to pull a hard drive, and add themselves as root? Never. Ever. But this is effectively what we're talking about. The only difference is that with a dedicated server your actions don't affect others. In a VPS environment, your actions can affect others. But I think that there are far better methods for controlling this than "breaking in" to a customer's VM.
So, this particular event shows a lack of good judgment on the part of the tech in question, and a lack of common courtesy in not notifying the customer of the issue in advance of taking action...but it is not an illicit act. No "break in" happened here. The options a hosting provider has when things are behaving badly are pretty much all things that a customer will not like. When a dedicated server is compromised and is being used to send spam, for example, the host will simply firewall the whole thing off from the world, shutting down all services. This happens all the time; the effected customer blames the host, sometimes. Sometimes there are other options. In this case, the host opted to turn off one (disputably) offending service rather than kill the whole host. I think we can all agree this wasn't the best way to handle it. Thus my assertion that this is a tech having a bad day (or simply one bad support tech at Rimuhosting, among mostly good ones).
Actually, I think the one thing I'm uncomfortable with is the illusion of propriety (ownership) Rimuhosting has given by saying "You are able to remove that if you are not comfortable with that.", in reference to the ssh key. This is a bit of a disconnect from the reality that under some circumstances, they will have to exert their ownership rights, and there's nothing you can do about it. At some point you just have to trust in the good faith of your provider. But the only alternative to doing what they did (assuming they, in good faith, thought Aaron's VM was damaging service for others), assuming they don't have the ability to throttle Xen instances on this particular machine (maybe it's too old to have that capability, I dunno, or maybe the tech in question didn't actually understand those capabilities; the tech could be new...everybody starts somewhere), would be to turn his VM off completely. From the techs perspective he may have thought he was doing Aaron a favor by leaving mail and other services running.
Again, I'm not arguing it was good judgment on the part of the tech. But to say that Rimuhosting broke into their own machine is ridiculous.