How can offering SSH be a security risk? and do you offer it automaticly to your customers? or do they have to request it? thanks.

I always prefered having SSH on a non-standard port, but it defeats the purpose if you allow shell for your customers

Honestly I wouldn't allow any customers ssh access. Only bad can come of it.

How can offering SSH be a security risk? and do you offer it automaticly to your customers? or do they have to request it? thanks.
I read up somewhere that offering SSH is dangerous unless you really know what you are doing.

Honestly I wouldn't allow any customers ssh access. Only bad can come of it.

And I would never order an account from you because of it.

By default I would disable it, but allow it by request.

We allow it by request, on a non-standard port, for all accounts but our smallest.

As a rule I disable SSH for all new accounts. If someone needs it, then they know what they are doing and/or I can evaluate whether or not they should be allowed to use it.

I do agree that having too many people with access to shell is not a good idea.

cheers
chris

And I would never order an account from you because of it.

By default I would disable it, but allow it by request.
Agree 100%

I usually ask for a copy of a govt/state issued ID, a fingerprint scan, a DNA sample, and their next-of-kin before I give anyone shell access.

Erm.... actually just their home phone number, and ISP email/abuse email is pretty good as 'compensation'. Pretty much giving out SSH is asking for your box to be hacked, so it's a good safety net, plus the beefed up security on the box, such as SSP,grsec,nonexec-stack.

Wouldn't it be a better solution to offer them a "Jailed Shell". I have seen them advertised before.

How can offering SSH be a security risk? and do you offer it automaticly to your customers? or do they have to request it? thanks.
You're giving your clients the ability to compile their own software. They could compile a root kit. However, any real threat could just transport the binary to your server, execute it via perl or php, and have access. The company I work for requires the customer to provide photo ID before he or she is granted shell access.

I always prefered having SSH on a non-standard port, but it defeats the purpose if you allow shell for your customers
Well if you moderate ssh access, running it on a non-standard port is still safe. Simply because lessens the likelyhood of being hacked by some random guy out there looking for vulnerable machines.

Honestly I wouldn't allow any customers ssh access. Only bad can come of it.
Maybe for you, but many people use ssh access for development purposes. In addition to that, using ssh instead of ftp for updating your website is much safer, because ftp transmissions are sent in plain text. Unless of course you have ssl over ftp setup.

I would never give SSH access to anyone on my servers.. nothing good could come out of it.. just hackers using it to run exploits, etc.

same exploits can be ran using php or perl..

I would never give SSH access to anyone on my servers.. nothing good could come out of it.. just hackers using it to run exploits, etc.

I prefer that my more technically skilled clients use a shell to dump their databases instead of cpanel; it seems to use way less resources.

I prefer that my more technically skilled clients use a shell to dump their databases instead of cpanel; it seems to use way less resources

Not only that, try importing a 100 mb .sql file into phpmyadmin. Seriously. Have fun.

I allow SSH access on my CPanel dedicated server, but only after a simple fax of a drivers license. It can't be that hard to fax a license.

if i would open ssh , i would place it in chroot (luckly we, there are guys the patch OpenSSH), so nobody could walk all the system

. . . It can't be that hard to fax a license.
And dead easy to forge one too.

If you put your time at it, you could forge a lot of identification methods.

SSH is nice for advanced users but makes the server much easier to root as the user often can run their own programs and compilers

SSH is nice for advanced users but makes the server much easier to root as the user often can run their own programs and compilers
That's totally inaccurate, same things can be done running php/perl

That's totally inaccurate, same things can be done running php/perl

Somethings can but it is much easier to secure PHP than a shell.

Ok, try to upload phpshell and let me know ;)

Ok, try to upload phpshell and let me know ;)

PHPshell can be prevented to a much larger degree than limiting a shell account. I am not saying php is safe but safer.

Somethings can but it is much easier to secure PHP than a shell.

PHPshell can be prevented to a much larger degree than limiting a shell account. I am not saying php is safe but safer.

Your statements are entirely invalid because whether it's PHP, Perl, SSH, Telnet, etc., running commands directly require a secure local system which applies to every medium a user is able to get into. It doesn't matter if it's a PHP-based shell with a form command-line or a user account with SSH access to a shell.

In a nutshell, the local system is exactly the same no matter how a user interacts with it.

