OpenSSH SFTP chroot() with ChrootDirectory
Posted by niol on Tue 1 Apr 2008 at 10:49
The upcoming version of OpenSSH (4.8p1 for the GNU/Linux port) features a new configuration option : ChrootDirectory. This has been made possible by a new SFTP subsystem statically linked to sshd.
This makes it easy to replace a basic FTP service without the hassle of configuring encryption and/or bothering with FTP passive and active modes when operating through a NAT router. This is also simpler than packages such as rssh, scponly or other patches because it does not require setting up and maintaining (i.e. security updates) a chroot environment.
To enable it, you obviously need the new version 4.8p1. I personaly use the cvs version and the debian/ directory of the sid package to build a well integrated Debian package 4.8p1~cvs-1.
In /etc/ssh/sshd_config :
You need to configure OpenSSH to use its internal SFTP subsystem.
Subsystem sftp internal-sftp
Then, I configured chroot()ing in a match rule.
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
The directory in which to chroot() must be owned by root. After the call to chroot(), sshd changes directory to the home directory relative to the new root directory. That is why I use / as home directory.
# chown root.root /home/user # usermod -d / user # adduser user sftponly
This seems to work as expected :
$ sftp user@host Connecting to host... user@host's password: sftp> ls build cowbuildinall incoming johnbuilderclean sftp> pwd Remote working directory: / sftp> cd .. sftp> ls build cowbuildinall incoming johnbuilderclean
The only thing I miss is file transfers logging, but I did not investigate this at all. More on this whenever I find some time to do so.
References :
Note that OpenSSH 4.8 was an OpenBSD-only release shipped with the
OpenBSD 4.3 CD.
[ Parent | Reply to this comment ]
OpenSSH 4.9 is OUT!
[ Parent | Reply to this comment ]
Have I misread the manual? It struck me that ChrootDirectory subsequently applied to all users (including myself), which wouldn't work for me at all...
I can be contacted through the Web site above.
--
Minstrel
[ Parent | Reply to this comment ]
#define SSHCFG_GLOBAL 0x01 /* allowed in main section of sshd_config */
#define SSHCFG_MATCH 0x02 /* allowed inside a Match section */
#define SSHCFG_ALL (SSHCFG_GLOBAL|SSHCFG_MATCH)
/* Textual representation of the tokens. */
static struct {
const char *name;
ServerOpCodes opcode;
u_int flags;
} keywords[] = {
// [...]
{ "chrootdirectory", sChrootDirectory, SSHCFG_ALL },
// [...]
}; HTH
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
With Jailkit you can also do a similar setup as above with cvs, rsync and scp.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
and have you seen OpenSSH 5.0/5.0p1 released Apr 3, 2008?
[ Parent | Reply to this comment ]
Can't wait to try it.
Brian Pence
Celestial Software
http://www.celestialsoftware.net
AbsoluteTelnet (for telnet and ssh)
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
I don't like the sound of setting a users home directory set to "/" though. I can't think of any repercussions, but since their home directory is technically set incorrectly, I wouldn't like to say there would be none. Can anyone else think of any problems this might cause?
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
It seems to be working but I still have a question ...
It says in the manpage of sshd_config that the path given to ChrootDirectory and all of its components must be root owned directories that are not writable by any other user or group.
So when the user logs in, he doesn't have write permissions right ?
Therefore he can't upload anything ...
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
They can't upload files. How do I fix this please?
Also is it possible to modify adduser.conf to create the home directory with the appropriate ownership/properties for this? (I have modified it to set the GID as sftponly too)
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
/home/%u/Public
It is not the home directory so no hidden files there, plus it is semantically better.
[ Parent | Reply to this comment ]
Here is what happens:
user@server:/var$ sftp 192.45.2.137
Connecting to 192.45.2.137...
user@192.45.2.137's password:
Couldn't read packet: Connection reset by peer
/var/log/auth.log:
Jun 18 20:45:57 server sshd[23658]: debug1: Bind to port 22 on ::.
Jun 18 20:45:57 server sshd[23658]: Server listening on :: port 22.
Jun 18 20:45:57 server sshd[23658]: debug1: Bind to port 22 on 0.0.0.0.
Jun 18 20:45:57 server sshd[23658]: Server listening on 0.0.0.0 port 22.
Jun 18 20:46:03 server sshd[23658]: debug1: Forked child 23664.
Jun 18 20:46:03 server sshd[23664]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Jun 18 20:46:03 server sshd[23664]: debug1: inetd sockets after dupping: 3, 3
Jun 18 20:46:03 server sshd[23664]: Connection from 192.45.2.137 port 42626
Jun 18 20:46:03 server sshd[23664]: debug1: Client protocol version 2.0; client software version OpenSSH_5.1p1 Debian-3ubuntu1
Jun 18 20:46:03 server sshd[23664]: debug1: match: OpenSSH_5.1p1 Debian-3ubuntu1 pat OpenSSH*
Jun 18 20:46:03 server sshd[23664]: debug1: Enabling compatibility mode for protocol 2.0
Jun 18 20:46:03 server sshd[23664]: debug1: Local version string SSH-2.0-OpenSSH_5.1p1 Debian-3ubuntu1
Jun 18 20:46:05 server sshd[23664]: debug1: user user matched group list sftp at line 80
Jun 18 20:46:05 server sshd[23664]: debug1: PAM: initializing for "user"
Jun 18 20:46:05 server sshd[23664]: debug1: PAM: setting PAM_RHOST to "192.45.2.137"
Jun 18 20:46:05 server sshd[23664]: debug1: PAM: setting PAM_TTY to "ssh"
Jun 18 20:46:05 server sshd[23664]: Failed none for user from 192.45.2.137 port 42626 ssh2
Jun 18 20:46:06 server sshd[23664]: debug1: PAM: password authentication accepted for user
Jun 18 20:46:06 server sshd[23664]: debug1: do_pam_account: called
Jun 18 20:46:06 server sshd[23664]: Accepted password for user from 192.45.2.137 port 42626 ssh2
Jun 18 20:46:06 server sshd[23664]: debug1: monitor_child_preauth: user has been authenticated by privileged process
Jun 18 20:46:06 server sshd[23664]: debug1: PAM: establishing credentials
Jun 18 20:46:06 server sshd[23664]: pam_unix(sshd:session): session opened for user user by (uid=0)
Jun 18 20:46:06 server sshd[23671]: debug1: SELinux support disabled
Jun 18 20:46:06 server sshd[23671]: debug1: PAM: establishing credentials
Jun 18 20:46:06 server sshd[23664]: User child is on pid 23671
Jun 18 20:46:06 server sshd[23664]: debug1: PAM: cleanup
Jun 18 20:46:06 server sshd[23664]: debug1: PAM: deleting credentials
Jun 18 20:46:06 server sshd[23664]: debug1: PAM: closing session
Jun 18 20:46:06 server sshd[23664]: pam_unix(sshd:session): session closed for user user
/etc/passwd:
user:x:1003:1003:User,,,:/:/usr/sbin/nologin
/etc/group:
sftp:x:1004:user
/etc/ssh/sshd_config:
# Logging
SyslogFacility AUTH
LogLevel DEBUG
Subsystem sftp internal-sftp
Match group sftp
ForceCommand internal-sftp
ChrootDirectory /var/sshbox
user@server:/var$ ls -l
drwxr-x--- 2 root root 4096 2009-06-18 20:05 sshbox
What I am doing wrong?
[ Parent | Reply to this comment ]
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Match
^^^^^
Add this here.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
If you chown the users directory to root.root how can the user have write access to their home directory?
[ Parent | Reply to this comment ]
I'm not sure on the reason for this, but I guess it's so they can't somehow change their .profile to allow themselves access to other directories. (maybe?)
[ Parent | Reply to this comment ]
# override default of no subsystems
Subsystem sftp internal-sftp
Match Group sftpusers
ChrootDirectory /chroot
AllowTCPForwarding no
X11Forwarding no
ForceCommand internal-sftp
where /chroot is my custom directory owned by root.root and it is working fine for sftp users
and for non sftp users(i.e "ForceCommand not used")
Match Group nonsftp
ChrootDirectory /chroot
AllowTCPForwarding no
X11Forwarding no
when i look at /var/log/messages....it says
sshserver sshd [2499] : Accepted password for test from 10.0.0.54 port 2683 ssh2
which says that authentication is ok....and when i ommit "ChrootDirectory" parameter.....than everything is ok...any suggestions??
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
sudo chattr +i .htaccess
[ Parent | Reply to this comment ]
sftp/ssh works. But chrooting dont.
If I remove the user from the sftpolny group it works. So Im guessing it has something with group/sftp to do, but I cant figure it out.
Anyone got any pointers to this?
[ Parent | Reply to this comment ]
sshd -v
and keep reading the logs:
tail -f /var/log/auth.log &
[ Parent | Reply to this comment ]
"read/write" for "group" and "other" on /home/ftpuser
Removed it to only "read". Works.
But no access. Shell is missing.
[ Parent | Reply to this comment ]
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
PasswordAuthentication yes
Hope this help.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
# usermod -d / userAnd when i testing add some user, And when i delete him which
userdel -rf user.......................
[ Parent | Reply to this comment ]
I have tried this on Ubuntu 10.04 server.
But when it is configured, I get an "network error - connection refused", when I try to connect using ssh or sftp, and this is for all users, chroot'ed or not??
Has anyone tried this on Ubuntu 10.04 ?
[ Parent | Reply to this comment ]
chown root /path/to/destination
chown root /path/to
chown root /path
chmod g-w,o-w /path/to/destination
chmod g-w,o-w /path/to
chmod g-w,o-w /path
Alternatively, you can use a symbolic link to replace the real path:
chown root /path/to/destination
ln -s /path/to/destination /destination
chown root /destination
chmod g-w,o-w /path/to/destination
chmod g-w,o-w /destination
[ Parent | Reply to this comment ]
to get public-key authentication up and running for sftpusers use the users sftphome in /etc/passwd (e.g. /var/www/sftpuser_1) and let sshd chroot to %h! Password authentication will still work.
Cheers,
Olaf
[ Parent | Reply to this comment ]
http://wiki.lapipaplena.org/index.php/How_to_mount_SFTP_accesses
(with special care with owners and permissions questions)
[ Parent | Reply to this comment ]
sudo usermod -s /bin/false someuser
?
Regards, Håkan
[ Parent | Reply to this comment ]
/Håkan
[ Parent | Reply to this comment ]
However, I think there is a error in the Match syntax. I tried it, and it didn't work; until I found out, that it is crucial to close the open Match clause. So using the example from the article the right entry in sshd.conf should be:
Match group sftponly
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Match
Otherwise SFTP-server won't allow any connections!
Hope this helps!
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Debian rules!
[ Parent | Reply to this comment ]
for ChrootDirectory %h to work, the home directory of the user MUST be owned by root
for .ssh/authorized_keys to work the home directory of the user MUST be owned by the user
So how do I "jail" a user in his own directory? (using sftp only)
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
Are there any security considerations against doing the following?
chown root:root /home/user1
chmod 750 /home/user1
setfacl -m user:user1:rwx /home/user1
setfacl -m mask::rwx /home/user1This would fulfil the requirements to successfully chroot() and let users have appropriate permissions to their home directories.
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
I noticed there is already a subsystem sftp defined, so maybe that is the problem, but what is the solution? I have:
Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp
Match group guests
ChrootDirectory /home/%u
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Match
thanks everybody
[ Parent | Reply to this comment ]
BR
Andreas
[ Parent | Reply to this comment ]
Request for subsystem 'sftp' failed on channel 0
Couldn't read packet: Connection reset by peer
What is going wrong and how can I fix this?
[ Parent | Reply to this comment ]
[ Parent | Reply to this comment ]
After the call to chroot(), sshd changes directory to the home directory relative to the new root directory. That is why I use / as home directory.
If you don't change the home directory to / it seems to work anyway (ie leave as default /home/user).
It also allows public key authentication to work (~/.ssh/authorized_keys)
[ Parent | Reply to this comment ]
But I've learned not to trust anything posted on this day...
[ Parent | Reply to this comment ]