Recurring issues with DediRock VPS, and support asks for root password

bmilk · May 12

I’m having a recurring issue with a DediRock VPS and it’s becoming very frustrating.

A few days ago, my server suddenly became inaccessible via SSH, and Cloudflare also started returning 503 errors. I opened a support ticket, and after about a day they fixed it.

However, only two days later, the exact same problem happened again.

I checked the VPS itself:

sshd is running normally
port 22 is listening on 0.0.0.0
UFW allows 22, 80, and 443
from inside the VPS, it can connect to its own public IP on port 22 successfully
So this really does not look like a simple issue inside the VPS. It seems much more likely to be something on the provider side, such as networking, ACL, routing, host node, or public IP mapping.

What makes me even more uncomfortable is that support asked me for the root password in order to fix the issue. I’m not comfortable sharing the root password, especially when this appears to be a provider-side infrastructure problem rather than a basic guest OS issue.

Has anyone else experienced similar issues with DediRock recently?
And is it considered normal or acceptable for a VPS provider to ask for the root password in this kind of situation?

At this point I’m seriously considering moving to another provider, because I can’t keep dealing with the same issue every few days.

m3th3lesh · May 12

@bmilk said:
I’m having a recurring issue with a DediRock VPS and it’s becoming very frustrating.

A few days ago, my server suddenly became inaccessible via SSH, and Cloudflare also started returning 503 errors. I opened a support ticket, and after about a day they fixed it.

However, only two days later, the exact same problem happened again.

I checked the VPS itself:

sshd is running normally
port 22 is listening on 0.0.0.0
UFW allows 22, 80, and 443
from inside the VPS, it can connect to its own public IP on port 22 successfully
So this really does not look like a simple issue inside the VPS. It seems much more likely to be something on the provider side, such as networking, ACL, routing, host node, or public IP mapping.

What makes me even more uncomfortable is that support asked me for the root password in order to fix the issue. I’m not comfortable sharing the root password, especially when this appears to be a provider-side infrastructure problem rather than a basic guest OS issue.

Has anyone else experienced similar issues with DediRock recently?
And is it considered normal or acceptable for a VPS provider to ask for the root password in this kind of situation?

At this point I’m seriously considering moving to another provider, because I can’t keep dealing with the same issue every few days.

You are not new, its common and regular issues with them.

ScreenReader · May 12

I'd avoid that provider like plague. asking plain password root on my chicken, seriously?.
at bare minimum (YOU) as provider ask your customer to add your ssh pubkeys to root instead of using plain password.

if i were you op, install & setup auditd to log root activities and send the log into remote rsyslog server, at very least during the customer support logging in into your vps as root.

slowservers · May 12

To be fair, they have root access anyway if they want it. You can use a unique root password, share it, and then change it later.

A packet capture would be interesting, but you could also share a (unique) root password and change it after, and see if they can fix it.

Though it sounds like a fix like this is going to come ultimately from outside the server, but it's possible they have some unusual requirements of the VPS itself.

bmilk · May 12

@slowservers said:
To be fair, they have root access anyway if they want it. You can use a unique root password, share it, and then change it later.

A packet capture would be interesting, but you could also share a (unique) root password and change it after, and see if they can fix it.

Though it sounds like a fix like this is going to come ultimately from outside the server, but it's possible they have some unusual requirements of the VPS itself.

In fact, that’s exactly what I did. I also tried to audit what they did to our VPS, but I couldn’t find anything. After I changed the root password, it stopped working again the next day.

bmilk · May 12

@m3th3lesh said:

@bmilk said:
I’m having a recurring issue with a DediRock VPS and it’s becoming very frustrating.

A few days ago, my server suddenly became inaccessible via SSH, and Cloudflare also started returning 503 errors. I opened a support ticket, and after about a day they fixed it.

However, only two days later, the exact same problem happened again.

I checked the VPS itself:

sshd is running normally
port 22 is listening on 0.0.0.0
UFW allows 22, 80, and 443
from inside the VPS, it can connect to its own public IP on port 22 successfully
So this really does not look like a simple issue inside the VPS. It seems much more likely to be something on the provider side, such as networking, ACL, routing, host node, or public IP mapping.

What makes me even more uncomfortable is that support asked me for the root password in order to fix the issue. I’m not comfortable sharing the root password, especially when this appears to be a provider-side infrastructure problem rather than a basic guest OS issue.

Has anyone else experienced similar issues with DediRock recently?
And is it considered normal or acceptable for a VPS provider to ask for the root password in this kind of situation?

