Other than general security share with me the reason why or why not basic shared customers should not have shell access.

Give me for and against based on your experience.

Well, most common users don't have knowledge of UNIX commands, so what's the point of giving them access? Anyways, There's absolutely no way I'd be giving out telnet access. SSH maybe.

For: Nothing. There are no positives.

Against:

1. Telnet sends information unencrypted. Any script kiddie out there can view telnet information easily.

2. Your box WILL be hacked eventually and say bye to your customers.

3. Anyone that asks for telnet probably isn't famliar enough with shell commands to use it effectively anyway. 99% of people that actually know what they're doing will ask for SSH... not only for the server's security, but for their own as well.

Other than security issues, there is no reason not to offer it. However isn't your and your customer's security reason enough?

what the others have said is good. i would like to say that SSH access can help for those that have a tar.gz file. uploading the one file then untaring it is faster and quicker then uploading each individual file. that's one of the biggest benefits of having shell access that i can think of. :)

Originally posted by ttremeth
Other than general security share with me the reason why or why not basic shared customers should not have shell access. Are you asking for opinions about granting shell access in general, as in the text above, or about telnet specifically, as in your subject line? Seems like the answers are to the second, telnet, version of the question.

Personally, I wouldn't consider buying a hosting account without SSH access. I know you can do just about everything you need to do to operate a site without it, but to me it makes things so much easier I wouldn't want to do without it.

So there's a reason to offer it: you'll lose some potential customers if you don't.

I will be giving out Shell access with my accounts, but will require a valid form of photo ID from them, ie. Drivers, etc...

Plus, I am also planning on calling them and going over a few basic things, and asking a few questions...

There is one big reason to give SSH access... Mysql... I have found that with certain versions of phpMyAdmin, and other PHP scripts that can backup DB's, they are limited to the DB size they can backup... I have a huge(40MB DB, I think...) and phpBB's backup and my phpMyAdmin version cannot back it up properly...

tell them to share their windows network drive to all and you'll let them have telnet access to your server.. i mean that's how unsafe telnet is these days.. :)

Originally posted by JayC
So there's a reason to offer it: you'll lose some potential customers if you don't.
It's a filter. You can't lose clients that you never had. :)

As service providers, each provider decides what services they want to offer to the public. The public then decides on the basis of what the provider provides, whether or not they utilise the services of that provider.

If you don't want clients using SSH, then don't offer SSH. If clients need SSH, then they don't look to you to provide them with SSH, when you don't offer this as part of your services.

Originally posted by Aussie Bob
It's a filter. You can't lose clients that you never had. :)

As service providers, each provider decides what services they want to offer to the public. The public then decides on the basis of what the provider provides, whether or not they utilise the services of that provider.

If you don't want clients using SSH, then don't offer SSH. If clients need SSH, then they don't look to you to provide them with SSH, when you don't offer this as part of your services.

gee thanks for the explanation, Captain Obvious :stickout:

it might be a good idea to offer SSH, but to have it turned off by default. so, if they need it, let them request it from you and provide a valid reason for needing it. this way, not all your accounts will have it turned on and hopefully it'll stay out of the hands of the clueless customers.

Well, most common users don't have knowledge of UNIX commands, so what's the point of giving them access? Ohhh I dunno... maybe so they can learn?

When a child doesn't know how to read, maybe we shouldn't allow books in the home either?

I think it's important that the host allow those who know how to use SSH, the convenience of using it, and those who don't, the opportunity to learn how.

After posting the above, another issue came to mind which has been brought up on these forums before when this question has been posted.

The only way to truly 'turn off telnet' is to also turn off all other execution ability such as CGI, PHP, etc, etc, etc. Trying to sell hosting without giving the client these abilities would be difficult at best.

A recent slashdot post shows a bit of what I am talking about
http://slashdot.org/article.pl?sid=03/02/03/1531246&mode=thread&tid=162&tid=156

CGI-Shell simulates a shell using CGI. So everybody who has a CGI-directory on a web-server, also has its own shell on it -- comparable with Telnet or SSH. That's really practical, because most webhosters don't offer a shell (for free) -- but do offer CGI. With CGI-Shell you can execute commands, copy files or just explore your webserver. Even a history and auto-completion with tabulator are included. " ...

By turning off telnet access you are merely stopping those with no interest in using it anyway... therefore doing little to no good. Those "without a clue" will not only install scripts with holes like the one in the above post that give them shell access but they also tend to give everyone else on the net shell access to their account because they don't realize they need to secure the script. Those 'with a clue' know how to obtain shell access anyway.

Your best bet is to try and secure your server as best as you can without taking away functionality from the users -- especially if it is functionality they can obtain anyway.

By "banning something useful" you may lose (or not gain) otherwise good accounts while not really securing anything at all.

Originally posted by Deb
Ohhh I dunno... maybe so they can learn?

Learning in a production enviroment is not learning. Its stupidity. Learn on your own on a server that doesn't have half a dozen other people on it. Learn where you won't cost me money.

