Page 1 of 2 12 LastLast
Results 1 to 25 of 29
  1. #1
    Join Date
    Jun 2005
    Posts
    3,455

    Is it safe to give shell access?

    I was wondering why most hosting platforms, lets name cPanel just to name on provide the ability to give users SSH access.

    On one part it makes sense, SFTP is better, but then again, would you not consider giving SSH access to a customer on a shared server, even if its chrooted to be amazingly unsafe?

    I donīt know how easy it is to escalate privileges on Linux and even while most say that Linux permissions are safe, I know that giving SSH access to users will increase the potential of a root hack.

    Lets assume your servers is patched, how hard is it for a SSH users to gain root access on a server? Do most providers even provide SSH access to users?

    Assuming here we talk about just Linux, nothing like Cloudlinux, etc, installed, just plain SSH access to a server for users. Of course the most you give someone the most attack layers he will have but my impression over the years is that it was pretty common to provide telnet and SSH access to hosting users years back and today its more uncommon. Is Linux becoming less safer? It seems getting root access is something very possible if attacks have access to the command line, even on secure servers, this for all the hacked and compromised servers you see on the wild.

  2. #2
    Join Date
    Oct 2002
    Location
    /roof/ledge
    Posts
    28,088
    Quote Originally Posted by nibb View Post
    On one part it makes sense, SFTP is better, but then again, would you not consider giving SSH access to a customer on a shared server
    http://forums.cpanel.net/f34/creating-sftp-142921.html
    Your one stop shop for decentralization

  3. #3
    Join Date
    Sep 2008
    Location
    /dev/null
    Posts
    469
    simply its not safe even on a shell hosting server

  4. #4
    Join Date
    Jun 2005
    Posts
    3,455
    I donīt mean Secure FTP but Secure File Transfer which uses just port 22 (in case of SSH) vs FTP which needs several ports depending on the mode, passive, active, etc. I prefer SFTP and dropped FTP along time ago, simple, safe and just works. No firewall messing.

    From the post you mentioned it seems SFTP can be enabled without enabling shell access to a user, not sure how safe that is either to be honest since even with the common FTP restrictions to avoid users browsing outside of their home folder, with SFTP this may be even easier. SFTP while its not the command line still allows file manipulation.

    My concern is for enabling shell access, but you bring up another interesting question. How about only SFTP without shell, I guess its safer but shell access is still needed for more advanced users to run their own commands.

    So has the world of Linux come to a place where shell access is not an option at all on a shared servers anymore? Some users just donīt want or need a full server, even a small VPS.

  5. #5
    Join Date
    Jun 2005
    Posts
    3,455
    Quote Originally Posted by badboyx View Post
    simply its not safe even on a shell hosting server
    So you think they just take the risk? What about a fully patched server. Lets assume there is no apache, no mysql, no third party software to hack except the standard linux packages.

    From as far as I know, you would need to try to raise privileges somehow, usually exploiting a kernel race condition. So how about if kernel is patched always?

    Would not a 0 day exploit be the only possible way?

    I assume only advanced hackers will be able to pull of this. Otherwise if in Linux its so easy to get root privileges with someones account what in the world are people talking when they say Linux is safe? It would mean its a piece of garbage if any hacker kiddie can get root access with just a shell account. Even Windows permissions would be safer in this regards...

  6. #6
    Join Date
    Mar 2003
    Location
    Canada
    Posts
    9,072
    Enabling or disabling SSH access for your customers shouldn't change anything in regards to security.

    A lot of people ignorantly believe that SSH access is opening the door to being hacked. That is not true! Almost every major exploit that I can think of in recent years for Linux, could have been done via a cron job, PHP, CGI (Perl) and Python to name a few. While yes, disabling SSH access does make it a tiny bit harder for an attacker to compromise your server... even a moderately experienced script kiddie would then try to run the exploit via PHP or a CGI to get around the lack of SSH access.

    My advice, always make sure your software is always up to date and run something like CloudLinux. With CloudLinux at least, it kills most exploits dead in their tracks by removing the ability for a user to compromise SUID software -- basically, removing the most common vector for a malicious user to escalate their privileges.

    http://www.cloudlinux.com/benefits/security.php

    Nothing will ever be 100% secure, but people have to get over this "SSH = Hack" mindset. I see it all the time, I see people thinking that SSH access is the only way you can get hacked or that offering SSH access is a huge security risk. Not so, not so at all. At the end of the day, SSH access is just ONE vector an attacker can use.
    RACK911 Labs | Penetration Testing | https://www.RACK911Labs.ca

    www.HostingSecList.com - Security Notices for the Hosting Community.

  7. #7
    Join Date
    Jun 2005
    Posts
    3,455
    I just started to research that and it confirmed what I suspected already.

    That information is actually wrong, the user is having jail access wich is nothing but a shell account. You need somehow an access in the server to be able to use SFTP, so that information in the link is not entirely correct.

    Its still a shell account.

    Also just confirmed this with someone from cPanel directly.

  8. #8
    Join Date
    Mar 2003
    Location
    /root
    Posts
    23,991
    If you do not want to give SFTP then you can suggest your client to use explicit FTP over TLS and make sure you have this enabled on your server.

    It is an alternative way to use ftp securely.

    Specially 4 U
    Reseller Hosting: Boost Your Websites | Fully Managed KVM VPS: 3.20 - 5.00 Ghz, Pure Dedicated Power
    JoneSolutions.Com is on the net 24/7 providing stable and reliable web hosting solutions, server management and services since 2001
    Debian|Ubuntu|cPanel|DirectAdmin|Enhance|Webuzo|Acronis|Estela|BitNinja|Nginx

  9. #9
    Join Date
    Jun 2005
    Posts
    3,455
    Patrick call me one of those ignorants then. Some years back I thought Linux permission systems is great, its secure and safe, this conception has drastically changed for me in the past years.

    If you donīt trust a user, donīt give him access to your server, common sense. But its not that I donīt trust a user, I donīt trust what they do with their details and I donīt trust their own systems. How many actually hacked accounts where not actually the user that hacked the account? Most of them, its their accounts that get hacked, and then the server.

    Its not their server, so they donīt care. They will not take the same security measures with your logins as you do on your own servers and neither they will keep their PC safe to which they telnet to your server. Once you know it, the access is compromised, and then we are talking about anonymous people accessing that customer account to people you donīt trust.

    Would you give with closed eyes public shell access to anonymous people to your server?
    If Linux is entirely safe you should have no problems with it and I donīt think anyone in their right mind would even try, but it would make a nice honeypot at least

    Yes, I use CloudLinux and CageFS in some machines and it seems to be great, at least in papers and in their website, but how safe is it really? I donīt know. Is it safer than just a normal shell account? Probably, but even with CloudLinux I donīt know if I would trust shell accounts to users. Should I? Maybe yes, maybe not.

    I agree that nothing will be 100% safe but this is not what I want to debate here. My debate is if shell accounts and the Linux privileges systems is by nature secure and safe. If you add chrooted shell or CloudLinux or anything else on top of it, that’s great, but lets focus on the core first.

    Also, as far as I remember shell users could disable CageFS via a cPanel hack, or it was resellers? This means that the hack would have been as:
    Users logged in.
    Disable CageFS.
    Escalate privileges.

    We donīt even know how many 0 day exploits to the Linux kernel a hacker has in his possession, weapons he will not reveal.

    Maybe Im an idiot, and shell is secure by nature, and users should be able to use it in a shared server but then again a compromised servers costs to much time and money to clean up, why take the risk?

    You do have a great point. You said most root hacks where via PHP, Ruby, which means if you provide some other services already, its not like you are doing the server any less secure by enabling shell. This is the debate I want to bring in.

  10. #10
    I don't think that if you are not giving SSH access to customers, so there is any advantage in it. Because there are alot of scripts which can easily access & use for getting SSH access even if you disabled it.
    To secure your server properly just use latest versions of all softwares specially OS kernel. OS kernel have a great role in server rooting, if you are using latest one, so it is not possible to get root access by user account.

  11. #11
    Join Date
    Feb 2006
    Location
    ::1/128
    Posts
    247
    Quote Originally Posted by nibb View Post
    Patrick call me one of those ignorants then. Some years back I thought Linux permission systems is great, its secure and safe, this conception has drastically changed for me in the past years.

    If you donīt trust a user, donīt give him access to your server, common sense. But its not that I donīt trust a user, I donīt trust what they do with their details and I donīt trust their own systems. How many actually hacked accounts where not actually the user that hacked the account? Most of them, its their accounts that get hacked, and then the server.

    Its not their server, so they donīt care. They will not take the same security measures with your logins as you do on your own servers and neither they will keep their PC safe to which they telnet to your server. Once you know it, the access is compromised, and then we are talking about anonymous people accessing that customer account to people you donīt trust.

    Would you give with closed eyes public shell access to anonymous people to your server?
    If Linux is entirely safe you should have no problems with it and I donīt think anyone in their right mind would even try, but it would make a nice honeypot at least

    Yes, I use CloudLinux and CageFS in some machines and it seems to be great, at least in papers and in their website, but how safe is it really? I donīt know. Is it safer than just a normal shell account? Probably, but even with CloudLinux I donīt know if I would trust shell accounts to users. Should I? Maybe yes, maybe not.

    I agree that nothing will be 100% safe but this is not what I want to debate here. My debate is if shell accounts and the Linux privileges systems is by nature secure and safe. If you add chrooted shell or CloudLinux or anything else on top of it, that’s great, but lets focus on the core first.

    Also, as far as I remember shell users could disable CageFS via a cPanel hack, or it was resellers? This means that the hack would have been as:
    Users logged in.
    Disable CageFS.
    Escalate privileges.

    We donīt even know how many 0 day exploits to the Linux kernel a hacker has in his possession, weapons he will not reveal.

    Maybe Im an idiot, and shell is secure by nature, and users should be able to use it in a shared server but then again a compromised servers costs to much time and money to clean up, why take the risk?

    You do have a great point. You said most root hacks where via PHP, Ruby, which means if you provide some other services already, its not like you are doing the server any less secure by enabling shell. This is the debate I want to bring in.
    Define "safe". Giving ssh access it's not the way, it's just another way.
    Most evil people will not try just to root your servers, they will try to use them.
    SSH or not, someone can bring up a botnet using php.
    Can spam people with it, use it for DoS or anything else. It doesn't strictly requires shell.

    Someone can still try to bind something on a port using cron, at, or php commands like passthrou system exec shell_exec and so on. Disabling shell doesn't make it safer.

    If we are talking for panels, like cPanel or Plesk, things are a lot easier too.
    You got all the tools you need at your panel. (Setting up ruby, php scripts, you got a filemanager and so on).

    From the time someone gets access it's easy enough to do anything of the above.

    Example you disable shell, you think a user can't dig/search into server with let's say ps aux / netstat and see what you run, when, how.
    He can easily use just a shell_exec(ps aux). That's it.
    Same thing, another way of doing it.

  12. #12
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    Quote Originally Posted by nibb View Post
    If you donīt trust a user, donīt give him access to your server, common sense. But its not that I donīt trust a user, I donīt trust what they do with their details and I donīt trust their own systems. How many actually hacked accounts where not actually the user that hacked the account? Most of them, its their accounts that get hacked, and then the server.
    If you sell hosting, and provide users access to FTP you already have trusted them. It is possible to run ssh commands a dozen different ways without actually giving ssh. You can even upload a precompiled binary to a server place it in cgi-bin and run a C binary as a script.


    Would you give with closed eyes public shell access to anonymous people to your server?
    If Linux is entirely safe you should have no problems with it and I donīt think anyone in their right mind would even try, but it would make a nice honeypot at least
    Linux is not entirely safe, but the idea that not providing ssh is more secure is laughable. I investigate alot of full server compromises a year (in the 100's), and not even 1% occurred through ssh access given to a user.

    Yes, I use CloudLinux and CageFS in some machines and it seems to be great, at least in papers and in their website, but how safe is it really? I donīt know. Is it safer than just a normal shell account? Probably, but even with CloudLinux I donīt know if I would trust shell accounts to users. Should I? Maybe yes, maybe not.
    Cloudlinux without a doubt is more secure than a normal shell account.
    Cloudlinux jails everything including php/perl/etc.
    cPanel has a experimental jail going on for apache but its crap.
    cPanel does jailshell cronjobs now, but it is not perfect. There are ways to evade.

    Also, as far as I remember shell users could disable CageFS via a cPanel hack, or it was resellers? This means that the hack would have been as:
    Users logged in.
    Disable CageFS.
    Escalate privileges.
    We discovered it. It was only via resellers. It was not shell based.

    We donīt even know how many 0 day exploits to the Linux kernel a hacker has in his possession, weapons he will not reveal.
    Again what is the problem? You can run a kernel exploit without SSH access. This is how its typically done.. Without SSH access.
    I can upload a perl/php script to your server. I can use that perl/php script to setup a back connnect shell to my desktop over a open port (think port 80), and then I basically have SSH access to your server without you even giving me SSH access.

    Maybe Im an idiot, and shell is secure by nature, and users should be able to use it in a shared server but then again a compromised servers costs to much time and money to clean up, why take the risk?
    You are more likely to be compromised without ssh then with ssh.

    Another thing to mention:
    Jailshell in cpanel is not sufficient enough to protect you when compared to cloudlinux. I had a debate with cpanels security team about this and the conclusion was it helps but its not perfect. They even changed the website documentation to reflect that it helps increase security whereas before it was a definitive answer.

    Lets not forget out of the box, there is protection for symlink based attacks in the kernel level with cloudlinux.
    Last edited by Steven; 01-12-2014 at 02:54 PM.
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  13. #13
    Join Date
    Jun 2005
    Posts
    3,455
    Quote Originally Posted by chrismfz View Post
    Define "safe". Giving ssh access it's not the way, it's just another way.
    Most evil people will not try just to root your servers, they will try to use them.
    SSH or not, someone can bring up a botnet using php.
    Can spam people with it, use it for DoS or anything else. It doesn't strictly requires shell.

    Someone can still try to bind something on a port using cron, at, or php commands like passthrou system exec shell_exec and so on. Disabling shell doesn't make it safer.

    If we are talking for panels, like cPanel or Plesk, things are a lot easier too.
    You got all the tools you need at your panel. (Setting up ruby, php scripts, you got a filemanager and so on).

    From the time someone gets access it's easy enough to do anything of the above.

    Example you disable shell, you think a user can't dig/search into server with let's say ps aux / netstat and see what you run, when, how.
    He can easily use just a shell_exec(ps aux). That's it.
    Same thing, another way of doing it.
    Its not the same impact of damage at all. A PHP sending spam, delete it, a compromised account, reset the account or delete the users home directory.

    A root compromise, you better do a full OS install and clean up since you cannot guarantee safety anymore. The impact of the damage can be mitigated without root access.

    Controlling one hosting account is not similar to someone having control over the whole server and SSH allows to enter commands. This is the only difference, you keep mentioning PHP and that users can also execute commands and control the server with it. Not quite right, you need to enable shell_exec needs and other features. You may get some information and input some commands with PHP but only what you actually allow with PHP.

    With SSH you can input any command that the OS accepts. Its a direct connection to the OS and gives more freedom.

    I donīt debate what you say because its true, but this does not explain why most hosts then disallow SSH directly. No server is secure, but you try to make it harder to exploit, just like you have a door at your home. Does it prevent someone from getting in? Probably not if they really want to get in, but still you close the door when you leave home.

    I assume that letting users input commands and control the OS with SSH is probably more risky. My point is how easy it is to hack a Linux OS without even relying on external software, lets not assume there the attacker takes a PHP vulnerability, or Apache, etc, but just has SSH access and uses this to take over the server.

  14. #14
    Join Date
    Jun 2005
    Posts
    3,455
    Quote Originally Posted by Steven View Post
    If you sell hosting, and provide users access to FTP you already have trusted them. It is possible to run ssh commands a dozen different ways without actually giving ssh. You can even upload a precompiled binary to a server place it in cgi-bin and run a C binary as a script.




    Linux is not entirely safe, but the idea that not providing ssh is more secure is laughable. I investigate alot of full server compromises a year (in the 100's), and not even 1% occurred through ssh access given to a user.



    Cloudlinux without a doubt is more secure than a normal shell account.
    Cloudlinux jails everything including php/perl/etc.
    cPanel has a experimental jail going on for apache but its crap.
    cPanel does jailshell cronjobs now, but it is not perfect. There are ways to evade.



    We discovered it. It was only via resellers. It was not shell based.



    Again what is the problem? You can run a kernel exploit without SSH access. This is how its typically done.. Without SSH access.
    I can upload a perl/php script to your server. I can use that perl/php script to setup a back connnect shell to my desktop over a open port (think port 80), and then I basically have SSH access to your server without you even giving me SSH access.



    You are more likely to be compromised without ssh then with ssh.

    Another thing to mention:
    Jailshell in cpanel is not sufficient enough to protect you when compared to cloudlinux. I had a debate with cpanels security team about this and the conclusion was it helps but its not perfect. They even changed the website documentation to reflect that it helps increase security whereas before it was a definitive answer.

    Lets not forget out of the box, there is protection for symlink based attacks in the kernel level with cloudlinux.
    Yes, you can attack a server without SSH, but I donīt think you have the same freedom of options, you are limited to what ever language you use in case of PHP, Ruby, etc, and this if we are not assuming you mean by attacking a vulnerability in that language which is not what I try to debate since that is exploiting PHP or Ruby, etc. My concern is an exploit to the OS and get root access directly from SSH attacking a default Linux package.

    About the cPanel jailed ssh, not sure when they told you this because I always knew that the jailed ssh from cPanel helps but does not give any guarantee and its based on the typical jail chrooted ssh which just avoids some commands and users browsing the root path. Its just for normal users so they donīt see others users data and do not run some command by accident that can hurt the server, I donīt think it was advertised as a security feature.

    Otherwise I would have enabled shell access with this option on for a cPanel server (this exists without cPanel servers as well) and I never did, most providers in the hosting industry which also use cPanel never did, because they know it helps, but its not secure and any newbie hacker will be able to by pass it.

    The CloudLinux jail, of course seems more secure as Cloudlinux implements its own kernel and this seems to be the reason why most of its patches cannot be undone easily since they are working on the upper level of the OS.

    CloudLinux does not measure everything under its LVE, this is a misconception and I have debated this allot of times and even Igor confirmed this on several times. Most people assume everything runs under CloudLinux and this is not correct. Apache and HTML pages actually donīt, and allot of languages donīt either, its just PHP and the CGI-BIN as far as I know, email, Ruby, Tomcat, FTP, all other services which are not explicit supported by CloudLinux runs as normal, without isolation. Its not isolated and resources are not taking into account this means any email server like Exim, Postfix, IMAP, POP, or SMTP protocols or any script in the server for allot of programming languages run just as they do on a normal server and CL has no effect on them. I donīt even think bash script does unless you start them in a CageFS session.

    Maybe im wrong but if you enable their jail I assume as well that for the same reason not actually everything runs jailed either. If this is not true then its actually pretty safe, if im correct, then its not jailing everything under a specific user account. I did tested SSH under a CafeFS and it seems to be quite better than anything I saw before, but is it bullet proof? If yes, then this product would solve allot of problems for allot of server administrators. While I have some servers running CloudLinux its more geared toward the hosting industry and this shows how they gave priority to PHP and MySQL. Not sure how safe and secure it would be for other type of industries and environments.

    Iīm not against providing SSH and Shell access. Quite the contrary, I was just questioning why years back it was pretty standard to give shell access to hosting users, it was actually included normally with even the cheapest packages and this disappeared in the last few years. So I came under the impression the only reason is security. Could maybe something like CloudLinux change this and bring SSH back to shared hosting users? I hope so.

  15. #15
    Join Date
    Mar 2003
    Location
    California USA
    Posts
    13,681
    It seems like you have it all figured out so I am not even sure why you are asking for opinions, because its obvious you don't care about what people have to say.

    Just keep living in your false world that not allowing ssh is keeping you secure. There is absolutely nothing that can be done in ssh that cannot be done in perl.

    Iīm not against providing SSH and Shell access. Quite the contrary, I was just questioning why years back it was pretty standard to give shell access to hosting users, it was actually included normally with even the cheapest packages and this disappeared in the last few years. So I came under the impression the only reason is security.
    Because people have this false idea it is more secure not to. It never was more secure not to on a shared server. The only thing it does is make it easier to run commands, which doesn't even matter since you can just open a back connect shell.
    Last edited by Steven; 01-13-2014 at 12:11 PM.
    Steven Ciaburri | Industry's Best Server Management - Rack911.com
    Software Auditing - 400+ Vulnerabilities Found - Quote @ https://www.RACK911Labs.com
    Fully Managed Dedicated Servers (Las Vegas, New York City, & Amsterdam) (AS62710)
    FreeBSD & Linux Server Management, Security Auditing, Server Optimization, PCI Compliance

  16. #16
    Join Date
    Jun 2005
    Posts
    3,455
    Not at all, this is why I posted this here to hear other users opinions on the subject.

    Just because I try to counter some opinions does not mean I decided to incline that way, I could argue the same about your opinion, where you clearly do not see any disadvantages on providing SSH at all, which would be biased as there is not such thing as completely safe or completely unsafe.

    This is why I asked it here, to hear both the cons and pros, if someone things something has only crons or pros, then he is completely biased. There must be positives and negatives to make a balanced decision.

    The reason of this post if to try to figure out if providing SSH actually has more pros than cons.

    I appreciate your opinion and it did inclined me more in favor of providing SSH which is actually what I wanted, to be convinced that its not unsafe as all these years told me so. But sometimes its good to hear others opinion, maybe someone jumps in and puts some information that makes me completely disfavor SSH again and confirms what I and most users thing.

    Its not easy to change the opinion on someone if they believed something for years and it seems im not alone here since the norm is not provide SSH.

  17. #17
    Join Date
    Jan 2011
    Location
    Canada
    Posts
    938
    I always figured not providing SSH on shared hosters was more a customer service policy than security. IIRC, asking for shell always ended up with an agreement appendum that further narrowed down any support the host may provide, considering that I could now muck up my small part of the world beyond any standard a level 1 tech could navigate.

  18. #18
    Join Date
    Jun 2005
    Posts
    3,455
    Quote Originally Posted by tchen View Post
    I always figured not providing SSH on shared hosters was more a customer service policy than security. IIRC, asking for shell always ended up with an agreement appendum that further narrowed down any support the host may provide, considering that I could now muck up my small part of the world beyond any standard a level 1 tech could navigate.
    Not really, IRC is not allowed because users asking for it tend to use it for malicious activity, botnets or controllers. Not really because they donīt want to provide support. Allot of networks forbid those type of services because usually they are in a huge % related to network abuses since they are a very attractive target for dos attacks. I assume people asking for shell usually want to install something like that, that could explain why most hosts are not willing to provide shell access either.

    Iīm not a fan of denying services, its the easy road. The correct way for a hosting provider or network is to do their jobs and have network admins and abuse teams in place to handle this issues instead of just denying someone access to a specific protocol or service.

  19. #19
    Unfortunantly I don't think it is safe to gie it out.

  20. #20
    Join Date
    Jan 2011
    Location
    Canada
    Posts
    938
    Quote Originally Posted by nibb View Post
    Not really, IRC is not allowed...
    IIRC == If I Recall Correctly.

  21. #21
    Join Date
    Mar 2005
    Location
    Ten1/0/2
    Posts
    2,529
    Quote Originally Posted by Steven View Post
    Just keep living in your false world that not allowing ssh is keeping you secure. There is absolutely nothing that can be done in ssh that cannot be done in perl.
    .. or compiled CGI binary, or......

    Totally agree with this. Shared access IS access and there are a lot of ways it can be manipulated.
    CPanel Shared and Reseller Hosting, OpenVZ VPS Hosting. West Coast (LA) Servers and Nodes
    Running Linux since 1.0.8 Kernel!
    Providing Internet Services since 1995 and Hosting Since 2004

  22. #22
    I don't see a reason to open another possible attack vector by default. If a customer asks for shell access, sure, here you go, of course it's available to be turned on for you. Even have it be a setting the user can easily find and change if possible. SSH brute force attacks are common, and while they rarely succeed, why risk it? Users don't always have secure passwords, and even if you require secure passwords there are passwords that will meet all criteria and still be insecure.

  23. #23
    Join Date
    Nov 2000
    Location
    localhost
    Posts
    3,771
    Deployment? Is that FTP right?
    If you're attempting to attract any non-novice developer then you'll struggle [or be laughed at] with just [s]FTP, by disallowing shell access you restrict any possible deployments (automated or otherwise) using rsync, git, or other ssh-based vcs.

    On another note the traditional FTP protocol sucks, as well being insecure, port information is embedded in the protocol in addition to the TCP headers causing all sorts of issues behind corporate NATs etc..
    MattF - Since the start..

  24. #24
    Join Date
    Oct 2010
    Posts
    5,079
    Quote Originally Posted by nibb View Post
    Yes, you can attack a server without SSH, but I donīt think you have the same freedom of options, you are limited to what ever language you use in case of PHP, Ruby, etc, and this if we are not assuming you mean by attacking a vulnerability in that language which is not what I try to debate since that is exploiting PHP or Ruby, etc. My concern is an exploit to the OS and get root access directly from SSH attacking a default Linux package.
    But I take it you'd never give out cron access then?

    All they'd have to do is put a file there with their intended bash commands in, and run /bin/bash {path_to_file}.sh from cron.
    Not as active on WHT as I used to be, but still drop in and receive email notifications from here.
    My personal blog site: https://www.oakleys.org.uk/blog

  25. #25
    Join Date
    May 2006
    Location
    EU & USA
    Posts
    3,684
    We don't give ssh access standard to everyone, why ? because clients are curious and half of the time do not know what they are doing. And usually they do not need it at all. Those who do; most of the time know how to work in a shell and can go around in it.

    Just look online at what kind of answers you sometimes get from people thinking to be funny... oh just log into your shell and type 'rm ...... ' and then the support department gets the issues on their plate. So no i am not a big fan to give all clients ssh access to access a shell. And in a way that has to do with security; not because it would be more secure for malicious hackers but more secure by protecting your client for itself.
    ŧ cPanel Servers in Europe: Strasbourg (FR), Haarlem & Amsterdam (NL) & Kent (UK), USA (Los Angeles, St.Louis), Asia (Singapore) | Follow us at Twitter: @040hosting
    ŧ
    Shared | Reseller | (managed) Dedicated Hosting | Domain Registrar | SSL Registrar | Cloudlinux Partner| 040Hosting (Registered company #17093425 KVK Eindhoven, The Netherlands)

Page 1 of 2 12 LastLast

Similar Threads

  1. Give access to OpenVPN account without giving access to SSH?
    By CuriosityHosting in forum Hosting Security and Technology
    Replies: 6
    Last Post: 09-04-2012, 08:35 PM
  2. Replies: 6
    Last Post: 02-25-2011, 08:28 PM
  3. Jailed Shell Safe?
    By M Bacon in forum Hosting Security and Technology
    Replies: 29
    Last Post: 08-22-2009, 06:05 PM
  4. Replies: 0
    Last Post: 04-22-2008, 07:41 PM
  5. Restrict Root Access and Give user access in PureFTP
    By stooley in forum Hosting Security and Technology
    Replies: 1
    Last Post: 03-03-2006, 03:19 AM

Posting Permissions

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