SFTP permission denied but SSH works fine

Question

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%]

Solution 1

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.

Solution 2

The core problem is that your SFTP server requires SSH Key Authentication to properly permit connections. You mentioned with FileZilla, so I've written this answer as such.

In case, you can use this for non-password-protected SSH keys:

1. Open the FileZilla client.
2. From the top of the home screen, click on Edit and select Settings.
3. On the left side of the menu, expand the Connection section and highlight SFTP.
4. Click on the [Add keyfile...] button and browse your local machine's directories and select your Private Key file.
5. Then, again from the top of FileZilla's home screen, click on File and select Site Manager.
6. Finally, on the left side of the Site Manager, click on the New Site button and type a unique name under My Sites that will allow you to easily identify this particular remote server in the future.
7. Now, under the General tab, fill in the Host (with either an IP address or FQDN) and Port fields (default is 22).
8. In the Protocol dropdown menu, select SFTP - SSH File Transfer Protocol.

Comments

[user9517]

Do the server logs have anything interesting to say ?

[T N]

@Iain not really, but good point - I've added the ssh logs to my question. Is there any extra logging I might be able to configure?

[user9517]

What about messages/syslog etc plenty of others to look in.

[T N]

@Iain checked them aswell - nothing in either. I did however find this post serverfault.com/questions/73319/sftp-logging-is-there-a-way and consequently captured the INFO level log of the SFTP session specifically - updated question.

[womble]

"This used to work via SFTP a few days ago" -- something changed. Security update, perhaps? Sneaky hack? Cat walked on the keyboard? The symptoms sound like sftp isn't picking up secondary groups for your user.

[Serrano]

+1 For the cheap joke! Anyway, I had a similar issue just now. After manual SFTP to the server I found out I was being chroot-ed. Paths that work for SSH don't work for SFTP, hence the permission problem. This won't help you, but just putting it out there.

[T N]

getenforce returns Disabled and sestatus returns SELinux status: disabled so I guess its not that. Working on your other ideas.... thanks Stuart!