Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Secure-Shell
[Top] [All Lists]

Re: openssh v5.0p1 chroot/sftp mac os x 10.4 errors

Subject: Re: openssh v5.0p1 chroot/sftp mac os x 10.4 errors
Date: Sat, 12 Jul 2008 09:46:14 -0700

On Jul 11, 2008, at 10:46 PM, Dirk H. Schulz wrote:

Hi Luke,

--On 10. Juli 2008 17:52:12 -0700 Luke Brannon <brannon@gseis.ucla.edu> wrote:

I've been attempting to set up a chroot jail for a group of sftp users on
a Mac OS X 10.4.11 server.

First of all, how did you get OS X' ssh to chroot? Did you apply the chroot patch to the darwin source OpenSSH?

I failed to mention that I compiled openssh v5.0p1 (which I understand to have native chroot support) in /opt/openssh. It's running in daemon mode at the moment as I have not integrated it with launchd yet. (/System/Library/LaunchDaemons/ssh.plist has been unloaded with launchctl)



Unfortunately when any of the users login,
they get kicked out with the following error in my /var/log/ secure.log:


"fatal: bad ownership or modes for chroot directory component "/""

Here are my configuration settings:

/etc/sshd_config
# override default of no subsystems
Subsystem       sftp    internal-sftp

Match Group webgroup
        ChrootDirectory %h
        ForceCommand internal-sftp
        AllowTcpForwarding no

(note: I've also tried: ChrootDirectory /webhome/web)

Users are from an OpenDirectory Master. Shells are currently set to
/bin/bash (no /bin/false as some write-ups suggest to use) and their home
directories are set to /webhome/web.


Permissions and ownership on the chroot home (/webhome/web/) are:

$ ls -alG /webhome/
total 0
drwxr-xr-x +  3 root  wheel   102 Jul 10 11:10 .
drwxrwxr-t + 33 root  admin  1224 Jul 10 11:10 ..
drwxr-xr-x    6 root  wheel   204 Jul  7 11:32 web

Within web, users have access to write to different directories:

$ ls -alG /webhome/web/
total 8
drwxr-xr-x + 6 root      wheel     204 Jul  7 11:32 .
drwxr-xr-x + 3 root      wheel     102 Jul 10 11:10 ..
-rw-r--r--   1 root      admin       7 Jul  2 15:48 index.html
drwxrwxr-x   3 user1  web1grp  102 Jul  7 12:07 site1
drwxrwxr-x   3 user2  web2grp  102 Jul  7 12:18 site2
drwxrwxr-x   2 user3  web3grp   68 Jul  7 11:32 site3

(note: web1grp, web2grp, web3grp are nested into webgroup)
(note: acls are used on the site directories to deny read access to
specific groups)

Users not in the webgroup are able to login to the server with no
problems.

Are those users chrooted as well?

No.

I do not see any binaries in your chroot environment. Do you supply any?

No. Ultimately users will have only sftp access. I was under the impression I'd only need to include binaries if shell access was granted. The error message is generated when I attempt either ssh or sftp logins.


Dirk

--------------------------------------------------------------
Dirk H. Schulz
IT Systems Service
Wiesenweg 12, 85567 Grafing
Tel. 0 80 92/86 25 68
Fax. 0 80 92/86 25 72
--------------------------------------------------------------
Technik vom Feinsten - und das nötige Tuning

Regards,

Luke





<Prev in Thread] Current Thread [Next in Thread>