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
  • I have a similar setup with the same general config - in mine, I have double-quotes around the username (i.e. Match User "carl"), but the documentation I can find seems to indicate this may be unnecessary. Do you have a Subsystem sftp internal-sftp line somewhere in your sshd_config? – rocketman10404 Jun 09 '14 at 14:18
  • yes, i have Subsystem sftp /usr/lib/openssh/sftp-server – Infira Jun 10 '14 at 05:28
  • In my config, I have the line you mentioned commented out, and am specifically using Subsystem sftp internal-sftp instead of the external sftp-server. Regarding the internal-sftp statement, the documentation states Alternately the name 'internal-sftp' implements an in-process 'sftp' server. This may simplify configurations using ChrootDirectory to force a different filesystem root on clients.. I'd try commenting out your Subsystem statement and trying it with Subsystem sftp internal-sftp instead. – rocketman10404 Jun 10 '14 at 15:39
  • i tried also to comment out that line and switch to Subsystem sftp internal-sftp but no help – Infira Jun 11 '14 at 15:23
  • I found some other useful notes that indicate your carl folder should be owned by root (chown root /srv/jarvis/carl). Your current permissions there look fine. It won't allow write-access for carl, so you may need to put a subfolder there owned by him to write stuff to. If you still have no luck, see if you can find anything helpful in /var/log/auth.log. – rocketman10404 Jun 11 '14 at 18:27
  • An amendment to the chroot permissions note - from the Archwiki (YMMV), it seems like you could keep your carl permissions if you change your ChrootDirectory to /srv/jarvis/%u, and modify the permissions on jarvis with chmod 755 /srv/jarvis. – rocketman10404 Jun 11 '14 at 18:54
  • still no luck auth log shows that

    21:10:18 localhost sshd[16609]: fatal: bad ownership or modes for chroot directory component "/srv/" Jun 11 21:10:18 localhost sshd[16596]: pam_unix(sshd:session): session closed for user carl

     – Infira Jun 11 '14 at 21:10

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