Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I am trying to restrict users of a file share server to their own home directories when they access it over SSH. I have several several HOWTOs and so on. I am trying to keep things simple, so I am sticking to the security which comes with OpenSSH and chroot.
I have created a test user called johndoe.
Following a HOWTO, I changed the ownership of /home/johndoe to root, but gave the permissions as 775 - so that johndoe can create folders and write as well.
So far, I could access johndoes account from another PC and read/write/edit files and directories.
But the user can browse upwards to /home, / and everywhere else, such as others home directories.
Because I also have a common shared directory, /public, I have created the group "public" so that all users in that group can access that folder as well - but that's another issue.
I then added chroot details to sshd_config:
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
Match group public
But, after restarting the server, I cannot log in as user johndoe. I get the error message:
Could not display "sftp://
Error: ssh program unexpectedly exited
Please select another viewer and try again
If I remove the Match... bit and all that follows from sshd_config, then I get access back.
So far, all problems I have had setting up this file share have had real simple, obvious fixes - i have been thinking "too deep" and trying to find complicated answers! I hope this is also the case...
You may need to change from /home/ to another directory, mounted with the proper restrictions. If there are regular users who can log into this server, you can change the home directories of the sftp users to this new directory in the /etc/passwd file. Another howto said to have the home directories like /ftp/./username/. I also don't know about the patch the howto mentions. It may depend on which version of openssh you are using.
Firstly, could you post the version of openSSL you have. I believe the chroot support by sshd is for later versions.
The howtos that mention creating some system directories, files and device nodes in the chroot directory are for chrooting ssh itself. From the manpage for sshd_config:
In the special case when only sftp is used, not ssh nor scp, it is possible to use
ChrootDirectory %h or ChrootDirectory /some/path/%u. The ﬁle system containing this
directory must be mounted with options nodev and either nosuid or noexec. The owner of the direc-
tory should be the user. The ownership of the other components of the path must fulﬁll the usual
conditions. No additional ﬁles are required to be present in the directory.
There is also a manpage for sftp-server that might be useful. More is required if you want to enable logging according to the sshd_config manpage.
I'm using OpenSSH 5.3, which should support the ChrootDirectory options.
Every HOWTO I read seems to have something different...
The owner of the directory should be the user.
All the HOWTOs I have reas say that the directory to be chrooted should be own by root.
The ownership of the other components of the path must fulﬁll the usual conditions.
Does this mean the usual perssions and such as when you installed the OS, or "usual conditions" for chrooting?
The one I have been looking at this morning also says that the user's shell be disabled with usermod -s /bin/false - when I did that, I could not login either. I set the shell back to bash and it works.
We will only be using sftp - the clients to be used are FileZilla for Windows & Linux and Nautilus for Linux.
I "just" want to restrict the users to their own home directories, and allow access to a public directory:
/home/user1 -> accessible by user1 only
/home/user2 -> accessible by user2 only
/home/usern -> accessible by usern only
/home/public -> accessible by all users
The ﬁle system containing this directory must be mounted with options nodev and either nosuid or noexec.
Note: adminuser and user1 are just covers for the real account names as real names are used.
I have replaced the group ftp with public and the directory /jail_ftp with /public.
1. Added to sshd_config:
Subsystem sftp /usr/lib/openssh/sftp-server
AllowUsers root adminuseruser1
Match Group public
# X11Forwarding no
# AllowTcpForwarding no
Restarted SSH server with restart ssh.
2. Made sure ownership of /public directory was root: chown root:root /public
chmod 750 /public
Also create additional directory /public/user1 ls -l / returns:
drwxr-x--- 5 root root 4096 2011-11-16 12:46 public
Compared to the HOWTO's example of:
drwxr-x--- root ftp 1000 Jan 1 10:10 /ftp_jail
It looks OK.
I also checked that the user user1 was in the public group: cat /etc/group returns:
But still, I cannot log in to the server.
If I remove Match and all after from sshd_config, restart the server, I can then log in.
The only reference in any logs I can find is: /var/log/auth.log
Nov 16 15:20:26 server01 sshd: pam_sm_authenticate: Called
Nov 16 15:20:26 server01 sshd: pam_sm_authenticate: username = [user1]
Nov 16 15:20:26 server01 sshd: Accepted password for user1 from 192.168.1.34 port 44190 ssh2
Nov 16 15:20:26 server01 sshd: pam_unix(sshd:session): session opened for user user1 by (uid=0)
Nov 16 15:20:26 server01 sshd: subsystem request for sftp
Nov 16 15:20:26 server01 sshd: pam_unix(sshd:session): session closed for user user1
However it does sound, from the sshd_config man page, that you need to have chroot directory on it's own partition, so you can mount with the noexec, nosuid & nodev options.
Test it with a user who can only use sftp, not one who can log in.
You can mount a directory over a mount point, and the remount the new mount point with new options:
mount --bind /home /srv/ftp
mount -o nodev,nosuid /srv/ftp
In the first command, using --rbind instead will also move filesystems mounted inside the first directory. --bind will not.
sudo mount --rbind /home /home2
sudo mount -o nodev,remount /home2
mount | grep /home
/dev/sda7 on /home type ext4 (rw,relatime,user_xattr,acl,barrier=1,data=ordered)
gvfs-fuse-daemon on /home/jschiwal/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
/dev/sda7 on /home2 type ext4 (rw,nodev,relatime,user_xattr,acl,barrier=1,data=ordered)
gvfs-fuse-daemon on /home2/jschiwal/.gvfs type fuse.gvfs-fuse-daemon (rw,nosuid,nodev,relatime,user_id=1000,group_id=1000)
If for your case /home isn't on it's own partition, that could be what you need. Satisfy the mount option requirements, even if your sftp chroot directory isn't on it's own partition.
Thanks for the help, gents. However, it has become a mute point - the company I worked has gone bust... However, I'm still sort of playing with problem at home, as I would like to find the fix. The Tech Republic link looks good.