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.
Sigh...I guess I need to move on from BuyShared. Recs?
raindog308
Administrator, Veteran
in General
I've been using @Francisco 's BuyShared for quite a while and have no complaints with the web hosting.
However, trying to work with the service over ssh is very painful. About 50% of my ssh attempts end like this:
ssh_exchange_identification: read: Connection reset by peer
I asked support and was told:
This is a result of our Shared nodes receiving constant bombardment of SSH Brute Force attacks that the firewall simply cannot keep up with that many concurrent connections. Whenever you see this error it's best to simply wait a minute or two and try again.
For interactive use, that's fine...and in fact I've been doing that for months.
But it's impossible to get through an ansible playbook like that.
I probably won't be able to find the same price but...recs? It's friends and family so I'd prefer something ultra-stable. I'd go back to Dreamhost but dread the cpanel-to-DH-custom-panel conversion.
I guess I can check the offers...
Comments
Are they using the default port 22?
Those BF attacks are commonly done by bots.
I get that once in a while, but by no means anything constant.
What's you ticket ID? I can put a bit of time into it and see what it could be. It could very well be an entropy issue.
Francisco
Ticket 84495.
FYI, more than 50% of my ssh sessions this morning had that error. 8-9 in a row, then it works, then a few more failures, then it works, etc. That's not unusual.
haveged :-)
@raindog308 What's keeping you from arbitrarily hooking a netcat from localhost:22 to a higher port once you get in? Other than, you know, being kind of shitheaded to do.
+1 for haveged (I wish the OpenVZ providers would be more willing to run it on the host node).
@Francisco - is it feasible to use a combination of sshd_config's MaxAuthTries and LoginGraceTime along with the equivalent of iptables' hashlimit (per source ip) to really clamp down on the nuisance value of these bots? (I assume due to the shared setup, you don't have the freedom to enforce public key only logins, possibly on a non-standard port).
@raindog308 - does it make sense to just have one mux'd ssh session going (with keepalives) to just get a connection and "hog" it for a while (till you get things done with ansible)?
netcat is unlikely to be available on shared servers. Especially not on a jailed session.
It isn't all /that/ difficult to compile statically, but I guess I'm not the norm (I'd ask for permission first).
How about patching sshd to use urandom instead of random, given your old kernel. 3.16 introduces the getrandom system call which is the right way to deal with this, but it's not pervasive yet.
@WSS - why reinvent the wheel (with netcat) when ssh pretty much gives you multiplexed sessions out of the box - see "ControlMaster" (man ssh_config). Should solve part of the problem in terms of getting (and keeping) a connection (for a user configurable period of time).
@nullnothere If my provider can't figure out how to mitigate the attacks against the port, and I need access, I'd probably do precisely as I described so I could archive it and move it elsewhere. As mentioned above, I'd ask for an OK first.
@raindog308 I'm using Crowncloud for the last year and they have good support, Don't know what ssh is like had no need to use it yet.
Is there a reason to have password ssh enabled at all, instead of public key? Is there a way to use fail2ban or something against the brute force attacks?
@raindog308 you're not the only one, I've been having similar intermittent SSH issues with my buyshared account in Luxembourg but I'm only pulling WordPress backups over rsync so it's just a little bit annoying for me.
on shared hosting forcing customers to look into the use of keys instead of passwords probably keeps being a big drawback, as a lot of customers simply don't want to get that 'techie' and rather go with another provider who offers access by passwords...
and yes fail2ban is very capable of blacklisting IPs on bruteforce attempts, might need some kind of finetuning on number of retires, findtime and bantime.
After all I'd also suggest that moving the port to something will definitly lower that noise a lot and should be easily presented to customers. fail2ban in addition may deal with anything left.
and haveged for sure should be considered if entropy issues are a supposed cause...
I'm looking into this but I don't believe it. Sshd should be using /dev/urandom or randombytes(2) if the kernel is new enough, probably by calling openssl. If it's doing anything else, something is messed up.
If Phoenix is acceptable as location I'm sure we can work something out.
If the listed packages is not meeting your needs, let me know and we might work something out.
I checked in debian 8, I'm fairly confident that openssh/openssl isn't doing something stupid about entropy. Don't know about other OS.
@willie - my hunch is that it is more related to MaxStartups (sshd_config) than entropy.
Unsure if this would help, but have you tried Mosh?
@telephone -
MostMosh still uses ssh to authenticate (which is where the pain is) - so it is unlikely to help (and if you COULD get a connection, then you can just keep a multiplexed ssh session open and not have any hassles with SSH for a while).mosh starts a server process on the remote side and then communicates with it by UDP. I don't think that would go over too well on a shared host. It looks like you can use screen though, once you get across.
I have to wonder about the security of mosh as well. ssh has been studied pretty well over the years, no idea about mosh.
True, but a few dozen lines of python and background tasking and you'll have your own hacked up version of netcat, then you don't have to worry too much. Of course, it leaves it exposed but you do the security w/ password/key and it'll be fine.
How about ssh to one of the ipv6 addresses? Not sure how to figure out what those are, though.
Linux should use arc4random :-)
>
Theo is known to cause cancer in lab deRaadts.
Oh, that's why codeguard fails to backup buyshared sites all the time.
Entropy?
I've only seen two causes to that issue, either Host Access Control blocks things, or MaxStartups is too low (which, lets be honest... if you're running a shared cPanel server and offer shell access, you really aught to bump that value up).
I've seen this a lot too so I notified Fran about it but I don't think it was ever really 'solved'. Other than that everything is working fine.
Their kernel seems to be very old, so it's using the normal randr input which can cause this also (but should log server side then that it did).
All of the kernels are pretty close to latest for Cloudlinux. Some are still CentOS 6 and honestly, I prefer that over the CentOS 7 boxes. The 7 boxes have been better after the latest Litespeed patches, but LSWS still randomly crashes/dies during graceful restarts/etc.
@raindog308 - I've messaged you to find your node, etc.
Francisco