Shell access is given out once a valid reason is given out. 80% of those I know wouldn't know what to do with shell access of any sort. They have a hard enough time with FTP.

Originally posted by Deb
The only way to truly 'turn off telnet' is to also turn off all other execution ability such as CGI, PHP, etc, etc, etc. Trying to sell hosting without giving the client these abilities would be difficult at best.


Like I said in the other thread, you can disable certain PHP functions through the php.ini file...

:rolleyes:

Originally posted by Deb
Ohhh I dunno... maybe so they can learn?

When a child doesn't know how to read, maybe we shouldn't allow books in the home either?

I think it's important that the host allow those who know how to use SSH, the convenience of using it, and those who don't, the opportunity to learn how.

I wouldn't want to have an experimental server eh? ;) Thanks Acronym BOY

I give out SSH access to EVERY customer, and they have the rights to give out SSH access to anyone else through their control panel up to the limit of user accounts I give them. Does this sound insecure?

Well, it might, except for the fact that every single website on my server is in its own chroot jail, so when the user uses SSH to access the server, they can only access the files in their chroot jail.

I have telnetd completely disabled on my server and will not provide telnet access for ANYONE, no matter what reason.

I think the point is being missed that if you offer other forms of execution that's worth offering then there is a high chance you are allowing them "shell acess" anyway. Therefore you'll have to work toward securing from the inside out in ways such as sirtwist mentions.

As far as education..part of the process is being able to put your new skills to work in a production environment. Telnet, once learned, isn't as useful on your local machine as it is on your production account.

But alas I give up ;) If you feel not allowing shell access is preventing clients et al from having that access, and therefore protecting your servers by all means shut it down. I just shiver at depending on a false sense of security and encourage those that feel that turning it off is "good enough" to strongly consider the NUMEROUS other ways clients can gain that access. Shrug :sleeping:

Originally posted by Deb
I think the point is being missed that if you offer other forms of execution that's worth offering then there is a high chance you are allowing them "shell acess" anyway. Therefore you'll have to work toward securing from the inside out in ways such as sirtwist mentions.

As far as education..part of the process is being able to put your new skills to work in a production environment. Telnet, once learned, isn't as useful on your local machine as it is on your production account.

But alas I give up ;) If you feel not allowing shell access is preventing clients et al from having that access, and therefore protecting your servers by all means shut it down. I just shiver at depending on a false sense of security and encourage those that feel that turning it off is "good enough" to strongly consider the NUMEROUS other ways clients can gain that access. Shrug :sleeping:

Tell that to bob! ;p

You can protect servers from the ignorant, but not from the hacker.

Originally posted by sirtwist
I give out SSH access to EVERY customer, and they have the rights to give out SSH access to anyone else through their control panel up to the limit of user accounts I give them. Does this sound insecure?

Well, it might, except for the fact that every single website on my server is in its own chroot jail, so when the user uses SSH to access the server, they can only access the files in their chroot jail.

I have telnetd completely disabled on my server and will not provide telnet access for ANYONE, no matter what reason.

Youre using Ensim, arent you :) Its virtual file systems are my favorite feature. I dont know why other control panels dont offer that.


Another thing that I would consider and the latest Ensim release provides that, is to restrict access to development tools. G++ and all that hoopla.
Try to imagine 50 out of your 200 client trying to compile some stupid program at the same time... What are the chances of that? pretty slim, but even 10 clients trying to compile something simultaneously will bring your server to a stop...
Provide binaries for most of the popular programs insteadn and maybe offer compilation services where they would pay you a one time fee of $10 to compile something for them, so youre in control of compilation time

Originally posted by Deb

quote:
--------------------------------------------------------------------------------
Well, most common users don't have knowledge of UNIX commands, so what's the point of giving them access?
--------------------------------------------------------------------------------

Ohhh I dunno... maybe so they can learn?

Umm...this would be the prime example of learning wouldn't it:

rm -rf /home


So much for learning!

Umm...this would be the prime example of learning wouldn't it:

rm -r /home


So much for learning! Yeah... I guess they can't delete important files of their own with just a mouse click or two in their FTP client. It's much easier for them to screw up by having to actually manually type 7 or more characters in the correct order :rolleyes:

Once we get real we realize ignorance is dangerous regardless how much you take away. This particular argument (the one about removing shell access to stop ignorant ppl from doing ignorant things) is silly at best. Those who are going to play&break are going to with or without shell access and this argument can only be successful if you decide the best way to prevent them from doing so is to confiscate their computer...or at least the best way to prevent them from doing it on YOUR servers is to cancel their account. The truly ignorant struggle at finding their CLI software, more less logging in.

If the reason for not providing shell access is to prevent ignorance...it's flawed.

My thoughts, is that they don't NEED SSH access all the time. If they want to install something, perhaps support can do it, or temporarily enable it on their account. Just my 2 cents on the matter

