A single SFTP Permission Denied message can come from three different layers, authentication, Unix file permissions, or a security policy like SELinux or AppArmor, and treating them as the same problem is the fastest way to waste time. One bad SSH key, one wrong chmod, or one hidden policy rule can block a transfer that looks identical on the surface.

You need a quick way to tell whether the failure sits on the client, the server filesystem, or the security layer, because each one needs a different fix. This guide shows you how to diagnose each case fast, then apply the right SFTP permission denied fix immediately, with a brief note on tools like openSFTP that make errors easier to read and a reference point for a different failure mode in /blog/sftp-connection-refused.

Is the problem really authentication, or just a bad key?

Check the login layer first

A lot of SFTP Permission Denied errors happen before SFTP ever reaches the file system. If SSH cannot authenticate you, the server rejects the session and the client may still show a generic access error. Microsoft’s example even shows Status: Access denied alongside Authentication failed and Critical, which tells you the login failed, not the upload [2].

Run one direct test from your client:

sftp -vvv user@host

Look for Authenticated ... using "publickey" or a refusal of the selected key. A FreeBSD forum log shows SSH can authenticate with public key even when password auth fails, which proves one method can work while another breaks [1]. That difference matters.

It Means You Should Not Start

It means you should not start changing server folders yet.

Fix the key mismatch

If the server rejects your key, check the obvious first. Make sure the private key on your machine matches the public key in authorized_keys, and verify key file permissions with chmod 600 ~/.ssh/id_ed25519 or the key you actually use. Broadcom notes that even hidden newline characters or copied key data that does not exactly match can break authentication [3].

Use this quick checklist:

  • Confirm the right key loads in your client
  • Compare the public key against authorized_keys
  • Run chmod 600 on private keys
  • Retest with sftp -vvv
  • If password login works but key login fails, focus on key auth, not SFTP itself [4]

If openSFTP shows the failure stage clearly, you save time because you can separate a bad key from a broken path faster than with a generic client. Once authentication succeeds, the next failure usually shifts to server-side permissions, which is a different layer entirely.

Could the server’s permissions be blocking SFTP after login?

Check ownership and mode

If sftp -vvv shows authentication succeeds, but uploads still fail with SFTP Permission Denied, the server filesystem is usually the next suspect. Microsoft’s SFTP guidance says specific users getting “Access denied” often points to ownership or permission problems, and on Linux you often see the same pattern when the account can log in but cannot write to the target directory [5].

Run one server-side check where the file lives:

ls -ld /path/to/target /path/to/target/file

You want to see that the user owns the directory or belongs to the group that owns it, with write permission where needed. An Ask Ubuntu case shows the practical version of this: the SFTP user needed to be in the owning group, and that group needed write access before uploads worked [7].

Fix the path

If the directory is owned by root or another account, fix ownership or permissions on the upload path, not just the user’s home directory. On Windows, Microsoft recommends checking NTFS permissions with icacls; on Linux, the same idea applies with chown and chmod [6].

Watch for chroot rules

If you use a chrooted SFTP setup, ChrootDirectory permissions matter too. The chroot root must stay owned by root and not be writable by the SFTP user, while the writable subdirectory sits inside it. That difference trips people up because the login works, but the session cannot cross the filesystem boundary.

In one real-world setup, an SFTP login worked from one server but failed from another until the private key was fixed from 0644 to 0600 and the target account’s ~/.ssh/authorized_keys was corrected; in a second case on a CentOS 8 host, the same error disappeared only after running restorecon on the chroot directory path. That last detail matters, because it moves the problem into the policy layer, not the Unix mode bits.

Is SELinux or AppArmor silently denying access?

Check the policy layer

If authentication works and Unix permissions look right, SELinux SFTP or AppArmor SFTP can still block the transfer. Red Hat notes that SELinux can deny actions even when the application itself is fine, simply because policy does not match how the service runs [8].

Run one log check on the server:

ausearch -m AVC,USER_AVC,SELINUX_ERR -ts today

If you see SELinux is preventing, you have a policy denial, not an SFTP login problem [10]. AppArmor tells a similar story, but it logs the program, operation=, and denied_mask= fields, so you can see exactly what the profile blocked [11].

Fix the policy, not the file mode

If SELinux blocks a chrooted SFTP path, restorecon often fixes the label mismatch, which is exactly what happened in a CentOS 8 SFTP chroot case earlier in this guide. If the policy is simply missing an allow rule, Red Hat’s audit2allow can generate one from the denial log, though some denials are nonfatal and may belong in dontaudit instead [14].

With AppArmor, check whether the profile is in enforce mode or complain mode. Debian’s man page says complain mode logs denials but does not enforce them [12], so a service can appear flaky across environments if one host enforces and another only complains. A systemd hardening change like ProtectHome=yes can also trigger unexpected AppArmor denials [13].

