sftp with chroot environment issue - need help

[Ganesan R]

Hi,

I have an account with only sftp access. Also I need to configure chroot environment for this account. I ran the script /opt/ssh/utils/ssh_chroot_setup.sh

It seems the script ran fine. see below
---------------------------------
Select chroot secure shell option
----------------------------------
1 sftp
2 ssh & sftp & scp
press return key to skip this step


Option : 1

chroot setup for sftp operations

IMPORTANT NOTE:
This setup will make sure that sftp works in your chroot environment
It should not be interpreted as a restrictive sftp-only Shell.
This setup simply copies the files required for sftp to the appropriate directories under the newroot.


Now configuring the chroot environment for sftp ...finished

Summary
--------

Chroot-ed user : ganesh

Chroot-ed user's new root directory : /newroot

Secure Shell configuration : SFTP

press Return key


But still the user is able to browse root dir and other directories.

sftp> pwd
Remote working directory: /newroot/home/ganesh
sftp> cd /
sftp> ls
bin cdrom
dev etc
home
lib lost+found newroot opt sbin stand tcb ter test tmp tmp_mnt usr
var

sftp> cd /var
sftp> ls
It is listing contents of var

entry in /etc/passwd is
ganesh:*:148:20:chrooted user:/newroot/./home/ganesh:/opt/ssh/etc/sftponly

I noted that I don't see any files under /newroot/home/ganesh.

What could be the issue? how to resolve it?

[Steven E. Protter]

Shalom,

There had to be an error during setup.

The tests you show indicate chroot configuration did not happen for this user at all.

I'd run thought the setup again and record the error. If you post that it might be the key to a solution.

SEP

[Ganesan R]

Hi SEP,

I tried reconfiguring also. result is same.
But I am not seeing any error and the script shows it is finished

My requirement is here.
=======================
Create a user called "test" with only sftp access(no ssh). This user should be restricted within his home dir(/home/test). He should not browse or view beyond his home directory.

Could someone give steps/commands to do the above. Either with help of ssh_chroot_setup.sh script or without this script(means by commands)

Thanks in advance.

[Olivier Masse · Accepted solution]

You don't need to run this script anymore. And I suggest you don't run it, building jails for scp and sftp is complex and messy.

Since March 2008, OpenSSH has a internal chroot feature for the sftp server and it has been included in HP-UX Secure Shell 5.xx and up, I have 5.10. This makes chrooting SFTP dead easy.

You simply have to add this to sshd_config:
Subsystem sftp internal-sftp
ChrootDirectory /opt/anonftp

And you're done. No need to copy any libraries.

Damien posted how to do this here:
http://undeadly.org/cgi?action=article&sid=20080220110039

There's also an article about the feature here:
http://www.debian-administration.org/articles/590

I've been using this for a few months now, and it works well.

To have full logging, you can put:
Subsystem sftp internal-sftp -l VERBOSE

The only drawback with this is that you need to redirect the jailed /dev/log, I have a fix here:
http://omasse.blogspot.com/2008/09/redirecting-chroot-jailed-devlog-to.html

Don't do a ForceComand sftp yet, as the loggin will not work. There's a bugzilla entry for this, and it has been fixed. We need to wait for HP-UX Secure Shell to sync with openSSH.

Good luck

[Ganesan R]

Hi Oliver,

Will try your suggesstion and update you on the status.

[Olivier Masse]

One more thing:

To create a limited sftp user, here's a suggested passwd entry:

sftpuser:x:604:307:SFTP Users:/opt/anonftp/./sftpuser:/usr/local/bin/noshell

The home directory has an embedded /./ in case the user decides to use FTP instead (we support both here) but I don't think you need this.

I set noshell to prevent any interactive login for this user, but noshell is not included with HP-UX, you can use /bin/false to get the same result.

I also run the sftp server on a different port and prevent these users from accessing the ssh service on port 22 using DenyGroups, but that's not required. Using /bin/false is good enough for most cases.