At this point I’m seriously considering moving to another provider, because I can’t keep dealing with the same issue every few days.

You are not new, its common and regular issues with them.

I’ve run into this twice within a week. The first time, they fixed it. Then two days later, I changed the root password, and about 12 hours after that, it became unusable again. In hindsight, I should have verified everything immediately after changing the password.

bmilk · May 12

@ScreenReader said:
I'd avoid that provider like plague. asking plain password root on my chicken, seriously?.
at bare minimum (YOU) as provider ask your customer to add your ssh pubkeys to root instead of using plain password.

if i were you op, install & setup auditd to log root activities and send the log into remote rsyslog server, at very least during the customer support logging in into your vps as root.

I really don’t think they should need the root password. If they check their network and don’t find any issue on their side, they should simply let me know so I can troubleshoot the VPS itself. Asking for my password should not be the default approach.

DrNutella · May 12

Honestly
First I’m hearing of this.

@DediRock is the most honest and transparent person I’ve met. He’s hard working, nice and quiet of all, listening because he cares.

I trust him to give us to LD here he as always, I offer my free strategy consulting to maximize outfits in this LE market that add double digits to any margin.

Not a paid promotion. I’ll shit talk the minute a screw up happens.

msatt · May 12

As an 'outsider' I would say - DR are being very generous to actually offer to look (internally) at your VPS. If they know their infrastructure is working then the problem is associated with the VPS. The VPS will very likely have been built from a template which means everyone using that template would be affected in the same way. So if you are the 'odd one out' then investigation needs to be made inside the VPS. This is outside the normal scope of support so credit to DR.
The fact you don't trust DR says more about you than them.
My advice would be backup and rebuild (not restore) - your problem will very likely disappear.

bmilk · May 12

@msatt said:
As an 'outsider' I would say - DR are being very generous to actually offer to look (internally) at your VPS. If they know their infrastructure is working then the problem is associated with the VPS. The VPS will very likely have been built from a template which means everyone using that template would be affected in the same way. So if you are the 'odd one out' then investigation needs to be made inside the VPS. This is outside the normal scope of support so credit to DR.
The fact you don't trust DR says more about you than them.
My advice would be backup and rebuild (not restore) - your problem will very likely disappear.

I don’t agree with that conclusion.

First, the fact that I can SSH to the VPS from within the VPS itself shows that the SSH service is working normally and that the firewall is not the problem. I also checked all listening ports and found nothing unusual.

Second, after I gave them the root password, I checked the SSH login history and shell history, and I couldn’t find any sign that they had actually logged into the machine or run any commands. So either they never logged into the VPS at all, which would suggest the issue was outside the VPS, or they did log in and wiped the traces afterward, which would be even more alarming.

Finally, after I changed the root password, the same connectivity issue came back again, while nothing else had been changed. That is a detail worth looking into very carefully.

msatt · May 12

dont agree - that is fine, but your comments show a lack of real sysadmin knowledge.
A cron / scheduled job could easily wipe ssh or change to i/f card or iptables or....
All could / may be cured by a reboot.
What you are really saying is you don't trust the provider.

bmilk · May 12

@msatt said:
dont agree - that is fine, but your comments show a lack of real sysadmin knowledge.
A cron / scheduled job could easily wipe ssh or change to i/f card or iptables or....
All could / may be cured by a reboot.
What you are really saying is you don't trust the provider.

This is not just a matter of trust. Sensitive credentials should not be shared unless there is a clear and necessary reason. By that logic, anyone could ask for highly sensitive access and simply say “trust me,” which is obviously not how security should work.

I have already checked the relevant possibilities on my side, including the SSH service, firewall, and listening ports, and everything appeared normal internally. Please don’t dismiss that with amateur speculation or assume I didn’t do the necessary troubleshooting.

AlteredParadox · May 12

lol. just freaking lol. These threads lately, wtf. @DediRock you are a far more patient person than anyone I know if this is the kinda shit you deal with on a daily basis, my friend

op: if you have such huge trust issues with the host, then why are you there in the first place? Move somewhere else, im sure dedirock will got out of business losing your $10.

FWIW, i've had other providers ask for creds when troubleshooting, usually to rule out an issue on the vps before pivoting to their network/infra, which makes perfect sense given the differing knowledge/skill levels of customers. Generally ill just change the root pw, give it to them, get whatever the issue is fixed, and rebuild the box. Free backup testing

jsg · May 12

@bmilk SSH problems usually can be debugged quite well. Just add '-v' (to ssh) and you should be able to spot the problem.