That gives you the last major branch, and the conclusion can now tie the three checks into one fast decision tree.

Diagnose the layer before you fix the error

A single “Permission denied” message can come from three different layers, authentication, Unix permissions, or mandatory access control, and now you can separate them instead of guessing. If sftp -vvv points to login failure, fix the SSH key or authorized_keys. If login succeeds but uploads fail, check ownership, modes, and ChrootDirectory permissions.

If both look correct, inspect SELinux SFTP or AppArmor SFTP logs for the silent deny.

That is the real SFTP Permission Denied fix, match the error to the layer, then change only the thing that actually broke.

Your Next Step Is Simple: Run

Your next step is simple: run sftp -vvv user@host, then check the server logs only if authentication succeeds.

Sources

  1. FreeBSD Forums, "Public key authentication can succeed even when password authentication fails" (2024-unknown) [https://forums.freebsd.org/threads/sftp-by-passwordauthentication-failing-ssh-by-pubkeyauthentication-still-fine.95024/]
  2. Microsoft Q&A, "SFTP client can show Access denied, Authentication failed, Critical" (2021-unknown) [https://learn.microsoft.com/en-us/answers/questions/680817/sftp-access-denied-problem]
  3. Broadcom Knowledge Base, "SFTP authentication can fail if key data does not exactly match, including hidden newline characters" (2024-unknown) [https://knowledge.broadcom.com/external/article?articleNumber=387929]
  4. Super User, "Server refused selected key while password authentication still worked" (2019-unknown) [https://superuser.com/questions/1445976/windows-ssh-server-refuses-key-based-authentication-from-client]
  5. Microsoft Learn, "Specific SFTP access denied errors can indicate ownership or permissions issues" (2024-unknown) [https://learn.microsoft.com/en-us/troubleshoot/windows-server/system-management-components/troubleshoot-sftp-issues-using-openssh]
  6. Microsoft Learn, "Use icacls for NTFS permissions and ForceCommand internal-sftp in sshd_config" (2024-unknown) [https://learn.microsoft.com/en-us/troubleshoot/windows-server/system-management-components/troubleshoot-sftp-issues-using-openssh]
  7. Ask Ubuntu, "SFTP user must belong to owning group and group must have write permission" (2012-unknown) [https://askubuntu.com/questions/196062/sftp-permission-denied-on-files-owned-by-www-data]
  8. Red Hat Enterprise Linux 9, "SELinux can deny access when policy does not match how an application runs" (2024-unknown) [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html-single/using_selinux/index]
  9. Red Hat Enterprise Linux 7, "Use ausearch or /var/log/messages to view SELinux denials" (2024-unknown) [https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/pdf/selinux_users_and_administrators_guide/red_hat_enterprise_linux-7-selinux_users_and_administrators_guide-en-us.pd]
  10. Debian Manpages, "AppArmor denials include operation and denied_mask fields" (2024-unknown) [https://manpages.debian.org/apparmor]
  11. Debian Manpages, "AppArmor complain mode logs but does not enforce" (2024-unknown) [https://manpages.debian.org/apparmor]
  12. Ubuntu AppArmor Mailing List, "ProtectHome=yes can trigger AppArmor denials" (2021-11) [https://lists.ubuntu.com/archives/apparmor/2021-November/012361.html]
  13. Ubuntu Manpage, "audit2allow can generate allow or dontaudit rules from denied operations" (2020-unknown) [https://manpages.ubuntu.com/manpages/focal/man1/audit2allow.1.html]

Frequently Asked Questions

How can I tell if an SFTP Permission Denied error is caused by my SSH key or by file permissions on the server?

Start with sftp -vvv user@host. If authentication fails in the debug output, the problem is the key or login setup; if authentication succeeds and uploads still fail, the issue is usually server-side permissions.

What is the fastest fix if my SFTP key is being rejected?

Confirm that the private key on your client matches the public key in authorized_keys, and make sure the private key is protected with chmod 600. Also check that your client is actually using the intended key, not a different one loaded from your SSH agent.

Can SFTP Permission Denied happen even when the folder permissions look correct?

Yes. SELinux or AppArmor can block access even when Unix ownership and mode bits are correct. If the logs show a policy denial, you need to fix the security label or profile instead of changing chmod.

Should I change the home directory permissions if uploads to a chrooted SFTP folder fail?

Usually no. In a chroot setup, the chroot root must stay owned by root and not be writable, while only the internal upload directory should be writable by the SFTP user.

What should I check first before blaming the server?

Check whether password or key authentication works at all, because many SFTP failures are really SSH login failures. If login is rejected, fix authentication first before touching filesystem permissions or SELinux rules.

When should I inspect SELinux or AppArmor logs?

Do that only after authentication succeeds and the target directory has the right ownership and permissions. At that point, a hidden policy layer is the most likely cause of the remaining access denial.