I am curious; I see loads of hosts offering SSH on their plans. Knowing what I know about SSH (which, is not a lot, just enough to make me dangerous), it seems like this is somewhat dangerous for everyone involved on the server that a host would offer SSH on. I would almost call it irresponsible, to allow someone to have SSH on a server where others are.

Anyway, I was wondering what everyone's experience with hosts that provided SSH to their clients was. Did it cause problems? Anyone have a crazed client who killed their server? Etc, etc

Thanks in advance.

I dont know about anyone else - but I would find it difficult to talk about my security issues on a public forum. :eek:

Well, I wasn't meaning to ask everyone to discuss exact problems they have had. I am really curious if everyone else sees this as a major security problem, or if it really isn't. From what I have seen it really looks like a host that offers SSH on a server is putting every single person who is on that server at risk.

Huh? SSH is a secure shell daemon. Have you used Telnet in the past? Telnet is horribly, horribly insecure. All your text, login name and password, etc. is sent in clear text, unencrypted, so anyone watching could grab them.

SSH (and SSH2), on the other hand, is encrypted, thereby ensuring casual crackers sniffing the lines won't get your login info nor see what you are doing. It is very much a GoodThing(TM). Telnet is a Badthing(TM).

read this (http://www.webhostingtalk.com/showthread.php?s=&threadid=53880&highlight=ssh)

Oh, so you mean giving shell access in general to shared clients, not necessarily inherent SSH problems?

I would think shell access is only a problem if you set up the server incorrectly. Unix is, of course, a multi-user system. It can easily handle multiple user accounts and permissions and security. If you set it up correctly, there should be no inherent security risks, otherwise Unix (linux, etc.) wouldn't be terribly useful (wouldn't really be multi-user, would it?).

You are completely wrong. It is your own personal policy or preference whether you want to be logged into a box where other users are, but its not feesible to think this way. If you want a box that only you can log into, get your own server. As far as SSH goes...its better than telnet. You really have nothing to worry about SSHing to a box.

I have been with hosts that offer SSH and haven't had any problems.

I'm currently with a host that doesn't offer SSH access for security reasons. That's perfectly fine for me. I was previously told SSH still poses security problems and that's why they don't grant access.

But I know others who won't go to a host that doesn't offer SSH. I guess it all depends on how important it is to you. :)

Disabling shell access is useless if you don't disable CGI or PHP as well. A determined cracker can execute commands from a CGI scripts. It is even very common to find CGI scripts providing shell access installed on rogue accounts.

Shell access doesn't really pose a security risk, but it is certainly harder to control than anything else.

An obvious example is that a customer can upload a "fork bomb" via FTP and execute it via CGI, but then you have a trace of the entire process. That same customer with shell access can log in, run vi, paste the fork bomb, execute it, and remove all traces from their history file with ease. Not a great example, but an example nontheless of how shell access is a bit harder to control.

The argument against telnet versus ssh is actually not a very good argument until POP3 and FTP go away since all passwords are transmitted in clear text over both of those protocols as well. Removing telnet just removes 1/3rd of that problem, and in all honesty sniffing for POP3 will be a lot more fruitful since many people check their email pretty frequently.

The bottom line in my oppinion is basically, provide shell access on a case by case basis and all should be well.

Originally posted by DizixCom
The argument against telnet versus ssh is actually not a very good argument until POP3 and FTP go away since all passwords are transmitted in clear text over both of those protocols as well. Removing telnet just removes 1/3rd of that problem, and in all honesty sniffing for POP3 will be a lot more fruitful since many people check their email pretty frequently.

That is true if your host does not support SFTP (or FTP via SSH2) or secure POP3.

But few people check root's email via POP3 (are you even allowed to?) nor log in as root via FTP (won't let you) but often you are forced to SU to other users (namely root) via the shell, so I would still think SSH would be a requirement if you're root-ing around often. :D

Ahh, yes, the point about su-ing to root is well understood. For the record, I disable telnet (er rather, I don't enable it since it's disabled by default in FreeBSD) as well. Certainly doesn't hurt anything.

The only other concern I have about enabling SSH (shell) access is that the traffic is not metered that way and using SFTP it's easy to get by monthly allowances.

I can't really speak as an admin from the server side of things, but I can speak as a knowledgable end user and developer. I wouldn't say SSH is irresponsible at all. As it's been pointed out, SSH is secure - it's no more of a danger than other server-side executable code like CGI or PHP (as was also pointed out by someone). I for one wouldn't be able to host with anyone who didn't have SSH - as a developer it comes in very handy and is almost essential to my web application development.

Dave

Originally posted by DizixCom
That same customer with shell access can log in, run vi, paste the fork bomb, execute it, and remove all traces from their history file with ease.