As for the root password I'm with you; a good provider would, if at all, ask for a normal user access. On the other hand @slowservers is right; it's a VM after all.

bmilk · May 12

@AlteredParadox said:
lol. just freaking lol. These threads lately, wtf. @DediRock you are a far more patient person than anyone I know if this is the kinda shit you deal with on a daily basis, my friend

op: if you have such huge trust issues with the host, then why are you there in the first place? Move somewhere else, im sure dedirock will got out of business losing your $10.

FWIW, i've had other providers ask for creds when troubleshooting, usually to rule out an issue on the vps before pivoting to their network/infra, which makes perfect sense given the differing knowledge/skill levels of customers. Generally ill just change the root pw, give it to them, get whatever the issue is fixed, and rebuild the box. Free backup testing

Your point would make more sense if this were a normal one-off guest OS issue. It isn’t. The concern here is a recurring connectivity problem that reappeared shortly after their “fix,” combined with a request for root credentials without any clear explanation of why that was necessary.

You may be comfortable handing over root access and rebuilding afterward. That’s your choice. I’m not comfortable treating root credentials as a routine troubleshooting shortcut, especially when the evidence points at least partly toward a provider-side issue.

Also, when the exact same issue occurred two days ago, I did provide the root password. After that, I explicitly asked them to explain the root cause, but they refused to provide any explanation and closed the support ticket instead.

And yes, I am already looking elsewhere. But “just move” does not make the underlying behavior any less questionable.

bmilk · May 12

@jsg said:
@bmilk SSH problems usually can be debugged quite well. Just add '-v' (to ssh) and you should be able to spot the problem.

As for the root password I'm with you; a good provider would, if at all, ask for a normal user access. On the other hand @slowservers is right; it's a VM after all.

Thanks, and I agree that ssh -v / -vvv can usually provide useful clues. I’ve already done the basic checks on the VPS side, including verifying that SSH was running normally, port 22 was listening correctly, and internal SSH connectivity worked from within the VPS itself.

My main concern is not whether a VM can have guest-side issues — of course it can. The concern is that root credentials were requested without a clear explanation of why that level of access was necessary, and when I previously provided them for the same issue, I was given no root cause explanation afterward and the ticket was simply closed.

If they wanted me to run additional diagnostics such as verbose SSH output or other checks from inside the guest, I would have been happy to do that.

bmilk · May 12

delete

totally_not_banned · May 12

@slowservers said:
To be fair, they have root access anyway if they want it. You can use a unique root password, share it, and then change it later.

That want comes with jumping through a bunch of hoops though if @OP put some work into his configuration and encrypted the disk with a remote unlock method. Sure, the unencrypted boot partition can still be mounted/backdoored and encryption keys can be dumped from RAM but it still requires way more effort than simply mounting the image.

A packet capture would be interesting, but you could also share a (unique) root password and change it after, and see if they can fix it.

Agreed. An actual dump is likely to reveal at least a good bit of additional information. Given it seems that @OP can access the VM via VNC running something alone the lines of tcpdump -vni eth0 port X or tcpdump vXni eth0 port X (X being @OP's SSH port) during a SSH connection attempt is a no-brainer in my opinion. Maybe it's something simple like no SYNs arriving to begin with making any talk about handing out root access superfluous.

zed · May 12

This is rank idiocy.

You have no way of knowing if "support" is just some outsourced fiverr monkey so the idea that it's ok for support to ask for your root creds because OBVIOUSLY they have root access to the host node is complete nonsense.

If they're asking for root so they can make sure that you already checked things internally to the vps they can say that and you can then point out what you've already done due diligence and politely decline that level of exemplary service.

It's much more likely that "support" is grasping at straws, especially since this is @DediRock (no offense big guy) which is $7/yr CC reseller so the machines are likely overloaded and struggling and support may not even know what tcp/ip means.

Not to mention the other current posts about issues with same provider.

LET is getting stupid, stop it what the fuck.

xvps · May 12

Just to make sure.

When software like Docker, libvirt, or fail2ban inserts rules directly into iptables/nftables, UFW is completely unaware of them.

You can check with:

# IPv4 — the raw truth, all chains
sudo iptables -L -n -v --line-numbers

# IPv6
sudo ip6tables -L -n -v --line-numbers

# Also check the NAT and mangle tables (Docker lives here)
sudo iptables -t nat -L -n -v
sudo iptables -t mangle -L -n -v

# If you use Debian 13 (nftables)
sudo nft list ruleset

You have checked your firewall rules the proper way and not just with UFW, right. :-)

