10 Oct
2014
10 Oct
'14
11:07 p.m.
On 10/10/2014 05:06 PM, Ivica Ico Bukvic wrote:
On 10/10/2014 04:01 PM, Joe Hartley wrote:
Also, the problem with this issue is that this needs to be specific to
one user, not system-wide, hence my preference of ForceCommand...
--
Ivica Ico Bukvic, D.M.A.
Associate Professor
Computer Music
ICAT Senior Fellow
DISIS, L2Ork
Virginia Tech
School of Performing Arts - 0141
Blacksburg, VA 24061
(540) 231-6139
ico(a)vt.edu
www.performingarts.vt.edu
disis.music.vt.edu
l2ork.music.vt.edu
On Fri, 10 Oct 2014 15:51:29 -0400
Ivica Ico Bukvic <ico(a)vt.edu> wrote:
Thanks for this but I thought that is what ForceCommand internal-sftp
-u 0222 does (and it does change file permissions except that even if
permissions are 000 I can still delete the file through sftp.
Subsystem is
Subsystem sftp /usr/lib/openssh/sftp-server
So, what I did so far is change
/etc/ssh/sshd_config so that sftp
chroots said user's home dir, and prevents access via ssh. I also
created a sftponly group and added the user to it. I adjusted home dir
permissions and created a subfolder "submissions" where users can
submit
their projects. Finally, I added umask to strip permissions from
uploaded files.
So, the /etc/ssh/sshd_config has the following entry
Match Group sftponly
ChrootDirectory /home/%u
ForceCommand internal-sftp -u 0222
X11Forwarding no
AllowTcpForwarding no
What's your subsystem line look like? You can force the
umask there
with
the -u directive. Example:
Subsystem sftp /usr/libexec/openssh/sftp-server -u 0002
If your sftp-server does not support -u then you can get the same effect
with this:
Subsystem sftp /bin/sh -c 'umask 0002; /usr/lib/openssh/sftp-server'