OpenSUSE11.2 - OpenSSH chroot only supports internal-sftp

Had my chroot jail all set up and working nicely in OpenSUSE 11.1, upgraded to OpenSUSE 11.2 and had to set:

Subsystem sftp internal-sftp
(which was:
Subsystem sftp /usr/lib64/ssh/sftp-server)

and:

ForceCommand internal-sftp

in /etc/ssh/sshd_config, before I could get sftp to work, and could not ssh to one of my chrooted users at all!

After setting debug level to debug and mount --binding /dev into my jail, when sshing to one of my chrooted users I saw the following message in /var/log/messages:

You aren’t welcomed, go away!

which when googled lead me to Re: About sftp chroot dev!, and a patch for a specific user to effectively break openssh chroot functionality.

After downloading and building the latest version of openssh:

ssh -V
OpenSSH_5.3p1, OpenSSL 0.9.8k 25 Mar 2009

(OpenSUSE 11.2 comes with:
ssh -V
OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009)

I am now able to use my chroot jail in the same way that I was under OpenSUSE 11.1.

Thought I’d share …

Note, when building OpenSSH I used:

configure --prefix=/opt --with-pam --with-privsep-path=/var/lib/empty --with-tcp-wrappers

Of which with-pam is mandatory. I used prefix to put the binaries in a place that would not conflict with the standard distribution, this meant I also needed to change /etc/init.d/sshd so that it referenced the newly compiled version of sshd, and copy /etc/ssh/sshd_config to /opt/etc/sshd_config.

I’m surprised it even worked before without internal-sftp. AFAIK, chroot requires many other conditions to be satisfied (local copy of /etc/passwd, /dev, etc) that the only workable solution is internal-sftp, which is what I used in 11.1. Before 11.1 I had to run a patched version of sftp to be able to confine sftp to a specific directory.

Not at all, I do not have a copy of /etc/passwd, though I do have a local /dev/null and /dev/zero, as well as some /bin and /lib. As I noted internal-sftp was not required under OpenSSH 5.3p1, but here’s some news, it is not required in all cases under OpenSSH 5.2p1 (I have a gentoo machine with 5.2p1 which does not have the homechroot patch). In the OpenSUSE distribution of OpenSSH 5.2p1 I could not ssh to a chrooted user even with use of internal-sftp, indeed the only thing I could use was sftp. With 5.3p1 I’m back to having things as they were under OpenSUSE and in Gentoo (ssh, scp and sftp all connecting to my chrooted users in their chrooted homes).

For clarification I mount --bind /var/run/nscd into my chroot jail, this seems to fulfill the role of /etc/passwd and others. I do have /etc/profile in my jail, but that’s the only file there.

This is the complete config of my ssh chroot filesystem:

find . -mount -ls

.
./bin
./bin/bash
./bin/cp
./bin/grep
./bin/ls
./bin/mkdir
./bin/mv
./bin/pwd
./bin/rm
./bin/rmdir
./bin/sh -> bash
./bin/vim -> vim-normal
./bin/vim-normal
./dev
./dev/null
./dev/zero
./etc
./etc/profile
./home
./lib64
./lib64/ld-2.10.1.so
./lib64/ld-linux-x86-64.so.2 -> ld-2.10.1.so
./lib64/libacl.so.1 -> libacl.so.1.1.0
./lib64/libacl.so.1.1.0
./lib64/libattr.so.1 -> libattr.so.1.1.0
./lib64/libattr.so.1.1.0
./lib64/libc-2.10.1.so
./lib64/libc.so.6 -> libc-2.10.1.so
./lib64/libcap.so.2 -> libcap.so.2.16
./lib64/libcap.so.2.16
./lib64/libcom_err.so.2 -> libcom_err.so.2.1
./lib64/libcom_err.so.2.1
./lib64/libcrypt-2.10.1.so
./lib64/libcrypt.so.1 -> libcrypt-2.10.1.so
./lib64/libdl-2.10.1.so
./lib64/libdl.so.2 -> libdl-2.10.1.so
./lib64/libkeyutils-1.2.so
./lib64/libkeyutils.so.1 -> libkeyutils-1.2.so
./lib64/libm-2.10.1.so
./lib64/libm.so.6 -> libm-2.10.1.so
./lib64/libncurses.so.5 -> libncurses.so.5.6
./lib64/libncurses.so.5.6
./lib64/libnsl-2.10.1.so
./lib64/libnsl.so.1 -> libnsl-2.10.1.so
./lib64/libpcre.so.0 -> libpcre.so.0.0.1
./lib64/libpcre.so.0.0.1
./lib64/libpthread-2.10.1.so
./lib64/libpthread.so.0 -> libpthread-2.10.1.so
./lib64/libreadline.so.6 -> libreadline.so.6.0
./lib64/libreadline.so.6.0
./lib64/libresolv-2.10.1.so
./lib64/libresolv.so.2 -> libresolv-2.10.1.so
./lib64/librt-2.10.1.so
./lib64/librt.so.1 -> librt-2.10.1.so
./lib64/libselinux.so.1
./lib64/libutil-2.10.1.so
./lib64/libutil.so.1 -> libutil-2.10.1.so
./lib64/libz.so.1 -> libz.so.1.2.3
./lib64/libz.so.1.2.3
./usr
./usr/bin
./usr/bin/dircolors
./usr/bin/grep -> /bin/grep
./usr/bin/groups
./usr/bin/id
./usr/bin/scp
./usr/bin/ssh
./usr/bin/vi -> /bin/vim
./usr/bin/vim -> /bin/vim
./usr/lib64
./usr/lib64/libcrypto.so.0.9.8
./usr/lib64/libgssapi_krb5.so.2 -> libgssapi_krb5.so.2.2
./usr/lib64/libgssapi_krb5.so.2.2
./usr/lib64/libk5crypto.so.3 -> libk5crypto.so.3.1
./usr/lib64/libk5crypto.so.3.1
./usr/lib64/libkrb5.so.3 -> libkrb5.so.3.3
./usr/lib64/libkrb5.so.3.3
./usr/lib64/libkrb5support.so.0 -> libkrb5support.so.0.1
./usr/lib64/libkrb5support.so.0.1
./usr/lib64/libltdl.so.7 -> libltdl.so.7.2.0
./usr/lib64/libltdl.so.7.2.0
./usr/lib64/libopenct.so.1 -> libopenct.so.1.0.0
./usr/lib64/libopenct.so.1.0.0
./usr/lib64/libopensc.so.2 -> libopensc.so.2.0.0
./usr/lib64/libopensc.so.2.0.0
./usr/lib64/libscconf.so.2 -> libscconf.so.2.0.0
./usr/lib64/libscconf.so.2.0.0
./usr/lib64/ssh
./usr/lib64/ssh/sftp-server
./var
./var/run
./var/run/nscd

