Results 1 to 22 of 22
Thread: To SSH or not to SSH
-
06-11-2002, 07:09 AM #1Junior Guru Wannabe
- Join Date
- Feb 2002
- Location
- texas
- Posts
- 88
To SSH or not to SSH
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. Matt J
Where Customer Services is #1
Virtual Plans Reseller Plans Dedicated Servers
Jatol Internet Service www.jatol.com
-
06-11-2002, 08:01 AM #2Web Hosting Master
- Join Date
- May 2001
- Location
- @ Work - Usually!
- Posts
- 835
I dont know about anyone else - but I would find it difficult to talk about my security issues on a public forum.
-
06-11-2002, 09:11 AM #3Junior Guru Wannabe
- Join Date
- Feb 2002
- Location
- texas
- Posts
- 88
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.
Matt J
Where Customer Services is #1
Virtual Plans Reseller Plans Dedicated Servers
Jatol Internet Service www.jatol.com
-
06-11-2002, 09:34 AM #4Junior Guru Wannabe
- Join Date
- Jun 2001
- Location
- Columbus, OH
- Posts
- 35
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).Matt - matt@fanhome.com
http://www.fanhome.com
FanHome.com - Where Sports Fans Connect
-
06-11-2002, 09:43 AM #5Junior Guru Wannabe
- Join Date
- Feb 2002
- Location
- texas
- Posts
- 88
Matt J
Where Customer Services is #1
Virtual Plans Reseller Plans Dedicated Servers
Jatol Internet Service www.jatol.com
-
06-11-2002, 09:55 AM #6Junior Guru Wannabe
- Join Date
- Jun 2001
- Location
- Columbus, OH
- Posts
- 35
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?).Matt - matt@fanhome.com
http://www.fanhome.com
FanHome.com - Where Sports Fans Connect
-
06-11-2002, 10:26 AM #7Disabled
- Join Date
- Jun 2002
- Location
- New Jersey
- Posts
- 19
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.
-
06-11-2002, 10:33 AM #8Newbie
- Join Date
- Apr 2002
- Posts
- 20
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.
-
06-11-2002, 10:36 AM #9Web Hosting Master
- Join Date
- Apr 2001
- Location
- Depok, Indonesia
- Posts
- 988
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.
-
06-11-2002, 10:49 AM #10Web Hosting Master
- Join Date
- Dec 2001
- Location
- Detroit, MI
- Posts
- 1,067
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.<!-- boo! -->
-
06-11-2002, 11:05 AM #11Junior Guru Wannabe
- Join Date
- Jun 2001
- Location
- Columbus, OH
- Posts
- 35
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.
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.Matt - matt@fanhome.com
http://www.fanhome.com
FanHome.com - Where Sports Fans Connect
-
06-11-2002, 11:09 AM #12Web Hosting Master
- Join Date
- Dec 2001
- Location
- Detroit, MI
- Posts
- 1,067
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.<!-- boo! -->
-
06-11-2002, 11:32 AM #13Junior Guru Wannabe
- Join Date
- Apr 2002
- Location
- Fairfax, VA
- Posts
- 73
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.
DaveDave Glick
creativenews.com - creative news for creative people.
glickcreative.com - look ma, I have a portfolio!
-
06-11-2002, 11:47 AM #14Disabled
- Join Date
- Jun 2002
- Location
- New Jersey
- Posts
- 19
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.
#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
-
06-11-2002, 12:15 PM #15Junior Guru Wannabe
- Join Date
- Jun 2001
- Location
- Columbus, OH
- Posts
- 35
[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.Matt - matt@fanhome.com
http://www.fanhome.com
FanHome.com - Where Sports Fans Connect
-
06-11-2002, 12:57 PM #16Web Hosting Master
- Join Date
- Dec 2001
- Location
- Detroit, MI
- Posts
- 1,067
#Prevent starting a new shell that CAN unset the history files
bash () { /usr/local/bin/bash -login ; } ; readonly bash
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.<!-- boo! -->
-
06-11-2002, 02:14 PM #17Web Hosting Master
- Join Date
- Dec 2001
- Posts
- 1,029
Re: To SSH or not to SSH
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.ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ
-
06-11-2002, 02:27 PM #18Web Hosting Master
- Join Date
- May 2002
- Location
- Edmonton, Canada
- Posts
- 978
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.
-MattLast edited by RackNine; 06-11-2002 at 02:41 PM.
-
06-11-2002, 02:36 PM #19Disabled
- Join Date
- Jun 2002
- Location
- New Jersey
- Posts
- 19
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.
-
06-11-2002, 06:18 PM #20Web Hosting Master
- Join Date
- Apr 2001
- Location
- Depok, Indonesia
- Posts
- 988
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.
-
06-11-2002, 06:20 PM #21Web Hosting Master
- Join Date
- May 2002
- Location
- Edmonton, Canada
- Posts
- 978
Er... firewall. Forgot to mention that part. Thanks
-Matt
-
06-11-2002, 06:23 PM #22Web Hosting Master
- Join Date
- Apr 2001
- Location
- Depok, Indonesia
- Posts
- 988
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.