Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


No, I'm not giving away my root password!
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.

No, I'm not giving away my root password!

brueggusbrueggus Member, IPv6 Advocate

There are quite a few providers out there whose support keeps asking for your root password, regardless of the nature of the issue I'm reporting. I'm always getting annoyed by such requests as I consider them highly unprofessional.

First of all, giving away your root password is a security risk. Of course, one could set a temporary password, send it to support and change it back later. But who knows what the support agent does on your server? And frankly, I don't want a person I don't know to fiddle around in my systems. Some providers even state in their TOS that you're not allowed to disclose your root password to anyone.

I personally always check if it's an issue that I can fix on my own before opening a ticket. I also try to give support as much information as possible, but I could imagine that many tickets providers receive do not contain much more than "my server doesn't work".

How do you feel about that? Is it okay to give your provider root access to your servers? Note that I'm talking about unmanaged services here. And is it okay for a provider to refuse working on the issue you reported if you refuse to give them the password?

«1

Comments

  • MasonRMasonR Community Contributor

    With an unmanaged service, I would never expect the provider to take control of the server to investigate any problems/solutions. I would expect general guidance in a certain direction or troubleshooting tips and nothing more. For that reason, I wouldn't give out the root password.

    For unmanaged services, the burden is on you to prove your case that there is a legit issue on the provider's end (provide mtr's and the like).

  • brueggusbrueggus Member, IPv6 Advocate

    MasonR said: For unmanaged services, the burden is on you to prove your case that there is a legit issue on the provider's end (provide mtr's and the like).

    ...and that's perfectly fine. Today I opened a ticket about a network connectivity issue. Added a mtr towards my server (stops after my default gateway), added a mtr from my server (stops after 2nd hop) and added a link to RIPEs BGPlay which shows that the whole subnet was de-announced this morning.

    Half an hour later I was asked for my root password "to investigate further". (╯°□°)╯︵ ┻━┻

  • But who knows what the support agent does on your server?

    That's pretty easy to log to external systems.

    I've seen providers ask it without needing actual access - and that annoys me as well.

    But depending on what people ask, asking the password, or access to the machine (can also be via teamviewer or similar) is completely fine.

    If I got contacted by a customer for unmanaged services to get support for something that is not network and/or hardware related, then I'd charge the customer, and then sure - the customer can decide to give his password, he can also decide not to, and I could explain what he should do. I'd charge in 15 minutes buckets anyway, so me spending more time just means I make more money.

    If it was managed services, I'd already have access to the machine - else it's hard to provide a managed service in first place.

  • MasonRMasonR Community Contributor

    @brueggus said: Half an hour later I was asked for my root password "to investigate further".

    You've definitely done your part to show there is an issue present. To me, this just shows incompetence on the provider's part to take the evidence you've presented and attempt a solution. There's no need for the provider to have access to your machine, but they likely have no clue what the issue is and just want to fiddle around with your box to find an answer. Not something I would be happy with.

    Thanked by 1Clouvider
  • mikhomikho Member, Host Rep

    @brueggus said:

    MasonR said: For unmanaged services, the burden is on you to prove your case that there is a legit issue on the provider's end (provide mtr's and the like).

    ...and that's perfectly fine. Today I opened a ticket about a network connectivity issue. Added a mtr towards my server (stops after my default gateway), added a mtr from my server (stops after 2nd hop) and added a link to RIPEs BGPlay which shows that the whole subnet was de-announced this morning.

    Half an hour later I was asked for my root password "to investigate further". (╯°□°)╯︵ ┻━┻

    Its the lazy support answer, asking for root.

  • I don't allow password authentication via SSH on my servers. You could do the same and joke's on them!

    (Of course they may not resolve your problem...)

    Thanked by 1brueggus
  • RadiRadi Host Rep, Veteran

    If your server for example is a KVM or Xen and you expect them to work on your VPS, there is practically no sane way for them to login to it, unless you permit them by giving your root password. And as @Zerpy said, you are free to log their actions.

  • CoreyCorey Member
    edited August 2017

    So why not setup a new user with root permissions so they can login that way you don't have to give your root password? They are just trying to help you. Some people....

    Also you do not have to give your proper root password on these signup forms. This is a 'feature' of the most popular billing software for hosts out there (WHMCS) to ask for your root password for auto provisioning. Yes this can be modified to be randomly generated, then you still get complaints that it generated a password that is too 'hard'.

  • JanevskiJanevski Member
    edited August 2017

    I've seen this before, they ask for your root password so they can download and watch all of the porn on your server.

    Just tell them you use keys.

  • rm_rm_ IPv6 Advocate, Veteran
    edited August 2017

    Radi said: you expect them to work on your VPS

    With a network connectivity issue, which you have clear as day demonstrated with two mtrs, lies two hops away from your VPS, no, you do not expect them to work on your fucking VPS.

  • jackbjackb Member, Host Rep
    edited August 2017

    @Radi said:
    If your server for example is a KVM or Xen and you expect them to work on your VPS, there is practically no sane way for them to login to it, unless you permit them by giving your root password. And as @Zerpy said, you are free to log their actions.

    Even if root level access is required (is not in this case) there are more sensible options available, for example a sudo user with key based login. Even allowing remote root password login is the long term is stupid never mind giving that password away.

  • IMO if i manage the server i will not give root password to anyone. And main reason is not even security/privacy but the fact that i want to know everything that is done to server, so that some time later i do not spend few days searching for a reason why something does not work only to find out that someone changed some settings. Also, IMO asking for any passwords from customer is highly unproffesional, especially when this passwords are supposed to be given through ticket system, which is accesible by multiple people and is, most likely, completely unsuitable for storing any sensitive information.

    What i would do in case when provider asks me for root password? I will close the ticket and simply move on, thankfully there are a lot of providers out there.

    Thanked by 3MasonR rm_ brueggus
  • AnthonySmithAnthonySmith Member, Patron Provider

    brueggus said: Half an hour later I was asked for my root password "to investigate further".

    So I assume you have put a cancellation request in then?

    I only ask for root passwords or rather 'a login with sufficient rights' if the end user pretty much demands direct assistance for something I cannot replicate because I feel that is better than saying "I tested it on another VPS on the same node with the same software and could not replicate it so I will not help you any further".

    Obviously, if it is an end user created issue in the end then they get billed for time.

    I have had users outright fake mtr reports in the past or when I request fairly basic troubleshooting information they only provide 50% of what I have asked for so sometimes it is just easier for everyone to ask them to login as root on the serial console and then take over that session which you can do in Xen or KVM without requiring root login details.

    I guess you can't please 100% of people 100% of the time, I do agree though asking for it as the first line of support, especially for a networking related issue is crazy.

    Thanked by 2Corey brueggus
  • @Gamma17 said:
    IMO if i manage the server i will not give root password to anyone. And main reason is not even security/privacy but the fact that i want to know everything that is done to server, so that some time later i do not spend few days searching for a reason why something does not work only to find out that someone changed some settings. Also, IMO asking for any passwords from customer is highly unproffesional, especially when this passwords are supposed to be given through ticket system, which is accesible by multiple people and is, most likely, completely unsuitable for storing any sensitive information.

    What i would do in case when provider asks me for root password? I will close the ticket and simply move on, thankfully there are a lot of providers out there.

    Once again, create a throw away account. How many times have you hopped providers when there was an issue because you wouldn't give them proper rights to access your machine?

  • @jackb said:

    @Radi said:
    If your server for example is a KVM or Xen and you expect them to work on your VPS, there is practically no sane way for them to login to it, unless you permit them by giving your root password. And as @Zerpy said, you are free to log their actions.

    Even if root level access is required (is not in this case) there are more sensible options available, for example a sudo user with key based login. Even allowing remote root password login is the long term is stupid never mind giving that password away.

    That is a totally sensible option, when support asks you for your credentials they just want something that gives them proper access rights to get what they need to do done.

  • MasonRMasonR Community Contributor

    @Corey said: Once again, create a throw away account.

    How is that any different than giving them your root password and changing it after they're done? The point is they shouldn't have nor need root access to your machine.

    Thanked by 1bugrakoc
  • MikePTMikePT Moderator, Patron Provider, Veteran
    edited August 2017

    So the provider is trying to help you debugging something that can be your own fault, and... Seriously?

    If you don't trust them with your root password, I hope you ordered a KVM VPS, installed your own ISO and encrypted the partition, because otherwise, they can still mount the lvm and boot, then reset the pw, etc etc.

    In all serious, if you don't trust your provider, just don't host with them.

    I've had to ask for root pw's multiple times, to provide further assistance / check their own mess / actually see what's happening in the VPS.

  • GamerTech24GamerTech24 Member
    edited August 2017

    Yeah, most providers, such as ovh, when you're having an issue with a VPS they'll try and give you guidance and will state they don't have access to your VM.

    Although one time I had my VM hijacked and they were able to look through my directories when I told them as they helped me recover my data, but that is because I told them to try anything they can while on the phone, plus it was booted into rescue-pro anyways

    Thanked by 1MikePT
  • WSSWSS Member

    They've got everything you do logged already. Everything.

    If you're afraid of giving them root access to your shitty virtual machine, well, that's fine. They can just boot around it by using a shell as init after copying your virtual drive to another, and snoop through anyhow.

    If you have a dedi, it's essentially the same deal. Don't do stupid shit.

    Thanked by 1MikePT
  • rm_rm_ IPv6 Advocate, Veteran

    MasonR said: How is that any different than giving them your root password and changing it after they're done?

    A normal user account cannot change system files or configs. I suppose giving them a non-root account (without sudo) may be tolerable.

  • MasonRMasonR Community Contributor

    @rm_ said:

    MasonR said: How is that any different than giving them your root password and changing it after they're done?

    A normal user account cannot change system files or configs. I suppose giving them a non-root account (without sudo) may be tolerable.

    Agreed. But previously he mentioned:

    So why not setup a new user with root permissions so they can login that way you don't have to give your root password?

    Which makes no sense to me as it's effectively still giving out your root pass.

  • RadiRadi Host Rep, Veteran

    @rm_ said:

    Radi said: you expect them to work on your VPS

    With a network connectivity issue, which you have clear as day demonstrated with two mtrs, lies two hops away from your VPS, no, you do not expect them to work on your fucking VPS.

    I meant generally, not for this specific case.

  • CoreyCorey Member
    edited August 2017

    @MasonR said:

    @rm_ said:

    MasonR said: How is that any different than giving them your root password and changing it after they're done?

    A normal user account cannot change system files or configs. I suppose giving them a non-root account (without sudo) may be tolerable.

    Agreed. But previously he mentioned:

    So why not setup a new user with root permissions so they can login that way you don't have to give your root password?

    Which makes no sense to me as it's effectively still giving out your root pass.

    Sorry I was mistaken. I thought you guys didn't want your password that you use to access your machine stored in clear text in someones database, but you actually don't want to give root access at all. /shrugs

    Other providers here have outlined why that is stupid since any provider can gain access to your files and system very easily if they wanted. If you do not trust your provider why are you hosting with them?

    Thanked by 1MikePT
  • @Corey said:
    Other providers here have outlined why that is stupid since any provider can gain access to your files and system very easily if they wanted. If you do not trust your provider why are you hosting with them?

    similiar question for you, do you trust client who hosted with you?

    some provider feel people too stupid to debug their issue. Why? because they're your provider so they must be better troubleshooting the issue than you.

  • @sibaper said:

    @Corey said:
    Other providers here have outlined why that is stupid since any provider can gain access to your files and system very easily if they wanted. If you do not trust your provider why are you hosting with them?

    similiar question for you, do you trust client who hosted with you?

    some provider feel people too stupid to debug their issue. Why? because they're your provider so they must be better troubleshooting the issue than you.

    What? If you're asking for help, then yes, you obviously need help.

  • you're not supposed to use passwords to login via ssh anyway. use pub key authentication. ask the provider to give you their pubkey and then add that to root's authorized_keys file. or better yet create an unprivileged account for them with sudo capabilities. this way the changes they make will be logged.

    the risk of sharing your root password via the ticket system is that a breach of their website will leave your server vulnerable.

  • I guess that 90% of the people that need support to log in to their server would still use password auth.

  • WSSWSS Member
    edited August 2017
    [wss@stinky:~]$ banner -f drpepper dicks
       _   _         _
     _| | <_>  ___  | |__  ___
    / . | | | / | ' | / / <_-<
    \___| |_| \_|_. |_\_\ /__/
    
    Thanked by 4Aidan brueggus Pwner sin
  • I remember my OVH dedi had a pre-installed SSH public key so that OVH staff could log into it if needed. This wasn't a backdoor since they announced it up front and said how to disable it if you didn't want it (but that could complicate some support cases). I don't remember but they may have run some regular monitoring with it, like cpu temperature.

  • WSSWSS Member

    $7

Sign In or Register to comment.