Since 1996, when we started as resellers, we never offered shell access until we got on to cpanel, my question (poll) is do you offer clients shell access?

If you think about it, what cant the customer do in ftp that they have to do in shell?

What about security issues? I know many large companies like that still don't offer shell access, they turn off telnet completely

What do you do if a customer installs a eggbot with about 20 processes going? (IE: like we had a few weeks ago) ? suspending the account wont do any good...

what about lurching? where customers just go into shell to browse around?

Whats the good things about offering shell access?

Anymore almost any box with telnet running on it has about a 80% better chance of being hacked. So i would say no on shell access, besides the only reasons someone might need shell access are usually bad ones.

About 4 months ago we had a root kit placed on one of our servers. it was caught within an hour, did not cause any serious interruption, but if it had prolongediti would have been a disaster.

since then we provide ssh only for select clients we know and yes we do loose biz because we dont offer it.

but we save biz also because we eliminate the down times associated with hacker intrusion.

just say no......


dos centavos

el_g

Originally posted by AlaskanWolf
If you think about it, what cant the customer do in ftp that they have to do in shell?


Lots of stuff. Compiling CGI scripts, for a start.

A better question would be "what security holes can a customer exploit from sh which they can't exploit via perl?", and the answer is "none". If you allow users to run CGI scripts then you might as well also give them shell access; if you're worried about security holes, then fix the security holes, don't obfuscate things by limiting shell access.

If you think about it, what cant the customer do in ftp that they have to do in shell?
For one, lots of people prefer the mysql prompt over phpmyadmin. There are just some people that are more comfortable using a shell than using a control panel (for cron jobs for example). Hardly any of our customers use their shells anyway...

What about security issues?
Use SSH and patch the system.

What do you do if a customer installs a eggbot with about 20 processes going? (IE: like we had a few weeks ago) ? suspending the account wont do any good...
Remind them that no irc-related processes are allowed to run (and no background processes, if you don't allow it). If they refuse to listen, cancel the account or revoke their telnet/ssh.

what about lurching? where customers just go into shell to browse around?
Just make sure the user can't read any of the system-critical files. Even if they don't have shell, a perl/php script can easily read directories and files on the system (the code in php is ridiculously easy too).

Whats the good things about offering shell access?Some customers like to have shell access. If you don't offer it, they'll go elsewhere.

Many scripts these days come with shell scripts for installing and configuring. Also, many people, myself included, enjoy using Pico to create php scripts and use pine to check email.

I agree 100% with cperciva.

Allowing users to execute/read files with cgi is no more secure than allowing the same thing through a shell.

However, allowing them a shell does allow them to use programs which require a terminal. We prohibit use of the shell for anything other than the maintaining of their web content.

And we don't have pine/pico installed, although we probably would if a user required it. We have vim installed, though.

The biggest use for it is setting of cron jobs (which we allow if they don't get carried away), using the mysql terminal, and cgi program development/installation.

We have one customer that uses shell for everything. He's aware of the control panel but just doesn't use it. In fact, (as I know him personally in 'real life') I know his own desktop computer doesn't have a GUI. He runs everything (and I mean everything) from command line linux, and views websites as text only for the most part.. He's an odd child :)

Giving shell to a customer isn't something we have written in black and white. In fact it's not even advertised as being available, though the TOS does cover anything that might end up there. We feel it's a responsibility, not a right and dole out shell access on a case by case basis. When you're dealing with real human beings, making something 100% this way or that isn't much of a reality. Of course granting it also means they're made fully aware they're being watched like a hawk, and if we spot any funny business we'll drop an axe on them.

This will sound trite, but we've been fortunate to have a very good collection of customers, and being 'watchful' doesn't take up as much time as you'd expect. For the most part we're able to leave them to their own devices.

Greg Moore

If you offer FTP you might as well offer SSH and Telnet. If you think that FTP is a lot more secure than SSH or Telnet, then your kidding yourself.

Only after I recieve a copy of their ID.

I theorize that people feel more accountable when they know you've got a copy of their vitals.

Not that there's really any way to check the DL/ID is real but so far it seems to work.

We require ID before opening up a shell account.

It takes some work and know-how, but we offer chrooted shell access. This allows CGIs and command-line scripts to operate in precisely the same environment and keeps users away from the 'real' system.