Results 1 to 26 of 26
  1. #1
    Join Date
    Apr 2002
    Posts
    221

    SSH - Dangerous?

    I was looking to purchase a reseller account, and found one I like, but they do not offer SSH, as it can allow easy access for a hacker. How much damage can you really do, accidentally, and purposfully, with SSH access?

    - James

  2. #2
    Join Date
    Oct 2001
    Location
    Miami,FL
    Posts
    612
    With SSH you CANT distroy a server without intentions...SSH is dangerous if user knows what he is doing
    Joman Sierra
    http://www.dominet.net

  3. #3
    Join Date
    May 2001
    Location
    Dayton, Ohio
    Posts
    4,962
    Originally posted by dominet
    With SSH you CANT distroy a server without intentions...SSH is dangerous if user knows what he is doing

    SSH is just as dangerous if you don't know what your doing.... If you see a command and wonder what it does and try it, it could be the one that formats your hard drive... This is if your root

  4. #4
    Join Date
    Oct 2001
    Location
    Miami,FL
    Posts
    612
    He is asking about a "Webhosting company ssh access" for example a reseller package.


    You'll never get root from a hosting company.
    Joman Sierra
    http://www.dominet.net

  5. #5
    Join Date
    Apr 2002
    Location
    USA
    Posts
    5,779

    SSH

    can be used by a hacker to extract passwords etc form others accounts on a shared server. We give it to few clients and we require a valid CC on file along with a valid ID, drivers lic etc faxed to us. Along with a reason in writting they need SSH. Very few people really need it, some see it as being offered and think I want that. Our policy is to protect everyone on our server, when we give it we want to know it is for a legit reason and the person that is using it is whom they say they are.

    Monte

  6. #6
    Join Date
    Jul 2001
    Location
    Melbourne, AU
    Posts
    1,392
    You will find that a lot of hosts these days will not provide SSH access and when they do, a lot (such as ourselves) will require some form of ID faxed before this type of access is granted.
    SERVSTRA | THE HIGH BANDWIDTH SERVER SPECIALISTS
    Lowest prices on 2Gbps, 5Gbps & 10Gbps DEDICATED unmetered servers!!!
    █ Custom 10Gbps unmetered clustered server solutions! Email us for more info!
    Over 24 world wide locations to choose from!

  7. #7
    Join Date
    Feb 2002
    Location
    Australia
    Posts
    24,009
    We don't allow it, period. Lose potential clients that way, but existing clients appreciate the extra security in the shared hosting environment.
    • AussieHost.com • Aussie Bob, host since 2001 •
    • Host Multiple Domains on Fast Australian Servers!! •

  8. #8
    Join Date
    Feb 2002
    Posts
    956
    An example of abused SSH: On sourceforge.net they give out SSH but a lot of people use it to read sensitive info like passwords from a file in someone elses account (Like when a project I develop on sourceforge had thier forum erased)

  9. #9
    Originally posted by dominet
    You'll never get root from a hosting company.
    Are you sure?
    Powered by AMD & FreeBSD.
    "Documentation is like sex:
    when it is good, it is very, very good;
    and when it is bad, it is better than nothing."

  10. #10
    SSH is only dangerous if the server is set up completely wrong to begin with.

    The fact that they are worried about SSH as a security risk would be enough to point me in a different direction even if I didn't need SSH.
    Dr. Colin Percival, FreeBSD Security Officer
    Online backups for the truly paranoid: http://www.tarsnap.com/

  11. #11

    re

    Shell is the easiest way to give root access to your costumer(s).
    Also if you want high security then disallow root login in ssd-config and use "su", add user "admin" (or other name you like) and put "admin" in group "root" (on Linux servers) or in group "wheel" (on BSD servers), then "chmod 750 <whereis_is_su> && chmod +s <where_is_su>" <-- by doing this you can login as root only if you know root password and password for user admin.
    ..and use suexec..
    Powered by AMD & FreeBSD.
    "Documentation is like sex:
    when it is good, it is very, very good;
    and when it is bad, it is better than nothing."

  12. #12

    Re: re

    Originally posted by Miha
    ... group "wheel" (on BSD servers), then "chmod 750 <whereis_is_su> && chmod +s <where_is_su>"
    This is unnecessary on BSD, since BSD `su` already checks for wheel membership if you're trying to su root.

    In fact, it is also a nuisance, since people with several accounts often find it useful to `su` between them.

    (In short, don't do that on a BSD box.)
    Dr. Colin Percival, FreeBSD Security Officer
    Online backups for the truly paranoid: http://www.tarsnap.com/

  13. #13
    Join Date
    Jul 2001
    Location
    Singapore
    Posts
    1,790
    Hi,

    I think SSH and cgi is almost the same... dangerous

    Just my thought

    Kindest regards,
    Choon

  14. #14
    Join Date
    Dec 2001
    Posts
    1,029

    Re: SSH - Dangerous?

    Originally posted by zRedDice
    I was looking to purchase a reseller account, and found one I like, but they do not offer SSH, as it can allow easy access for a hacker. How much damage can you really do, accidentally, and purposfully, with SSH access?

    - James
    Blocking SSH access won't stop a determined cracker. The worst you can do accidentally is mess up your own account or delete your own web site. The worst you can do on purpose is exploiting security holes on the server to gain root access and do malicious damage, but you have to know what you're doing, and that can be done through CGI scripts. On a properly secured server, people aren't going to be able to extract passwords or read sensitive information. UNIX was designed to allow users to login remotely. People are afraid of what they don't know. If they're worried about giving shell access because of a reason like "security risk," then that shows ignorance.
    ŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻŻ

  15. #15
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051
    Well now, this isn't altogether true of all situations. CGI scripts open up problems too, but you can do a lot to deny CGI and PHP scripts and whatnot, from being able to do things they don't need to (i.e., viewing files, running compilers, etc.). If you don't provide shell access and you configure it so CGI and PHP scripts don't have anything but database connectivity, read and write access to their own directories, etc. -- basically, all that any CGI or PHP script should need to do anyway -- then how is a CGI or PHP script able to be just as insecure? This is a lot easier to control and you don't have to worry about chroots, wrappers and and whatnot either, since people can just break out of them often. On the issue of shell access, there's simply far too many things to cover compared to other type's of access. And although you should cover that ground anyway, it's difficult to cover it all, especially compared to other interfaces that don't offer such a great variety of means to do things like shell access gives users. Otherwise you'd have to do this same thing on the user-level for every user in some manner.

    True though, that people having shell access shouldn't pose any more of a security risk, since that shouldn't matter, assuming a system is configured properly. However, people can do more than just try and crack the server too. They can do a lot of annoying things like try and run IRC scripts, open up a service on some high port, or who knows what. Also, it's a lot easier to run a password cracker locally and without shell, good luck doing this with a CGI script that's not given permission to do such a thing. There's 100's of more examples to support the fact that allowing shell access will indeed open up a greater potential and means to have your system compromised. Of course that alone shouldn't be an issue, but it certainly makes the changes greater -- not to mention it's another service with potential exploits (and SSH has had it's share). Of course, that's also not in regards to who is allowed access or not, but the service itself. I agree that if allowing shell access is going to get you owned, that you're pretty much going to be anyway, but it actually does open up a lot more ways for someone to try and run exploits. There's ways to prevent this by 95% or more, but there's always a few ways that are more available due to having shell.


    Also, since most people don't need shell access, why give it out? That's more users that have a greater potential. Also, they can use your server as a jump point, it's more difficult to control processes than it would be for a CGI or PHP script on scripts or tools they run, etc. and all of that can more easily be avoided with CGI and PHP than shell access. After all, there's a lot more ways to do things and a lot more ways around things in shell and it's simply more difficult to control. Secure system or not, shell access opens up a lot of potential issues and it indeed does open up more potential for being exploited. Any interface you allow has problems, but shell has so much people can do with it, that it's much more difficult to cover all the potentials than you could with another interface like CGI, PHP, FTP, etc.

  16. #16
    Join Date
    Jul 2000
    Location
    Colorado Springs, CO
    Posts
    2,280
    I agree here, we do allow ssh ourselves but we don't enable it for accounts by default. When a user requests SSH access we give it to them, no questions asked.
    Greg Landis | Founder Jaguarpc - Keeping websites happy since 1998
    Managed IT Solutions - Business hosting | Virtual Private Servers | Cloud VPS Hosting | Dedicated servers | Backup service
    Follow us @ Facebook.com/Jaguarpc | Twitter: @JaguarPC | (888)-338-5261 | sales @ jaguarpc.com

  17. #17
    Join Date
    May 2001
    Posts
    1,513
    I like to run unix commands from SSH, such as pico, mv, top, du, zcat, and rm -r, etc. I also want to be able to compile and configure modules without having to do them locally on my own machine. To me, SSH is easier, faster and some unix commands don't work in a perl file.

    This reminds me when I had a site at Hypermart, they accused me of cracking, and closed my account for running simple commands like cd. Of course, I wasn't cracking. I was just curious how many other domains were on the server, so I kept backing up directories with cd .. and saw all the users, system files, etc.; but I had no intent of doing any damage. Just curious, that's all. Of course Hypermart appears to know little about security. I spent 2 years writing many perl programs, and they were all copied illegally and all of my directories were wiped out by a cracker, even though I had them protected with .htaccess and other methods.

    Both sides are interesting. I don't know which one to believe. So-called security experts seem to say that SSH is risk-free if you have a person set up the server that knows what they are doing.
    Last edited by chrisb; 06-09-2002 at 05:49 AM.

  18. #18
    Seems the main point of offering SSH is so customers don't have to send their passwords (and web pages, too) in clear text.

    Two questions:

    1) Isn't it really a matter of setting up a Linux or FreeBSD server and the user accounts of those who have SSH correctly so that SSH is not a problem? Or is SSH an inherent problem one can not "configure/proper sysadmin away"?

    2) If not SSH, what does one offer clients that don't want to send their logon id and password in clear text via FTP?


    Maybe we need a "how to configure a server for secure use of SSH" FAQ -- or is that not possible?


    Thanks,

    Louis

  19. #19
    Join Date
    Apr 2002
    Location
    Hollywood, CA
    Posts
    3,046

    i wouldnt....

    i wouldnt buy an account from a company that disallowed ssh access . I think lots of people still use there shell . If a hacker or cracker wants into your system bad enough and they have the know how , they'll get in . I figure the worst thing to do is give a person shell access who has no idea what they're doing , im sure that costs the consumer money and the techs headaches , just like a hacker or cracker would do as well.

  20. #20
    Greetings:

    While SSH is secure in terms of the transmission of information, any form of remote command access may allow a potential hacker clues as to the layout of the land.

    Furthermore, while permissions may impact / impeed, they are still able to see --> which can be a privacy issue.

    We see more and more shared hosting companies removing remote access as a feature.

    Or as some stated here faxing identification, and potentially only allowing SSH from static IP addresses of people who present such identification.
    ---
    Peter M. Abraham
    LinkedIn Profile

  21. #21
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051

    Re: i wouldnt....

    Originally posted by case
    i wouldnt buy an account from a company that disallowed ssh access . I think lots of people still use there shell . If a hacker or cracker wants into your system bad enough and they have the know how , they'll get in . I figure the worst thing to do is give a person shell access who has no idea what they're doing , im sure that costs the consumer money and the techs headaches , just like a hacker or cracker would do as well.
    Indeed, if you are going to definitely get 'rooted' by simply giving out shell access, you're doomed anyway. However, allowing it does open up more means for people to compromise the system -- there's no argument about that. If there's a few ways to compromise the system, shell access will allow a potential cracker to take advantage of those few ways they'd not have been able to exploit otherwise. There is no argument about it, really. As for "A cracker will get in if they want to bad enough anyway", is a poor assumption and *untrue*.

    If you only run secure, well configured and unexploitable services, then there is *not* just some mystical way they can get in if they "want to badly enough". This isn't the movies and computers don't smoke when people crack them either. Granted, there's still some local ways people can exploit some servers without shell access (via some script or program they can upload and run), but anyone with that poor of a system configuration is doomed anyway and you'd then be right about how it wouldn't matter, since you'd get rooted anyway if someone "wanted to badly enough".

    Really, I'm not saying that FTP, SSH, telnet, Sendmail, BIND, etc. haven't had exploitable holes that result in systems being cracked, but if you keep updated on things, and you configure the system decently, there's not going to be a way someone can root your server. With shell access, I'd almost agree that someone could eventually find some way, given all the programs and services local. However, if you use non exploitable services (Apache, ProFTPD, Qmail, etc.) that are well configured and you take other (not that it's only a little bit) measures to secure your server, then a user simply having FTP and email access is *not* going to just ultimately find a way in "if they want to badly enough".

    Sorry if this sounds sarcastic or rude, but I'm tired of hearing how it's just inevitable -- because it's not (provided you only supply a limited number of services and interfaces that you can control -- and out of all the one's you can, shell access is the most difficult to control). That's also not to say that no one should give out shell access to anyone. You just don't want to have some user get it by default. Most people don't know what to do with it, and most people don't store their passwords and login information in a secure or sensible manner. A cracker is able to obtain said login information and then logs into a *shell*.

    What I mean by this and how it differs, is; User's that are more familiar with shell will be more experienced users and more careful with said login information. Due to that, people that request shell access are going to be more careful in general, resulting in less chances of a cracker obtaining their login information of a user that *does* have shell access. You might not agree, but it's a real fact and it does make a difference -- but that's not to say that shell access in itself is the end of security or that it can't be secured. It is true though, that most anything you can implement in shell, someone can break out of.

    This same aspect is not true of things like ProFTP, Qmail, etc. For example; Qmail has never been exploited. For example; ProFTPD hasn't had any exploits that resulted in root access, but only DoS attacks (not that that's not a bad thing, but it is not an issue of being vulnerable to being exploited to gain root access). I could go on about a lot of things. Trust me on this; Indeed a secure system that's properly configured might not be easily cracked, but I'll tell you for certain that if there's any potential, that shell access is giving them 50+% more potential. Added the above mentioned and it does certainly make a difference.

    You can much more easily secure a system by allowing fewer people shell access, than you could by allowing it. That' also not to say that you shouldn't (as a web host) take every possibly measure to secure the shell environment anyway, but that it does open up far more potentials. I don't see how or why anyone would argue this fact. I just really see too many claims that "No system is ever secure" and "If someone wants in badly enough, they *are* going to get in". It's simply not true, even if it's more commonly true of some people than not.

  22. #22
    OK,

    Lets say one is going to give web hosting customers SSH access. How then does one configure
    things so the cutomers given SSH access are NOT able to see or do what they should not be able to see or do on the server?


    Thanks!

    Louis

  23. #23
    Join Date
    Apr 2002
    Location
    Hollywood, CA
    Posts
    3,046

    maybe not to my customers

    we're in the dedicated hosting forums , right ? I thought so . How would people manage there server without ssh access , unless they were near there NOC and could access it from there . Maybe i wouldnt give it to my customers by default , but ssh is a must have for many people . I just thought since we were in the dedicated forum , we were talking about dedicated hosting , were shell access is a must , unless its managed for you .

  24. #24
    Join Date
    Apr 2000
    Location
    California
    Posts
    3,051

    Re: maybe not to my customers

    Originally posted by case
    we're in the dedicated hosting forums , right ? I thought so . How would people manage there server without ssh access , unless they were near there NOC and could access it from there . Maybe i wouldnt give it to my customers by default , but ssh is a must have for many people . I just thought since we were in the dedicated forum , we were talking about dedicated hosting , were shell access is a must , unless its managed for you .
    Oh, well yeah. It would be insane to have a dedicated server and not have access to SSH and root, for goodness sakes! Okay, I'm with you there. I've actually *heard* of people renting out dedicated servers and not allowing the client to have root access, but I thought that was mostly a myth. Definitely, if that's the case, they are a joke and you'd not want to go with them, indeed!

  25. #25
    Join Date
    Mar 2002
    Location
    Chesterton, IN
    Posts
    792
    I have a Plesk box, but I am not sure that this is the same for all servers. A regular user on a linux box, from what I've noticed, only has read access to all files accept his own root directory. Can someone correct me on this if I'm wrong?

  26. #26
    Join Date
    Jun 2001
    Location
    Columbus, OH
    Posts
    35
    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 - [email protected]
    http://www.fanhome.com
    FanHome.com - Where Sports Fans Connect

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •