I am trying to setup an scp receiver that allows select users, based on ssh keys, to scp files to a specific server as a user different than themselves. This is to satisfy access restrictions by corporate figures. [8^) The ultimate setup would include a user's .ssh/config file having an entry like:
Host ssh-server
HostName=my-ssh-server
User=receiver
Their scp command would look simple like this:
scp /tmp/file.txt ssh-server:/some/dir/file.txt
I have been following a few of the questions about setting umask for scp, sftp, and ssh but I find that when creating directories, the umask is ignored and for permissions of created dirs and subdirs. However file permissions are correct.
One example of a question I have followed for the setup.
Here's what I have done:
1: Added the following to the receiver's ~/.ssh/authorized_keys:
command="/home/receiver/bin/bash_scp_run" ssh-rsa AAA ... My SSH Key
2: Wrote the script referenced above that sets umask to 027 and logs to a tmp file that it was executed. I also tested without this script and the results did not show that the umask of 027 was set. In fact it appeared that the default umask on this system was 002.
#! /bin/bash
echo "Entering ~/bin/bash_scp_run" >> /tmp/scp_log.txt
umask 027
$SSH_ORIGINAL_COMMAND
3: Ran many tests including: (Assume that all files and dirs locally have perms of 777 so the umask should be the only limiting factor.)
3.1: scp /tmp/file.txt ssh-server:/some/dir/file.txt
Result: /some/dir/file.txt has permissions of 750 just as expected.
3.2: scp -r /tmp/dir-with-subdirs ssh-server:/some/dir/top-dir
Result: /some/dir/top-dir has permissions of 777 which is not expected. Also /some/dir/top-dir/subdir has permissions of 777 which is also not expected! However files at any level have permissions of 750 which is expected.
In all cases the file /tmp/scp_log.txt showed that the umask was successfully set.
From the results in 3.2 it appears that the umask is not honored when scp creates directories but it is honored when it creates files! From my long UNIX/Linux experience, that's not how umask is supposed to work. This seems like an scp bug.