SSH vs FTP / File Manager - Security Issues [FAQs]

3 posts / 0 new
Last post
#1 Thu, 04/05/2007 - 05:05

SSH vs FTP / File Manager - Security Issues [FAQs]

SSH vs FTP - I have been going around in circles and found some answers along the way. As a note for myself and others who wonder about the security aspect of SSH...


  1. Is SSH preferred over FTP? I seemed to get the impression from Joe, from some forum posts that I've read, that SSH transfer is preferred over FTP for security reasons.


Joe: "...I'm dead set against FTP as a protocol in general, and the sooner it dies the better off we'll all be"

Joe: "I don't recommend enabling FTP if your users are capable of using alternatives."

But Jamie says otherwise:

Jamie: "options you have are...restrict users to FTP and access via Webmin's File Manager which can be locked down to specific directories. I'm sure this is what Joe meant, not the other way around :-).... Unfortunately, there isn't much you can do with SSH to lock it down further."


  1. How to prevent SSH users from seeing other SSH users' (e.g. other peoples' virtual server) directory and files?


Jamie: "If you are running the latest version of Dovecot (1.0), home directory permissions can be set to 750 by default, .. this will restrict SSH and FTP. Users will no longer be able to see each other's home dirs, but can see /tmp, /usr and other system directories."

> System] Users & Groups] Module Configuration] Permissions on new home directories] 0750

To fix your existing home dirs, you can run: chmod 750 /home/*


  1. But SSH users can see/download (although cannot delete) all other (system) files on the server!!??


That is true. And there is nothing you can do about it. If you have unencrypted passwords in any of the system directories, it can be viewed by any SSH users.

Jamie: "The Unix shell commands you run via SSH need access to /etc, /usr and other system directories to run.. so there is no way to set the permissions globally to make them unreadable."

Jamie: "Make sure all files containing security-critical information like passwords are readable only by root, or encrypted. This is actually the default on all Unix systems - /etc/shadow for example contains encrypted passwords and can only be read by root."


  1. So, how do I disable SSH access to virtual server administrators?


> Webmin] Servers] SSH Server] Access Control

Jamie: "However, even (this) is not foolproof, because if you allow users to run CGIs or PHP scripts, they can write their own scripts that will access the filesystem with the exact same permissions as if they were logged in via SSH."


  1. If SSH is not accessible to virtual server administrators, then how could I restrict them to their own home directories via FTP and File Manager?


Restrict FTP:

> Webmin] Servers] ProFTPd Server -> Files and Directories] Limit users to directories] select Home directory

Restrict File Manager:

> Webmin] Usermin Configuration] Access Control Options] Root directory for file chooser] tick User's home directory

> Webmin] Usermin Configuration] Usermin Module Configuration] File Manager] tick Allow access to home and directories below..


  1. Is there a way to further prevent unauthorised SSH login attempts?


Leif: "The rules have to be in this order..."

iptables -A RH-Firewall-1-INPUT -d -p tcp -m tcp ! --tcp-flags SYN,RST,ACK SYN -j ACCEPT

From Webmin: Action to take: Accept Destination address or network: Equals Network protocol: Equals TCP TCP flags set: Does not equal (First row) SYN TCP flags set: Does not equal (Second row) SYN ACK RST

iptables -A RH-Firewall-1-INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 22 -m recent --update --seconds 30 --name DEFAULT --rsource -j DROP

From Webmin: Action to take: Drop Incoming interface: Equals eth0 Network protocol: Equals TCP Destination TCP or UDP port: Port(s) 22 Connection states: Equals New connection(NEW) Additional IPtables modules: recent Additional parameters: --update --seconds 30 --name DEFAULT --rsource

iptables -A RH-Firewall-1-INPUT -i eth0 -p tcp -m state --state NEW -m tcp --dport 22 -m recent --set --name DEFAULT --rsource -j ACCEPT

From Webmin: Action to take: Accept Incoming interface: Equals eth0 Network protocol: Equals TCP Destination TCP or UDP port: Port(s) 22 Connection states: Equals New connection(NEW) Additional IPtables modules: recent Additional parameters: --set --name DEFAULT --rsource


  1. How do I check if my server is vulnerable?


Nessus Vulnerability Scanner

Open Port Check Tool


Can anyone tell me how to get scponly Jail for SFTP/SSH - The whole server is "open for everyone"

SSH breach - security problem!

Security - Users able to view all files on server via SSH

Possible Security issue - symlinks with owner root

SSH login attempts, maybee this is "fix" for the firewall???

How to turn off Anonymous FTP?

Post edited by: ah...lifes...good, at: 2007/09/18 21:03<br><br>Post edited by: ah...lifes...good, at: 2007/09/18 21:04

Thu, 04/05/2007 - 05:51
Joe's picture

Awe-inspiring summary. Nice job!

Seeing all of that, it's clear that I'm at odds with nearly everyone on the value of &quot;hiding&quot; things from users. I guess I trust my UNIX forefathers more than most. ;-)

I may have to add chroot ssh to the mix before we call this Early Adopter period finished, despite my grave misgivings about the security of doing so, since having things not obviously visible seems to make people happier and feel safer than having them visible (and if it's causing people to stick with FTP just to get the chroot).

A while back I read that when Chrysler was designing the PT Cruiser they did focus groups with women drivers and found that smaller windows and more cup holders made them feel safer (despite the fact that in reality both make cars more dangerous, smaller windows in particular). When the car was released, it had smaller windows and more cup holders. I won't say that chrooting SSH is like the tiny windows on the PT Cruiser...but it did bring that story to mind, and it's looking like when Virtualmin ends beta it will have a chroot ssh option. You may draw your own conclusions. ;-)

BTW-There's one thing about all of this I want to make clear. Jamie has alluded to this in a couple of the linked threads, and I've mentioned it in passing as well, but I'm going to spell it out plain-like here:

Any user that can upload a script, or edit a script, of <i>any type that can be run by Apache</i> will be able to see everything that the user can see under ssh as it is currently configured. Using FTP with chrooting does not prevent this. Using SSH with a chroot does not prevent this. Setting Usermin to only display the users home does not prevent this. Jailshell from cPanel does not prevent this. Nothing short of all out virtualization (or a FreeBSD Jail, or a vserver, or a Solaris Zone) can prevent this. Even SELinux can't prevent this to a serious degree (though it can do more than UNIX permissions).

Apache runs scripts as the user that owns them, in our default configuration (and we're moving further in this direction now that mod_fcgid+suexec is working well for PHP on most of our platforms). Any programming language can list the files in the filesystem with a few simple instructions. They can also open and read files...and display them via the browser. One could even install one of the numerous &quot;command shell&quot; type scripts out there that provide a basic interactive shell.

The good news is that it doesn't matter! Assuming permissions are sane everywhere, nothing sensitive will be revealed and nobody will be able to change things that don't belong to them.


Check out the forum guidelines!

Fri, 06/08/2007 - 08:58

This post should be stickied up there, or included in the FAQs.

I see a lot of people asking the same questions at the Customer Issues tracker.

(1) Change the default to stricter security
(2) Include in FAQs

1. Jamie has already changed the default of newer VMpro releases to restrict user access. I think he missed the FTP one:

&gt; Webmin] Servers] ProFTPd Server -&gt; Files and Directories] Limit users to directories] *select* Home directory

2. Explain why people can SSH-see root directories and how to ensure users do not mess with other users' directories and files (i.e. with directory ownership and permission; THIS IS WHY CHMOD 777 IS SUCH A BAD IDEA).

Topic locked