1

I have a folder /srv/jarvis which has punch of subfolder and on of them is called carl (/srv/jarvis/carl)

jarvis Dir has these rights

drwxrwxrwx 12 root root    4096 Jun  9 11:34 jarvis

And Carl has these rights

drwxr-xr-x  4 carl carl 4096 Jun  9 13:02 carl

In the /etc/ssh/sshd_config i have added these lines

Match user carl
    ChrootDirectory /srv/jarvis/carl
    ForceCommand internal-sftp
    AllowTCPForwarding no
    X11Forwarding no

But if i add those lines and do service ssh restart

then the user cant login into that server Write fails: Broken pipe. And if remove tose lines from sshd_config he can login again but i dont want that

I want that the use can access only to /srv/jarvis/carl/ and do there what ever he wants Also he cant do any of the root stuff :)

How can i fix thoes problems

Infira
  • 11

1 Answers1

0

From your auth.log notes, it appears that this is a permissions issue. Specifically the log line that says

21:10:18 localhost sshd[16609]: fatal: bad ownership or modes for chroot directory component "/srv/"

If you leave your sshd_config line reading ChrootDirectory /srv/jarvis/carl, as it is currently, then every directory in this path need to have the following characteristics:

  • It needs to be owned by the root user (group is not important)
  • It cannot be group or world writable (i.e. would need chmod 755)

Again, these apply to /srv, /srv/jarvis, and /srv/jarvis/carl. Unfortunately, the result of this is that this user carl will not be able to write into his top-level directory (after the chroot takes effect). One way around this is to prepare a subdirectory there and give him ownership of it, so he has some place to create files and folders.

I haven't tested it myself, but some discussions of this topic across the web has led me to believe that if you change your ChrootDirectory directive to read:

ChrootDirectory /srv/jarvis/%u

(which, in your case, will always mean /srv/jarvis/carl since he's the only one that would match), sshd may treat the wildcard-matching folder differently. You may be able to get away with the user carl owning the carl folder this way. Again, no guarantees. If not, the first method described should work.

rocketman10404
  • 656