/home and /var/run/nscd are “mount --bind” from elsewhere (neither are on the / filesystem). Of course there might be a security exploit that I’m exposing myself to by setting up a full ssh chroot jail, but I’d doubt it’s any bigger than the one created by enabling ssh in the first place.

Hmm you must have installed a newer version of sshd from somewhere other than the official repo. The current version installed on the servers in question running 11.1 is 5.1p1 (with openSUSE updates) and this config fragment works fine, no need to use the external sftp. I haven’t tried 11.2 yet.

Match User <listofsftponlyusers>
ChrootDirectory %h
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
Match

My OpenSUSE 11.2 installation is an upgrade from 11.1, during the OpenSUSE upgrade OpenSSH was updated to 5.2p1.

My issue was that using ForceCommand internal-sftp in sshd_config appears to be mandatory under this configuration and that ssh to a chrooted user failed to result in a login, instead the message “You aren’t welcomed, go away!” appeared in /var/log/messages (well, it did after “mount --bind /dev /<path to chroot>/dev” plus setting sshd log level to debug).

It’s not a question of whether internal vs external sftp works, it’s whether:

ssh <chrooted user>@<host>

results in a successful login. With the 5.2p1 (with OpenSUSE updates) version of OpenSSH supplied with OpenSUSE 11.2 it does not, with the current version of OpenSSH it does, with a standard install of OpenSSH 5.2p1 it does.

The details above demonstrate the steps required to get a successful login under OpenSUSE 11.2 with OpenSSH 5.3p1 and to show that such a thing is workable (which you appeared to doubt, “the only workable solution is internal-sftp” is simply not true).

I don’t doubt that with the appropriate files under the chroot you can get external sftp to work. However I intensely dislike that solution, which is why I called it unworkable. Perhaps I should have called it unwieldly.

However my situation differs from yours in that I require only sftp for chrooted users, not ssh. So it appears you had to do what you did. If I allowed sftp users normal ssh access, that defeats my purpose of a chroot jail for them since then can then do scp, and all sorts of other mischief. My chrooted sftp is intended as a secure alternative to ftp and I don’t want to give those users login shells.

Right, our requirements differ, the version of OpenSSH with OpenSUSE 11.2 should meet yours. Mine are met with the standard 5.2p1 release of OpenSSH but not the one bundled with OpenSUSE 11.2. I may not be the only person that requires ssh to operate within a chrooted environment, hopefully this thread will help others with similar requirements.

I’ve learnt from a lot of tutorials to use built-in OpenSSH chroot feature. Here my compendium for optimal configuration in both clients and servers:

How to mount SFTP accesses - LaPipaPlena

(special care of users and permissions)

narcisgarcia wrote:
> (http://wiki.lapipaplena.org/index.php/How_to_mount_SFTP_accesses)

never connects, firefox times out with: “Network Timeout - The server
at wiki.lapipaplena.org is taking too long to respond.”

and, from http://downforeveryoneorjustme.com/
It’s not just you! http://wiki.lapipaplena.org looks down from here.


DenverD
When it comes to chocolate, resistance is futile.
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]

[QUOTE=DenverD;2237890]narcisgarcia wrote:
> (How to mount SFTP accesses - LaPipaPlena)

never connects, firefox times out with: “Network Timeout - The server
at wiki.lapipaplena.org is taking too long to respond.”

I’ve checked your checker now and says "It’s just you. Index - LaPipaPlena is up. "

yes, it is back on line…

and, it is pretty nice (i didn’t go through it all to check accuracy,
but it sure LOOKS nice)…


DenverD
When it comes to chocolate, resistance is futile.
CAVEAT: http://is.gd/bpoMD [posted via NNTP w/openSUSE 10.3]

A domain name has changed for Lapipaplena. Please update the link for:
How to mount SFTP accesses - GiLUG