totally_not_banned · May 12

@xvps said:
Just to make sure.

When software like Docker, libvirt, or fail2ban inserts rules directly into iptables/nftables, UFW is completely unaware of them.

You can check with:
# IPv4 — the raw truth, all chains
sudo iptables -L -n -v --line-numbers

# IPv6
sudo ip6tables -L -n -v --line-numbers

# Also check the NAT and mangle tables (Docker lives here)
sudo iptables -t nat -L -n -v
sudo iptables -t mangle -L -n -v

# If you use Debian 13 (nftables)
sudo nft list ruleset
You have checked your firewall rules the proper way and not just with UFW, right. :-)

This is solid advice. In general something like alias fwstat='iptables -Lnvt' (arguments would be filter, nat or mangle) or the matching IPv6 equivalent is actually handy to have in one's shell startup script.

bmilk · May 12

@xvps said:
Just to make sure.

When software like Docker, libvirt, or fail2ban inserts rules directly into iptables/nftables, UFW is completely unaware of them.

You can check with:
# IPv4 — the raw truth, all chains
sudo iptables -L -n -v --line-numbers

# IPv6
sudo ip6tables -L -n -v --line-numbers

# Also check the NAT and mangle tables (Docker lives here)
sudo iptables -t nat -L -n -v
sudo iptables -t mangle -L -n -v

# If you use Debian 13 (nftables)
sudo nft list ruleset
You have checked your firewall rules the proper way and not just with UFW, right. :-)

Thanks, I appreciate the suggestion. Yes, I checked the raw iptables/nftables rules as well — not just UFW — including the relevant chains and tables, and I didn’t find anything obviously abnormal there. That’s part of why this still looks more like an external/provider-side issue than a simple guest firewall problem.

bmilk · May 12

Quick update: this time I did not provide the root password. Support has now responded, and after testing, everything appears to be accessible normally again.

I’m not looking to argue with anyone here. The repeated issue and the way the earlier ticket was handled were what prompted me to post in the first place.

Thanks to everyone who took the time to reply and offer suggestions.

bmilk · May 12

@zed said:
This is rank idiocy.

You have no way of knowing if "support" is just some outsourced fiverr monkey so the idea that it's ok for support to ask for your root creds because OBVIOUSLY they have root access to the host node is complete nonsense.

If they're asking for root so they can make sure that you already checked things internally to the vps they can say that and you can then point out what you've already done due diligence and politely decline that level of exemplary service.

It's much more likely that "support" is grasping at straws, especially since this is @DediRock (no offense big guy) which is $7/yr CC reseller so the machines are likely overloaded and struggling and support may not even know what tcp/ip means.

Not to mention the other current posts about issues with same provider.

LET is getting stupid, stop it what the fuck.

I understand your point, and yes, that was basically my concern from the beginning: if root access is being requested, there should be a clear explanation of why it is necessary and what exactly is being ruled out.

My issue was never “support should never ask.” My issue was that root credentials were requested, no meaningful cause was explained afterward, and the same problem came back again shortly after. That’s what made the whole process feel questionable.

In any case, the issue appears to be working again for now, and I’m not looking to escalate things further. I do appreciate the people here who responded in good faith.

DediRock · May 12

@bmilk said:
I’m having a recurring issue with a DediRock VPS and it’s becoming very frustrating.

A few days ago, my server suddenly became inaccessible via SSH, and Cloudflare also started returning 503 errors. I opened a support ticket, and after about a day they fixed it.

However, only two days later, the exact same problem happened again.

I checked the VPS itself:

sshd is running normally
port 22 is listening on 0.0.0.0
UFW allows 22, 80, and 443
from inside the VPS, it can connect to its own public IP on port 22 successfully
So this really does not look like a simple issue inside the VPS. It seems much more likely to be something on the provider side, such as networking, ACL, routing, host node, or public IP mapping.

What makes me even more uncomfortable is that support asked me for the root password in order to fix the issue. I’m not comfortable sharing the root password, especially when this appears to be a provider-side infrastructure problem rather than a basic guest OS issue.

Has anyone else experienced similar issues with DediRock recently?
And is it considered normal or acceptable for a VPS provider to ask for the root password in this kind of situation?

At this point I’m seriously considering moving to another provider, because I can’t keep dealing with the same issue every few days.

Hey @bmilk,

How are you? Very sorry for the trouble here. I can tell from the rest of the thread things did get handled, so thank you for your patience with us while it was sorted out. However, I would also like to DM you to get your ticket number, and I would like to take a look as well and see how we can make things a bit better on the process side of things. Thanks again for being a customer and for your patience with us.

