1

I have a weird issue when trying to upload files to a server using SFTP.

When for maximum security I use a user with a disabled shell ("/bin/false") to upload files, I get mode 640 for the uploaded files and this is not what I want (local files have mode 664).

However when I enable the shell "/bin/bash" for the same user I get the correct mode, 664.

I am not sure to understand what is happening here, why does disabling shell change the mode of the uploaded files?

My sshd configuration:

Port 22
Protocol 2
AcceptEnv LANG LC_*
UsePAM yes
UseDNS no
Subsystem sftp internal-sftp
  • I suspect a valid shell is required for the client to execute "chmod" after uploading. Can't this be a solution? serverfault.com/q/283492/56333 – HUB Mar 13 '18 at 11:34
  • You should check what happens in the rc files of your system... ~/.bashrc , ~/.bash_profile, /etc/profile, /etc/profile.d – Itai Ganot Mar 13 '18 at 11:55
  • is using rsync -a an option? On older systems, you have to tell rsync to use ssh, rsync -a -e ssh – Adam Katz Mar 19 '18 at 16:20
  • You said you tried the solution provided by @ivanivan, can you provide your sshd_config with his fix applied? – Broco Mar 20 '18 at 12:33
  • Try to set the setuid bit on your folder to which you upload you files. gnu.org/software/coreutils/manual/html_node/… – Anton Makovetsky Mar 22 '18 at 15:27
2
+25

By not having a valid shell, the system default umask isn't being applied/used.

What you can do is put your users in a group, and force a few things via the /etc/sshd_config file, including a umask -

Match Group uploadusers
  ForceCommand internal-sftp -u 0002

the -u 0002 option sets a umask for the internal-sftp program/subsystem and any files uploaded through it IF the user is a member of the uploadusers group.

Personally I also chroot the users so that they can only access their directories - check the ChrootDirectory option as it applies to a Match Group directive in the sshd_config file.

  • I have tired this but it did not work – obo Mar 20 '18 at 10:38
0

The reason behind this is because when a shell is getting involved, a UMASK is being applied. In your case, it's likely (for bash), being applied inside of /etc/bashrc (this is assuming some modern Red Hat/Centos 7 version), location of these files might vary. When using nothing, check the UMASK setting in /etc/profile maybe.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.