New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
I skipped over all that, but probably number 4. You make things more complicated and totally annoying AF. While it is helpful to show the commands to reproduce, it's better to show actual output to show what took effect. You could have typo'd your initial steps resulting in a different result than you thought or that you're telling them to do, causing the issue.
😡
My amd64 computer lives in the basement closet and is accessed via SSH only.
HDMI port and VGA monitor cannot mix.
My servers are setup the same way.
No passwords, just SSH keys.
VNC disabled.
Good idea.
Agreed.
As a counterpoint to all this, I was once with a provider where we had either found a bug in KVM or in the guest Linux kernel (my guest was actually affecting the host negatively even when it looked idle by every metric). They wanted to poke at some sysctls and see if their observations changed.
They offered to give me their SSH key and a list of commands to add to a sudoers file; I could drive on via commands given on a text chat while we discussed on voice chat and they watched their end; or I could screen share and the previous chats (which we ended up doing since it was the most informative all around).
They had a legitimate interest in solving the problem (it was a kvm misconfiguration that somehow I managed to tickle yay), but they wanted the minimum required privileges.
Of course, they may have just asked me to put their key into root's authorized_keys (wouldn't do any good with
PermitRootLogin noanyhow) if they didn't know already that I was clueful. Or even asked for the root password. And, you know what, it would have been justified to ask as a troubleshooting measure, as I was inadvertently not using only my fair share and that needed to be corrected or else they would have been in the right to terminate me under the ToS/AUP.I realize that this is a very unusual case that is unlikely to happen to most (or hopefully even me again!). But it's worth a demonstration to help us remember that things are rarely black and white. And starting a thread the way this one was basically forces a binary world view that isn't fair to either the providers involved (especially named up front, without any supporting details) or the other members of LET.
This isn't the first thread like this over the years, and I'm (sadly) certain that it won't be the last... But we can at least all try to remember that most people aren't out to get everyone else. Most of us are in it for the hobby of it, providers and users alike. There's not all that much difference between the two sides, quite often.
And if you think someone's acting maliciously, provide evidence. Otherwise we end up with pages of thread that just waste our collective time and we don't get to do cool things with low end services.
I generally have PermitRootLogin set to no in my sshd_config, only allow public key auth for the normal user accounts, and have root's password disabled outright.
But then, I've been doing this for many years and know it's a good way to keep out interlopers from across the internet.
Sure, you can always boot from a live CD to set a password (or a few other ways), but that's not the same at all as just having someone give you a (nonexistent) login.
Lets establish few variable here:
Simulate situation:
Customer contacting provider and asking to fix XYZ problem. He shows all evidence that something is wrong on provider side. Usually customer initially engagea L1 support agent. If L1 deems evidence enough to bother L2 agents, be pass ticket to them. L2 has access to node. Support contacts customer by asking if server could be taken down to recreate the cause of issue.
Usually answer is "yes". Now L2 stops server, mounts image and access server data.
That's it. And such instances are very rare as services is self-managed.
Asking password from customer indicates one or more of these points:
Let me chime in on this.
Although we offer a completely unmanaged service, we focus on the network and the host node. Everything else falls within the customer's scope.
At times, some customers might be installing scripts that modify some OS files and that could result in a plethora of things, like breaking the networking, or ssh, etc.
The amount of useful information in a ticket varies, but it's mostly "my server is down, fix it"...
Now, if all the other servers are fine, and working as expected, then my first assumption would be that it is an issue from within the VPS itself. The only way to investigate, although not really part of our support plan, is to access the VPS and troubleshoot this for the customer.
If the customer accepts, we provide two options, either we reset the password and use a temporary one, or ask the customer to install support pubkey.
After sorting it out, they can either reset the password, or remove the pubkey.
There's really no one-size-fits-all answer unfortunately.
Why do you provide management for unmanaged service? Do customer pays extra for this?
He said that he offers a completely unmanaged service, but obviously tries to be user-friendly and helpful wherever he could - and you know that.
If that's his business approach, there's no need to question that.
I'm just too nice!
Anyone can question anything, after all, this is public forum.
This is how I'd probably do things as well in a unique situation where everything else failed like trying to login from the host node without access etc. I would likely reset the password instead of asking for one and only if that failed then ask them to give me a temp password for access. I would also tell them that I am making an unusual request out of my normal operating procedures - whether this suffices for LET though I am getting the impression it wouldn't. So in my books, I'd say your view of the customer is A plus here.
All these methods are exactly on spot, and to reply the initial question,
Prior installing SSH-keys, temporally changing the password to access the vps, we always ask the permission of the customer to do this, not only us, as I seen on the answers here, all providers do, in most cases the quickest way to debug a situation like this is to access the VPS and try to figure out what is wrong.
If the customer agrees we proceed, if he denies, then we go to plan B, with an extremely long ticket solving, that can take actuality days, rather then minutes to ours.
In most cases we do a full backup of the VPS not to fuck up.
by the way, and I am sure most do the same.
In my opinion, a hosting company does not have time to search throu a vps/dedi of a customer, that is waste of time and resources.
Highly doubt any respectful provider would log in to your VPS/DEDI if he knows the password. I just do not see the "why", not to mention that this is a violation of privacy. The second he would do this he would be done for the rest of he's life.
@vitobotta
You should learn to trust your provider, if you do not, pick another one you do. But in this case your provided just wanted to help you out faster, you have the right to say no to a question like that, and figure out a debug solution with them.
Ask for an ISO , install and encrypt your installation of OS if you wish to feel safer for your data.
And now a little off topic, but this to pint out that your last problem is if the provider knows your password:
Most of you have Social Media, Pictures on Google, Facebook, Tiktok and others.
All those us sophisticated math equations ( AI ) so they actually know more about your behavior than you do, and all this to feed you the relevant commercials that others pay so they can make the profit, and keep you engaged.
You really think that your pictures in the BIG CLOUD providers are not scanned for Facial-Recognition, Geo-Location and so on, c'mon mann.
5 years ago, "deep learning", 5 minute video, but you will get my point at by minute 1
Intel Skylake Xeon VS Nvidia Tesla V100
I know, the conspiracy theory is HIGH there
I have thought long and hard about it, not once but multiple times.
Though I would never want to do that, thing is any provider can login into any VPS (KVM or VZ) anytime doesn't matter what kind of encryption you put on them.
Linux systems were never built to be protected against physical access.
Sometimes we also ask for passwords and/or for our SSH key to be added to a clients system so that we can diagnose a particular problem with our clients applications/OS, and usually our clients allow access. It helps drastically to speed up the diagnosis process. Obviously, we don’t force it on anyone, and we totally understand why some of our customers are probably not comfortable with the idea of giving a support representative access to their server. We find that most of our customers prefer it because they don’t have anything sensitive, they trust us, or they’re inexperienced and just want the problem fixed with as little hassle as possible. It’s rare that we ask for access, usually it happens when there is a misconfiguration on the operating system that we have to diagnose and/or fix.
However, also keep in mind, if a provider really cared about your data, it would be easy to access it from a VPS provider perspective. Cloudinit and QEMU Guest Agent are typically preinstalled on almost all VPS hosts as that’s what allows the control panel to communicate to the VPS to change network settings, configure passwords, users, etc (aka some of the control panel functions). A provider could also take a backup of your instance or boot it into rescue system to change the password or look at your files (this also applies to dedicated servers, although it would be way less discrete). The only way around these would be to install from ISO and run full disk encryption, but that’s also not foolproof (although, it does make it harder).
Guys, are we still talking about self-managed services or fully managed vps?
For us, both, we provide support.
One of the famous storage provider here once sniffed my stuff. Once in a while I run an expensive extract and diff. And one of the nosy admin got curious. Logged in, stopped my script, nano script.sh, re-run the script, removed traces and left. Always use full encryption if it's important but others have already mentioned encryption keys can be extracted from RAM. And I have seen big cloud providers have forensic tools to do this on scale.
Interesting, never thought of this, anyone alse?
Name and shame that scum. You should seek therapy in groups for such brutal act.
and some of us silly customers greatly appreciate the service, support and care that such providers give!!
It is not about a customer being silly
On the lung run, you will have a lower overhead of work, if you help out the customer. Most Providers that do this, rather help and step in, then let the "bastard" struggle and post shit on a forum for not being able to fix the issue himself, because he lacks the knowledge. please do not take the "bastard" as an insult, it was a figure of speech.
it seems to me that providers span a wide range of practices and standards and that if you, as a customer, are not happy with how your provider operates then find a different provider. simple as that.
and honestly, to complain you paid for 3 years of service, with no option for refund, and you're not happy with how the provider operates...that's on you 100%.
but sometimes we are very silly
Sometimes, but this comes with the job
If qemu guest agent is installed, they can run any command they want, disk encryption or not.
Why would i install that agent though? I am not using any provider supplied templates. Usually they don't even have any templates for the OS i want to use
When there is no custom ISO option there's always
dd if=os.raw of=/dev/stdout bs=1M | ssh root@rescue-system-ip -c 'dd if=/dev/stdin of=/dev/sda1 bs=1M'(os.raw is obviously a locally prepared installation of your target OS but it's also very handy if you need to move your system to another VM/dedi). If you wanted to get fancy you could also dodd if=os.raw of=/dev/stdout bs=1M | gzip -9 | ssh root@rescue-system-ip -c 'gunzip | dd if=/dev/stdin of=/dev/sda1 bs=1M'. I am not sure it's a lot of gain over ssh default compression though.Qemu on the rescue system is also an option but obviously only works if the system supports virtualization and gets tricky quite quickly if there isn't enough RAM. If there is no rescue system installing something and moving replacing the filesystem root with a tmpfs. After that it's dd over ssh again just as if it were a rescue system. There is pretty much never a reason to use provider supplied templates. At least on KVM/dedi.
So why the fuck are you annoying them about headless PC's in your basement? Or are you doubling down on being complicated and annoying AF?
And again, the hypervisor doesn't have HDMI or VGA and still have a console. So you're just putting yourself cause number 1 instead of 4.
You have very little understanding of support. I don't know why you think you do. You're just naive and/or basic.
If you happy with your thoughts and imagination - I'am in no power to prove that wrong.