Ssh – SFTP permission denied but SSH works fine

permissionssftpssh

I keep getting Permission denied errors while attempting to upload changes to a file via SFTP, however it works fine when using SSH directly as the same user.

The file I am trying to upload is /srv/www/website/current/app/AppKernel.php (however the error currently applies to any file in my project, we'll stick with the one file to keep things simple).

My first port of call, was to SSH into the server AS THE SAME USER and confirm the permissions are working.

After SSHing in, I check who I am

$ whoami
cp5w

An ls -l reveals the following permissions (snipped to the relevant line)

$ ls -l
-rwxrwxr-x 1 deploy nginx   1523 Nov 11 12:51 AppKernel.php

You can see here the owner of the file is deploy and the group is nginx. I can confirm the user cp5w is in the group nginx:

$ groups
opsworks nginx

So in theory I should be able to write to AppKernel.php yes? Let's try that:

$ tail -n 3 AppKernel.php
        $loader->load($this->getRootDir().'/config/config_'.$this->getEnvironment().'.yml');
    }
}

$ echo "# add line to end of file" >> AppKernel.php
$ tail -n 3 AppKernel.php
    }
}
# add line to end of file

Yep that works fine. No errors. I'm not going mad.

Some possible solutions suggest checking there is group-executable on the parent directory which I've double checked as follows (again snipped to the relevant line):

$ ls -l ..
drwxrwxr-x  6 deploy nginx  4096 Nov 11 15:31 app

I've also checked for issues with system-owned directories however, I'm already working on a child directory website which also shares the same permission pattern as the rest of the project:

  • owned by deploy
  • group is nginx
  • group can read, write and traverse directories

Now I'll try uploading (aka modify) the file using SFTP from my workstation. Same user. Same SSH key. Same workstation. Same server. Targeting the same file. Just SFTP now, not SSH.

psftp> open myserver
login as: cp5w
psftp> cd /srv/www/website/current/app
Remote directory is now /srv/www/website/releases/20151111145342/app
psftp> lcd C:\Users\chris\Source\website\app
New local directory is C:\Users\chris\Source\website\app
psftp> put AppKernel.php
/srv/www/website/releases/20151111145342/app/AppKernel.php: open for write: permission denied

What gives?!!

Some more food for thought:

  • This used to work via SFTP a few days ago and I haven't made any server configuration changes recently that I can recall
  • Is the issue because I'm trying to write via a symlink?
  • The only thing I've changed recently is my workstation which is now Windows not Linux. Is this my punishment? Cheap joke. Seriously, would the workstation OS affect this?

TODO:

  • Test from a different workstation OS

EDIT

I've checked the SSH logs to see if anything meaningful could be added, and this is the output caused by attempting to upload (obscured some data with % placeholders):

$ tail -f /var/log/secure
Nov 11 17:46:58 %server% sshd[22455]: Accepted publickey for cp5w from %ip% port %port% ssh2: RSA %fingerprint%
Nov 11 17:46:58 %server% sshd[22455]: pam_unix(sshd:session): session opened for user cp5w by (uid=0)
Nov 11 17:46:58 %server% sshd[22455]: pam_unix(sshd:session): session closed for user cp5w

I also enabled SFTP logs by modifying my sshd_config and adding -l INFO as follows:

Subsystem sftp  internal-sftp -l INFO

Followed /var/log/messages with the following:

$ tail -f /var/log/messages
Nov 11 18:06:57 %server% internal-sftp[23002]: session opened for local user cp5w from [%ip%]
Nov 11 18:06:57 %server% internal-sftp[23002]: opendir "/srv/www/."
Nov 11 18:06:57 %server% internal-sftp[23002]: closedir "/srv/www/."
Nov 11 18:06:57 %server% internal-sftp[23002]: open "/srv/www/website/current/app/AppKernel.php" flags WRITE,CREATE,TRUNCATE mode 0666
Nov 11 18:06:57 %server% internal-sftp[23002]: sent status Permission denied
Nov 11 18:06:57 %server% internal-sftp[23002]: session closed for local user cp5w from [%ip%]

Best Answer

I wonder if you are running selinux and this might have anything to do with your problem. What does getenforce or sestatus show if anything? If you are running enforcing, what happens if you switch to permissive?

If not, can you test and prove which user account that sftp is using to write files on your behalf? In principle it should be cp5w but is that the case in reality?

Finally you may find that chroot is not playing ball. Does it work without chroot?

Best of luck Mr Willmott.