In a typical setup yes, but if you research this for 5 minutes, their are ways to prohibit people from from tampering with any history files. I know this is a fact with bash, which (from what I've seen) is one of the most common shell's short of tcsh. I haven't bothered to research how to do it with tcsh, but with bash its as simple as putting the following in the GLOBAL profile (On my system, and most i'm sure, its /etc/profile) :

#Prevent unsetting of history files
readonly HISTFILE
readonly HISTFILESIZE

#Prevent starting a new shell that CAN unset the history files
bash () { /usr/local/bin/bash -login ; } ; readonly bash

[b]Originally posted by DizixCom [/ib]
Ahh, yes, the point about su-ing to root is well understood. For the record, I disable telnet (er rather, I don't enable it since it's disabled by default in FreeBSD) as well. Certainly doesn't hurt anything.

The only other concern I have about enabling SSH (shell) access is that the traffic is not metered that way and using SFTP it's easy to get by monthly allowances.

It's understandable -- you're looking at SSH from a host perspective and I'm looking at it from a dedicated (or owned) server perspective, so we're on two different states of minds I think :D. I assume regular shared-server users aren't allowed root access to the shared boxen. I guess it could be useful if you (admin) were in a client login and needed to su to do some modifications. Otherwise you are correct SSH isn't really useful since the rest of the user logins are insecure.

#Prevent starting a new shell that CAN unset the history files
bash () { /usr/local/bin/bash -login ; } ; readonly bash
And if I run /bin/sh? I'm no longer running bash, but sh and there is no longer a history file. Or I can simply rm ~./bash_history and poof, off she goes.

The bottom line is that providing shell access is giving up a good deal of control, and while there are ways to lock things up (chroot, jail, restricted shells, etc), most sysadmin don't bother. It's a while lot easier to delegate shell access only to users who have good intentions and a solid need.

That said, it is not entirely good policy to say "no shell access", but it isn't so bad if you ask your customers why they require it and are just generally careful with it. As said before, a well administered system shouldn't have too many problems to begin with that cannot be exposed via CGI anyway.

Originally posted by snikle
I am curious; I see loads of hosts offering SSH on their plans. Knowing what I know about SSH (which, is not a lot, just enough to make me dangerous), it seems like this is somewhat dangerous for everyone involved on the server that a host would offer SSH on. I would almost call it irresponsible, to allow someone to have SSH on a server where others are.

Anyway, I was wondering what everyone's experience with hosts that provided SSH to their clients was. Did it cause problems? Anyone have a crazed client who killed their server? Etc, etc

Thanks in advance.

How can you come to the conclusion that offering SSH is somewhat dangerous and almost irresponsible on a shared server when you don't know a lot about SSH? UNIX and Linux were DESIGNED to handle multiple remote users. It's not like anyone can do whatever they want. What makes you think it's dangerous? If a client can kill your server, then you have major security problems.

The biggest concern I've found with offering SSH was obviously the ability for clients to run their own daemons and other nasty toys off the server which could either user up resources with stuff they shouldn't run (MUD's, IRC servers, etc.) or completely destabilize it using poorly written code executed from the prompt.

Quick way to fix this: Process killer. Any process not owned (or at least created) by Apache may run at XX percent for more than a couple seconds.

Providing SSH access is a good way to allow real-time modification of client scripts and web files as well as offering other tools to maintain their site online. Combined with a good yet simple control panel / webmail system gives you a heck of a nice environment for your users to work in.

-Matt

Any real UNIX admin knows that there are ways to limit the amount of background processes, and not even allow users to run things while they are not logged in. There are user classes as well (in most modern day unices) that limit how much memory and processor ticks they can use.

You can use jails and other various chrooting techniques, but the bottom line is, dont offer shells if you do not think you can handle the everpresent task of keeping an eye on rampant users. Good judgement comes into play as well. If you get a customer doing some ecommerce things with their site, chances are they are not going to be malicious. On the contrary, if someone hosts www.myfirstandlastname.org, and it is about the various cracks/hacks they've developed, tell them to take a hike.

Alot more politics should be in place when shell accounts are in question. If so, there would be alot less DoS attacks and such things going around ruining the net stability for everyone else.

Originally posted by RackNine
Quick way to fix user ability to run daemons: Process killer. Any process not owned (or at least created) by Apache may run at XX percent for more than a couple seconds.


Another way: block any incoming traffic except to a few important ports, block any outgoing traffic to unnessary ports (irc).

Er... firewall. Forgot to mention that part. Thanks :)

-Matt

To monitor user activity, one could use process accounting. It won't show you the exact command that a user types on the command line, but it is better than nothing. Relying to bash_history files is useless as another poster pointed out, there are LOTS of ways to execute a command without being logged to a history file.