As a rule I disable SSH for all new accounts. If someone needs it, then they know what they are doing and/or I can evaluate whether or not they should be allowed to use it.

I do agree that having too many people with access to shell is not a good idea.

cheers
chris

Here's what we do, and it's something a lot of providers are adapting to although you still have to special request it. We ask for a cash deposit (depending on your country) for access.

Your statements are entirely invalid because whether it's PHP, Perl, SSH, Telnet, etc., running commands directly require a secure local system which applies to every medium a user is able to get into. It doesn't matter if it's a PHP-based shell with a form command-line or a user account with SSH access to a shell.

In a nutshell, the local system is exactly the same no matter how a user interacts with it.

I dont think you get my point. In php it is possible to disable a lot of the "dangeous" commands which is much harder to do in a shell

I dont think you get my point. In php it is possible to disable a lot of the "dangeous" commands which is much harder to do in a shell

Yes, but due to the people that are coding a lot of the php applications out there.. doing this disables the functionality of certain code. Personally, I'd rather not run it. However, try explaining that to your customer who doesn't understand much about system administration and security.

Questions to ask yourself before giving shell access to customers:

How often are you keeping your kernel up to date? ( Based on vulnernabilities and not versions )

Will you implement any extra security? (A jail would be a good start.)

Who is requesting access? Do you want them to have access?

Ask them what they need it for, if they can't provide a valid reason.. offer them another solution and tell them no (as nice as possible). People will be understanding if you have another solution that works or valid reasons.

Just a few thoughts anyways..

How often are you keeping your kernel up to date? ( Based on vulnernabilities and not versions )

Your kernel is only a FRACTION of what needs to be kept up-to-date. I would say approx. 85 to 93% of all exploits which result in a more privledged user, or superuser, are software-based vulnerabilities and not just a kernel overflow, etc.

