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
That would have at least been a reasonable answer.
Instead he took the "if its a clear error, there is no issue the account is unblocked and everyone is happy" route... as if losing access to your server pending a response from support (that may or may not restore your account) isn't a big deal. It's a big deal. For anyone to say otherwise is minimizing a shit product.
Maybe it's time to move away from that platform, if it doesn't work in anyone's favour...
I was talking specifically about blaming the time-wasting on customers. This is applicable to all customers, not just the OP but even someone who does just type sudo accidentally. The time wasting is something he brought on himself.
It's like installing a car alarm system that causes the engine to break down when someone touches the car - to stop someone stealing it - and it takes an hour to fix.
Instead of putting a fence or wall up so people can't touch it, or allowing people to touch the car and only triggering the alarm if someone tries to break in, he adds a sign saying "Do not touch the car"
If someone then touches the car, the engine breaks and he then complains that he has to spend an hour fixing it.
It's simple. Either change the message to inform the customer what will happen if they run sudo or change out of the user directory (suspension + a long wait until someone reviews the case), or just block the commands being run without causing extra work for support.
Seems fair. Better than the current system.
👍🏻@i20
do you think the platform should be abandoned because they don't allow shady proxieservices on their shared hosting packages? is that what you mean?
Sure, all of the mentioned hosters allow sudo commands in their shared webhosting packages.... Not
OP was not banned cause of running sudo commands. He got refunded as @xHosts mentioned. Sudo commands are blocked as also mentioned by @xHosts If you run sudo commands your ash access will be blocked and you ask through a ticket to get access again. So many mjjs are trying to blame the hipster for this is imo ridiculous.
...and an attempt was made to run shady scripts on the shared hosting.
Definitely not that, but there are proper ways to manage this instead of just outright banning because some one is traversing (or trying to) a directory out of their own, or if they use sudo...
Edit: Plus, 20i is not their platform, and seems like they are middleman-ning/reselling shared hosting through 20i? Less control overall from the host and depends completely on 20i.
Next thread "I tried rm -fr *" just for curiosity with my new hosting company.
I love threads like this, thank you LET
Curious, who is the other provider. I never enabled jailed SSH or entertained the idea of permitting it because in my testing a user could still
catfiles outside of their directory, see running processes which includes other customer's usernames, etc. Jailed SSH seems like a privacy and security nightmare. At least it was a few years ago in DirectAdmin, unsure if better now.Are you able to view system files or print all directories in /home/ or anything?
So you only offer hosting for static files? Or only PHP with PHP safe mode? Otherwise, how do you make sure that those scripts don't access any files they shouldn't? Yes, SSH makes it more convenient to have a look around the system, but if you allow any scripts you have the exact same issue.
You do not lose access to the account in the event of a block, simply SSH.
Fully account blocks are only done normally
A) you contact asking to ssh back, you say something like i tried to restore a wordpress backup but the logs show you tried to run this type of script or have other nefarious actions
It seems to work fine for hundreds on my account and I suspect thousands of others direct and other resellers, all about people talking to staff, being clear on their intent if statf ask a few simple questions if they report issues with SSH, the customer being honest is not hard. When someone is evasive that is when issues arise
Yes, I am completely supportive of that, and even we would do the same thorough approach if required, and make sure we only have legitimate customers who will abide by the T&Cs set forth.
On the other hand, I would still prefer to use a control panel for shared hosting that manages this a bit differently, and allows users access to ssh, but without the ban hammer part.
I am with @xHosts on this one, client clearly signed up for something and went vague and then decided to install something from github without making sure it was allowed. Shared hosting is for websites and some files, for God's sake, it was a $3-something lifetime deal.
It could be managed a little better, the main reason they advise of ban is that once the ban happens, the customer will either leave the SSH blocked or make contact which in some views will force the customer to engage and discuss their use, at that point logs can be reviewed and if the service is not suitable for their intended use they have the options to switch to a service that does suit their needs or switch to another provider that can provide. They explained to me while banning the SSH access will prevent someone who has nefarious intent who maybe probing the system for either a loophole or a zero day stands a high chance of being blocked before either of them are found.
Your analogy is incorrect. More accurately, random person wasn't just "touching" the car, his intent was to break the engine. The fucking off to the customer prevented the car from needing a trip to the repair shop. The hassle is the need to fucking off a customer. That's better than a trip to the garage.