DediRock Makes It Right™

DediRock · May 12

@m3th3lesh said:

@bmilk said:
I’m having a recurring issue with a DediRock VPS and it’s becoming very frustrating.

A few days ago, my server suddenly became inaccessible via SSH, and Cloudflare also started returning 503 errors. I opened a support ticket, and after about a day they fixed it.

However, only two days later, the exact same problem happened again.

I checked the VPS itself:

sshd is running normally
port 22 is listening on 0.0.0.0
UFW allows 22, 80, and 443
from inside the VPS, it can connect to its own public IP on port 22 successfully
So this really does not look like a simple issue inside the VPS. It seems much more likely to be something on the provider side, such as networking, ACL, routing, host node, or public IP mapping.

What makes me even more uncomfortable is that support asked me for the root password in order to fix the issue. I’m not comfortable sharing the root password, especially when this appears to be a provider-side infrastructure problem rather than a basic guest OS issue.

Has anyone else experienced similar issues with DediRock recently?
And is it considered normal or acceptable for a VPS provider to ask for the root password in this kind of situation?

At this point I’m seriously considering moving to another provider, because I can’t keep dealing with the same issue every few days.

You are not new, its common and regular issues with them.

Hey @m3th3lesh,

Always looking to improve thanks for the comment. Have a good man.

Thanks

DediRock · May 12

@ScreenReader said:
I'd avoid that provider like plague. asking plain password root on my chicken, seriously?.
at bare minimum (YOU) as provider ask your customer to add your ssh pubkeys to root instead of using plain password.

if i were you op, install & setup auditd to log root activities and send the log into remote rsyslog server, at very least during the customer support logging in into your vps as root.

Hey @ScreenReader,

How are you? That is a good point, and I can bring that up to my Sys Admin to see what we can do. Thanks for the comment. However, if you would ever like to give us a try, let me know, as it sounds like you could give some great customer feedback, etc.

Thanks

DediRock · May 12

@slowservers said:
To be fair, they have root access anyway if they want it. You can use a unique root password, share it, and then change it later.

A packet capture would be interesting, but you could also share a (unique) root password and change it after, and see if they can fix it.

Though it sounds like a fix like this is going to come ultimately from outside the server, but it's possible they have some unusual requirements of the VPS itself.

Hey @slowservers,

I am def looking into this. I do know in the past I have read a few tickets where customers had concerns on sharing root credentials, etc. It looks like I have a few options to update our process. Thanks for the comment.

Thanks

DediRock · May 12

@bmilk said:

@ScreenReader said:
I'd avoid that provider like plague. asking plain password root on my chicken, seriously?.
at bare minimum (YOU) as provider ask your customer to add your ssh pubkeys to root instead of using plain password.

if i were you op, install & setup auditd to log root activities and send the log into remote rsyslog server, at very least during the customer support logging in into your vps as root.

I really don’t think they should need the root password. If they check their network and don’t find any issue on their side, they should simply let me know so I can troubleshoot the VPS itself. Asking for my password should not be the default approach.

Hey @bmilk,

I agree there should have been some other steps done before that, and again I will review your ticket to see what we should have done instead. Thanks again for your patience on it.

DediRock Listens™

DediRock · May 12

@DrNutella said:
Honestly
First I’m hearing of this.

@DediRock is the most honest and transparent person I’ve met. He’s hard working, nice and quiet of all, listening because he cares.

I trust him to give us to LD here he as always, I offer my free strategy consulting to maximize outfits in this LE market that add double digits to any margin.

Not a paid promotion. I’ll shit talk the minute a screw up happens.

Hey @DrNutella,

Thank you very much for the compliment. It definitely takes some doing and effort to get the service right by listening and putting in the time, but it is always worth it. Definitely already reached out to @bmilk to get his ticket number so we can check it further.

Thank you!

aRNoLD · May 12

Check you network config file to see if it is eth0 or ens3 (or sth.)

For example, install from netboot.xyz and you'll have ens3 but only eth0 is officially recognizable and will be forcefully rewritten into the config file. When you reboot the machine, you will see the machine is live, but not accessible from you client side. Change ens3 back to eth0 may solve the problem.

Howdy, Stranger!

Categories

In this Discussion

Recurring issues with DediRock VPS, and support asks for root password

Comments

Howdy, Stranger!

Quick Links

Categories

In this Discussion

Recurring issues with DediRock VPS, and support asks for root password

Comments