Building a Chrooted sftp Environment on Linux
时间：2005-05-18 来源：patguo
There was a time, not so very long ago, when we used to enjoy running an ftp server and locking our users into tiny little chrooted jails. While we still enjoy denying users their freedom, we now prefer to do so using a maximum security facility. The sftp file transfer program, which comes with OpenSSH server, gives users an interactive interface like ftp but performs transfers over an encrypted ssh transport. In this day and age, it is not unreasonable to expect users to start using an ssh client, even if they are running Windows. If they don't have one already, tell them to download Putty. There are also nice commercial clients, and if users are technically adept and so inclined, they can use openssh over cygwin
Now build the chroooted OpenSSH.
Before you make install, you may want to make a copy of your current ssh binaries, if they are installed in /usr/local/bin and /usr/local/sbin, which is where openssh will put them by default. The install will not overwrite your config files or host keys, though if you're paranoid like us you'll back them up anyway.
This goes swimmingly on my Red Hat 7.3 workstation. Now, you'll need to kill the old sshd and start the new one. In my case, I have been running sshd from a different location, /usr/sbin/sshd which is where Red Hat installs it. In order to keep the rc script working, either change the path to sshd in your sshd rc script, (/etc/rc.d/init.d/sshd or something like that) or create a link like so:
Make sure you can ssh to your machine from another box. If sshd is working, we can proceed to my favorite part, setting up the chrooted jail.
Building a Jail
The chrooted environment must contain everything a user needs to copy files back and forth using sftp. This includes utilities used by sftp, libraries, a home directory, and even some device files. This will keep the user safely off the rest of the system. Before you get too excited, keep in mind that chrooted jails can be broken. But not easily. Referring to the document at chrootssh.sourceforge.net, we'll build our jail. We're going to call ours alcatraz.
Copying the necessary binaries:
Determining which libraries are needed and copying them into place:
And so on. We also need sftp itself.
Now sftp should work. We just need a couple of device files, /dev/null and /dev/zero:
Let's see if the chroot works.
It works! But as you can see, functionality is limited. If we had an /etc/passwd file, for instance, we'd have a normal root prompt instead of the identity crisis listed above.
Setting up Users, Refining.
Let's add a user whose home directory is chrooted and test the chroot functionality of ssh.
Yep, we are definitely in our jail. But lets see what we can do in this jail:
Looks pretty good! The last thing we have to do is lock down little fifi's shell so she can use only sftp. We are not allowing interactive logins, chrooted or no. The easiest way to do this is to use sftp-server as the shell. It's a little ugly, but it works.
The ugly part is that the session just hangs until interrupted when interactive login is attempted. You can always write a wrapper, but remember it must work within your chroot environment. Finally, let's tighten up our jail a little bit more. Let's take away fifi's write permissions on her own home directory! Why, you ask? I'll show you.
This is fine, if you want to allow the user to write keys and circumvent the need for a valid password. But if you want to control access via passwords, lock down the home directory and give them write permissions on a directory below it.
That will keep fifi from playing her naughty tricks. I'm looking forward to imprisoning many users with this system. True, there's no proof they've done anything wrong, but I'm sure they're just waiting for the opportunity!
Building a Chrooted sftp Environment - Printable View
There was a time, not so very long ago, when we used to enjoy running an ftp server and locking our users into tiny little chrooted jails. While we still enjoy denying users their freedom, we now prefer to do so using a maximum security facility. The sftp file transfer program, which comes with OpenSSH server, gives users an interactive interface like ftp but performs transfers over an encrypted ssh transport. In this day and age, it is not unreasonable to expect users to start using an ssh client, even if they are running Windows. If they don't have one already, tell them to download Putty. There are also nice commercial clients, and if users are technically adept and so inclined, they can use openssh over cygwin.
Building a chrooted ssh
By design, OpenSSH does not include the capacity to be chrooted, as the developers contend such functionality belongs in the OS. Luckily, a third party patch has been developed. The patch, a pre-patched openssh tarball, and a good document about setting up the chrooted sftp are available at http://chrootssh.sourceforge.net/.
Download the tarball for openssh, and the chrootssh patch. Untar the openssh sources, then apply the patch.
[urbana@bubbles ssh]$ tar xzf openssh-3.6.1p2.tar.gz [urbana@bubbles ssh]$ cd openssh-3.6.1p2 [urbana@bubbles openssh-3.6.1p2]$ patch -p1 < ../osshChroot-3.6.1.diff patching file session.c |
Now build the chroooted OpenSSH.
[urbana@bubbles openssh-3.6.1p2]$ ./configure --with-md5-password [urbana@bubbles openssh-3.6.1p2]$ make |
Before you make install, you may want to make a copy of your current ssh binaries, if they are installed in /usr/local/bin and /usr/local/sbin, which is where openssh will put them by default. The install will not overwrite your config files or host keys, though if you're paranoid like us you'll back them up anyway.
[root@bubbles openssh-3.6.1p2]# make install |
This goes swimmingly on my Red Hat 7.3 workstation. Now, you'll need to kill the old sshd and start the new one. In my case, I have been running sshd from a different location, /usr/sbin/sshd which is where Red Hat installs it. In order to keep the rc script working, either change the path to sshd in your sshd rc script, (/etc/rc.d/init.d/sshd or something like that) or create a link like so:
[root@bubbles openssh-3.6.1p2]# mv /usr/sbin/sshd /usr/sbin/sshd.old [root@bubbles openssh-3.6.1p2]# ln -s /usr/local/sbin/sshd /usr/sbin/sshd [root@bubbles ssh]# service sshd stop Stopping sshd: [ OK ] [root@bubbles ssh]# service sshd start Starting sshd: [ OK ] |
Make sure you can ssh to your machine from another box. If sshd is working, we can proceed to my favorite part, setting up the chrooted jail.
Building a Jail
The chrooted environment must contain everything a user needs to copy files back and forth using sftp. This includes utilities used by sftp, libraries, a home directory, and even some device files. This will keep the user safely off the rest of the system. Before you get too excited, keep in mind that chrooted jails can be broken. But not easily. Referring to the document at chrootssh.sourceforge.net, we'll build our jail. We're going to call ours alcatraz.
[root@bubbles u01]# mkdir alcatraz [root@bubbles alcatraz]# mkdir bin dev home lib usr [root@bubbles alcatraz]# cd bin |
Copying the necessary binaries:
[root@bubbles bin]# cp /bin/bash /bin/cp /bin/ls /bin/mkdir /bin/mv /bin/rm /bin/rmdir . [root@bubbles bin]# ln -s bash sh |
Determining which libraries are needed and copying them into place:
[root@bubbles bin]# cd ../lib [root@bubbles lib]# ldd ../bin/bash libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002b000) libdl.so.2 => /lib/libdl.so.2 (0x40030000) libc.so.6 => /lib/libc.so.6 (0x40033000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [root@bubbles lib]# cp /lib/libtermcap.so.2 . [root@bubbles lib]# cp /lib/libdl.so.2 . [root@bubbles lib]# cp /lib/libc.so.6 . [root@bubbles lib]# cp /lib/ld-linux.so.2 . [root@bubbles lib]# ldd ../bin/cp libc.so.6 => /lib/libc.so.6 (0x4002b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [root@bubbles lib]# ldd ../bin/ls libtermcap.so.2 => /lib/libtermcap.so.2 (0x4002b000) libc.so.6 => /lib/libc.so.6 (0x40030000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) |
And so on. We also need sftp itself.
[root@bubbles alcatraz]# cd usr [root@bubbles usr]# mkdir lib [root@bubbles usr]# mkdir -p local/libexec [root@bubbles usr]# cp /usr/local/libexec/sftp-server local/libexec/ [root@bubbles usr]# ldd local/libexec/sftp-server libutil.so.1 => /lib/libutil.so.1 (0x4002b000) libz.so.1 => /usr/lib/libz.so.1 (0x4002f000) libnsl.so.1 => /lib/libnsl.so.1 (0x4003d000) libcrypto.so.2 => /lib/libcrypto.so.2 (0x40051000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40117000) libc.so.6 => /lib/libc.so.6 (0x40144000) libdl.so.2 => /lib/libdl.so.2 (0x4026b000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) [root@bubbles usr]# cp /lib/libutil.so.1 ../lib/ [root@bubbles usr]# cp /usr/lib/libz.so.1 lib/ [root@bubbles usr]# cp /lib/libnsl.so.1 ../lib/ [root@bubbles usr]# cp /lib/libcrypto.so.2 ../lib/ [root@bubbles usr]# cp /lib/libcrypt.so.1 ../lib/ [root@bubbles usr]# cp /lib/libc.so.6 ../lib/ cp: overwrite `../lib/libc.so.6'? n [root@bubbles usr]# cp /lib/libdl.so.2 ../lib/ cp: overwrite `../lib/libdl.so.2'? n |
Now sftp should work. We just need a couple of device files, /dev/null and /dev/zero:
[root@bubbles usr]# cd ../dev [root@bubbles dev]# ls -l /dev/null /dev/zero crw-rw-rw- 1 root root 1, 3 Apr 11 2002 /dev/null crw-rw-rw- 1 root root 1, 5 Apr 11 2002 /dev/zero [root@bubbles dev]# mknod null c 1 3 [root@bubbles dev]# mknod zero c 1 5 [root@bubbles dev]# ls -l total 0 crw-r--r-- 1 root root 1, 3 Jul 28 15:15 null crw-r--r-- 1 root root 1, 5 Jul 28 15:15 zero |
Let's see if the chroot works.
[root@bubbles root]# chroot /u01/alcatraz /bin/sh [I have no name!@bubbles /]# pwd / [I have no name!@bubbles /]# ls bin dev home lib usr |
It works! But as you can see, functionality is limited. If we had an /etc/passwd file, for instance, we'd have a normal root prompt instead of the identity crisis listed above.
Setting up Users, Refining.
Let's add a user whose home directory is chrooted and test the chroot functionality of ssh.
[root@bubbles bin]# useradd -d /u01/alcatraz/./home/fifi fifi [root@bubbles bin]# passwd fifi Changing password for user fifi. New password: Retype new password: passwd: all authentication tokens updated successfully. [root@bubbles bin]# ssh pike root@pike's password: Last login: Mon Jul 28 13:44:49 2003 from bubbles.upthe.com [root@pike root]# ssh fifi@bubbles fifi@bubbles's password: bash-2.05a$ pwd /home/fifi bash-2.05a$ cd ../.. bash-2.05a$ ls bin dev home lib usr |
Yep, we are definitely in our jail. But lets see what we can do in this jail:
bash-2.05a$ mkdir z mkdir: cannot create directory `z': Permission denied bash-2.05a$ cd bash-2.05a$ pwd /home/fifi bash-2.05a$ mkdir z bash-2.05a$ ls -l total 4 drwxr-xr-x 2 548 548 4096 Jul 28 22:39 z bash-2.05a$ cd .. bash-2.05a$ rmdir fifi rmdir: `fifi': Permission denied |
Looks pretty good! The last thing we have to do is lock down little fifi's shell so she can use only sftp. We are not allowing interactive logins, chrooted or no. The easiest way to do this is to use sftp-server as the shell. It's a little ugly, but it works.
[root@pike root]# ssh fifi@bubbles fifi@bubbles's password: Last login: Mon Jul 28 15:36:54 2003 from pike.upthe.com Connection to bubbles closed. [root@pike root]# sftp fifi@bubbles Connecting to bubbles... fifi@bubbles's password: sftp> pwd Remote working directory: /home/fifi sftp> put /etc/group Uploading /etc/group to /home/fifi/group |
The ugly part is that the session just hangs until interrupted when interactive login is attempted. You can always write a wrapper, but remember it must work within your chroot environment. Finally, let's tighten up our jail a little bit more. Let's take away fifi's write permissions on her own home directory! Why, you ask? I'll show you.
[urbana@pike .ssh]$ sftp fifi@bubbles Connecting to bubbles... fifi@bubbles's password: sftp> mkdir .ssh sftp> lcd .ssh sftp> cd .ssh sftp> put id_dsa.pub authorized_keys Uploading id_dsa.pub to /home/fifi/.ssh/authorized_keys sftp> exit [urbana@pike .ssh]$ sftp fifi@bubbles Connecting to bubbles... sftp> |
This is fine, if you want to allow the user to write keys and circumvent the need for a valid password. But if you want to control access via passwords, lock down the home directory and give them write permissions on a directory below it.
[root@bubbles fifi]# mkdir files [root@bubbles fifi]# chown fifi:fifi files [root@bubbles fifi]# chmod 700 files [root@bubbles fifi]# ls -l total 12 drwx------ 2 fifi fifi 4096 Jul 28 16:35 files [root@bubbles fifi]# cd .. [root@bubbles home]# chown root:root fifi [root@bubbles home]# ls -l total 4 drwx------ 3 root root 4096 Jul 28 16:35 fifi |
That will keep fifi from playing her naughty tricks. I'm looking forward to imprisoning many users with this system. True, there's no proof they've done anything wrong, but I'm sure they're just waiting for the opportunity!
相关阅读 更多 +