This includes SSH, Sendmail/Exim/Qmail/Postfix, Apache (and its modules, remember when 'jixinx' created the self-propagating worm based off openssl-too-open?), etc. can all result in the same fate as any insecure kernel version. And it's not just root that kills -- Don't forget that openssltooopen did NOT root the user (since Apache, almost 99.999% of the time runs as 'nobody), but it caused the setup of a huge DDoS net which did more damage than a superuser cracker since entire networks were going offline, not just a 'rm -fr /*'

Another way to help reduce the amount of damage a user can do is to chroot as much as possible. We set up a honeypot once and laughed as the cracker could do next to nothing and didn't know how to break out of his environment to gain root. He couldn't even remove our DNS zone files (this was a named exploit entry). We were vuln., had a cracker in the system, and in theory our users would be just fine and have no loss of data, etc.

Furthermore, while you may be secure from remote-based attacks, giving a user access to your filesystem (PHP, SSH, etc.) is alot more dangurous than someone trying to get in without any access at all.

Your kernel is only a FRACTION of what needs to be kept up-to-date. I would say approx. 85 to 93% of all exploits which result in a more privledged user, or superuser, are software-based vulnerabilities and not just a kernel overflow, etc.

This includes SSH, Sendmail/Exim/Qmail/Postfix, Apache (and its modules, remember when 'jixinx' created the self-propagating worm based off openssl-too-open?), etc. can all result in the same fate as any insecure kernel version. And it's not just root that kills -- Don't forget that openssltooopen did NOT root the user (since Apache, almost 99.999% of the time runs as 'nobody), but it caused the setup of a huge DDoS net which did more damage than a superuser cracker since entire networks were going offline, not just a 'rm -fr /*'

Another way to help reduce the amount of damage a user can do is to chroot as much as possible. We set up a honeypot once and laughed as the cracker could do next to nothing and didn't know how to break out of his environment to gain root. He couldn't even remove our DNS zone files (this was a named exploit entry).

Furthermore, while you may be secure from remote-based attacks, giving a user access to your filesystem (PHP, SSH, etc.) is alot more dangurous than someone trying to get in without any access at all.


My train of thought is:

If he had to ask, then no is the only answer.

However, yes.. everything you said is correct.

All the services you listed could by theory be used to compromise the machine from a remote location. The impact that is caused could be brought down to a minimal level by setting the enviorment properly and just keeping things up to date. We're talking about giving local access here, so the services should be thought about way before you think about adding local users to your machine (IMHO).

I would give users SSH access on my OpenBSD machines faster than I would on my linux machines.. but that's just because OpenBSD has proved itself to me. :)

but that's just because OpenBSD has proved itself to me. :)

I love OpenBSD, however I'm sort of limited to mostly Linux in a sense that all these popular control panels the end-users want (read: non-technical customer) don't really have a good *BSD (OpenBSD/FreeBSD mainly) option available although I have FreeBSD+cPanel here but Linux is the most seen because Linux is what sticks into the customer's head. Redhat, Fedora, Linspire, blah blah... Nobody knows FreeBSD ;-(

I love OpenBSD, however I'm sort of limited to mostly Linux in a sense that all these popular control panels the end-users want (read: non-technical customer) don't really have a good *BSD (OpenBSD/FreeBSD mainly) option available although I have FreeBSD+cPanel here but Linux is the most seen because Linux is what sticks into the customer's head. Redhat, Fedora, Linspire, blah blah... Nobody knows FreeBSD ;-(

FreeBSD is a very good alternative.

I haven't dabbled too much with CPanel/Freebsd, but I recall installing it and having it fail or being incomplete for more times than not.

I guess you raised an important question, what are your main reasons for choosing Linux over FreeBSD for a cpanel enviorment? Does an end user (non technical) really understand the difference? I'd just market it as BSD/UNIX.

I guess you raised an important question, what are your main reasons for choosing Linux over FreeBSD for a cpanel enviorment? Does an end user (non technical) really understand the difference? I'd just market it as BSD/UNIX.

Well, most users who have only Windows at home are more likely to choose "Linux" over something called "FreeBSD" for a few reasons. One, they're used to paying for something... Redhat's up2date subscription, etc. give users a sense of security as where this free "cvs stuff" they might think sounds like the popular CVS Pharmacy stores here in the United States -- Free is "cheap," I mean, Windows isn't free, they paid for it.... I'm rambling but there are more boxes in the retail stores that say "Linux" with a price tag than the lone box of FreeBSD way in the back that ONLY has 4 or so CD's.

My biggest point is that a lot of control panels just don't work well with *BSD or don't have an option of anything but Linux. There are really good things with Plesk+FreeBSD but most of my clients want cPanel because of the free Fantastico instead of paying extra for A PowerPack or better add-on to their Plesk...

the only viable reason I would consider accepting for ssh access is if a user has to do a lot of mysql database importing and dumping. Even then I would likely say no and just tell them to ask me to do it for them or to do it in the gui.

Whilst it is possible to do in php and the like what can be done in ssh the truth is allowing ssh access especialy in a unjailed manner opens up the system a lot more then if the user just has web and ftp access.

the only viable reason I would consider accepting for ssh access is if a user has to do a lot of mysql database importing and dumping. Even then I would likely say no and just tell them to ask me to do it for them or to do it in the gui.

Whilst it is possible to do in php and the like what can be done in ssh the truth is allowing ssh access especialy in a unjailed manner opens up the system a lot more then if the user just has web and ftp access.

True, however *A LOT* of programmers almost require direct command-line access especially when developing complicated applications. It's not just for faster MySQL work V.S. phpmyadmin. If a company is hosting with you and their programming team says, "We need SSH," if they don't get it they'll probably cancel on the spot. Companies listen to programmers and programmers can't make due with just an FTP account.

Now, if you come at them with a moderate deposit refundable once the SSH access is removed -- I'm more than certain the company would have no problem forking it over, and that's when you log their activity (be sure to secure .history or .bash_history, etc.) and review it with your 'security department' before you refund to the credit card.

programmers can't make due with just an FTP account.
That's a load if I ever heard it. As a programmer, about 0.0001% of my programming is done via ssh. With the proper tools , you can do anything you want without having to do anything on the server.

How can offering SSH be a security risk? and do you offer it automaticly to your customers? or do they have to request it? thanks.


have them fax or email you a photo ID [60% wont do it]

We provide JailShell upon request and receipt of a valid photo id (with credibility), justification and a signed liability form.

All accounts are fraud checked beforehand with address lookup & telephone verification regardless if they require SSH or not.

We request photo ID and reason for access.

For people who dont know what they are doing, ssh can be a server disaster just waiting to happen. I really wouldn't let them use it.