It's a personal decision made by a supplier regarding what they offer and what they don't offer to the public. There is no "right" and "wrong" here. For anyone who thinks that their opinions determine what is "right" and "wrong" for us all, need to get a grip on some form of reality. :)

not there's any such thing as a "reality" too. ;)

I agree with Aussie Bob...there is no right or wrong here, anyways, I think that's about all for now

You could get around the no SSH limit by running linux on a old pentium box or something....no one will care if it crashes.

By the way, cpanel offers decompression via its file manager, which renders one pt above (about uploading many small files vs one big one) moot.

My .$02

First off, a host needs to understand, as I'm sure everyone here does, that if someone decides they are going to find a way into your box, they will somehow find a way in. I don't believe that restricting ssh/cgi/etc access is going to stop a determined hacker. Who it will stop is the script kiddie who has no actual knowledge beyond "dood, get shell access, run this script, and you're IN". Hell, it doesn't even have to be a classic script kiddie - it could be someone who's simply a bit curious and has some time to kill. In this regard, I consider restricting shell access to be a matter of "keeping honest people honest".

I personally don't offer shh access as a standard feature on any accounts, but it is available at no extra charge to those who need it.

As for as giving the customer a "learning environment", sorry, not on my machines. I base this on my own experience through the learning curve and the mistakes I've made (and continue to make) along the way. I have a linux/ensim setup here at home on which I do all my learning/experimenting, and I have made some horrible mistakes that, if done on my production servers, would have brought the whole box down.

However, I do agree that simply disabling access to certain services is far from a cure-all - one has to be aware of the other potential security risks that exist, evalaute them, and then take the appropriate steps to ensure their machines are as protected as possible against them.

Finally, of course there is no "right or wrong" here, but that doesn't make the subject any less worthy of discussion :)



.

I dont mind giving people shell access. I have strict rules for background processes and such, and if your box is nice and secure, why not?!

I offer users BOTH TELNET AND SSH access, and if you think I'm stupid for doing so, then you're just ignorant. If you don't want to allow shell access, that's fine, but to deny shell access because you think it's insecure without ever considering CGI and PHP access is just ignorance. If you think the TELNET protocol is insecure, that's fine, but to say you will NEVER run a TELNET server because the TELNET protocol is insecure without ever giving a second thought to the FTP and POP3 servers you're running is just ignorance.

Originally posted by Stomp442
As for as giving the customer a "learning environment", sorry, not on my machines. I base this on my own experience through the learning curve and the mistakes I've made (and continue to make) along the way. I have a linux/ensim setup here at home on which I do all my learning/experimenting, and I have made some horrible mistakes that, if done on my production servers, would have brought the whole box down.

If a customer that has no clue what they're doing can bring down your server, then you have serious security issues that need to be dealt with immediately.

SSH has had more exploits than telnet. SSH is only more universally acceptable because it is encrypted.

Originally posted by seg fault
SSH has had more exploits than telnet. SSH is only more universally acceptable because it is encrypted. am I missing the point but if someone can 'sniff' the username/password from a telnet session that the client might run once in a week seems a lot easier to me to wait around for POP3 traffic. Some people have their mail client set to check for mail every 10-30 minutes and it's nearly always the same as their account password.

Originally posted by ToastyX
If a customer that has no clue what they're doing can bring down your server, then you have serious security issues that need to be dealt with immediately.

Give me shell access on one of the common web server setups, and I can bring the whole server down. Anyone can - it's not exactly rocket science.

.

err, if you can do it with shell access Stomp, you can do it in cgi, php and just about any other scripting language.

Give me shell access on one of the common web server setups, and I can bring the whole server down. Anyone can - it's not exactly rocket science. It's not a matter of whether or not a person can bring a server down. It's a question of whether or not turning off shell access will prevent them from doing so.

I personally do not see offering direct access to a shell account as providing them much more ammunition than the numerous other services that are not shut down offer.

I do agree that each host is perfectly correct in their own decision making regardless of what it may be. Each host has its own reasons for offering, or not offering, whatever services they choose. In the end the clients decide what is right and what is wrong and lucky for the hosts there are -many- different types of clients each with their own specific requirements that vary greatly between each other. So obviously what works for one host may not work for another.

Again, my only advise is to be cautious with your reasoning to ensure the answer you give someone who asks "Why not?" is one of sound business sense.

Originally posted by seg fault
err, if you can do it with shell access Stomp, you can do it in cgi, php and just about any other scripting language.

Right, I know that. My response was to ToastyX, who is of the opinion that only a server with "serious security issues" can be brought down through shell access by a clueless user. He is mistaken.

As I stated in my previous post, you need to look at and evaluate all potential security risks, and deal with them accordingly, and in a manner that does not impact your clients in a negative way but still allows you to sleep well at night. That means looking at cgi, php, ftp, ssh, telnet, smtp, etc... There's no magic bullet, but common sense and a bit of dilligence in matters of server security in general are a damned good substitute.

Anyway, you're not going to stop someone who is determined to get in, but there's no reason to make it easy for them either, that's all I'm saying.

.