How to fix scp: Permission denied in SSH

SSHINTERMEDIATEMEDIUMUpdated Jan 4, 2026ยท 501 views

The scp permission denied error occurs when your user account lacks read permissions on the source file or write permissions on the destination directory. This commonly happens due to file ownership mismatches, missing SSH keys, or incorrect file permissions on the remote server.

Quick fix

Fixes scp: Permission denied

ssh user@remote ls -ld /path/to/destination
  1. Verify the destination directory exists and check its permissions
  2. Check ownership of the destination directory
  3. Fix directory ownership if you have sudo access
  4. Ensure the destination directory has correct write permissions
ssh โ€” error
ssh user@remote ls -ld /path/to/destination
scp: Permission denied

What this error means

SCP (Secure Copy Protocol) is unable to transfer your file because either you cannot read the source file on your local machine or you cannot write to the destination directory on the remote server. This is a file system permission issue, not an SSH authentication problem. The error indicates that while SSH authentication succeeded, the actual file operation failed due to insufficient filesystem permissions.

Typical symptoms

  • SCP commands fail with 'Permission denied' after SSH connection is established
  • Able to SSH into the remote server but scp transfers fail
  • Error occurs specifically when copying files to certain directories on the remote server
  • File transfers work to some directories but not others
  • Copying from the remote server fails even though you can view the file contents via SSH

Common causes

  1. The destination directory on the remote server is owned by a different user (e.g., root) and your SSH user lacks write permissions
  2. The source file you're trying to copy has read permissions restricted to its owner, and you're not the owner
  3. The destination directory has a umask that prevents your user from writing new files
  4. You're using the wrong SSH key for your user account (authentication succeeds with fallback key but that user doesn't own the target directory)
  5. File already exists in the destination with read-only permissions, blocking overwrite attempts
  6. SSH key permissions are incorrect (~/.ssh should be 700, authorized_keys should be 600) on the remote server

How to fix "scp: Permission denied"

1Verify the destination directory exists and check its permissions

First, check if the destination directory actually exists and what permissions it has:

bash
ssh user@remote ls -ld /path/to/destination

If the directory doesn't exist, create it first:

bash
ssh user@remote mkdir -p /path/to/destination

Look at the output - the first 10 characters show permissions. If it shows drwxr-xr-x with a different owner, that's likely your issue.

2Check ownership of the destination directory

Verify who owns the destination directory:

bash
ssh user@remote ls -l /path/to/destination

The third column shows the owner. If it's a different user (e.g., root) and you need write access, you'll need to change ownership or use a directory you own.

To check which user you're logged in as:

bash
ssh user@remote whoami
3Fix directory ownership if you have sudo access

If the destination directory is owned by root (or another user) but you need write access, change ownership to your user:

bash
ssh user@remote sudo chown -R user:user /path/to/destination

Replace user with your actual SSH username (run whoami if unsure). The -R flag recursively changes ownership of the directory and all contents.

If you don't have sudo access, skip to the next step.

4Ensure the destination directory has correct write permissions

Even if you own the directory, it needs write (w) permissions:

bash
ssh user@remote chmod 755 /path/to/destination

Or if you want stricter permissions (only you can write):

bash
ssh user@remote chmod 700 /path/to/destination

The first number (7) means read+write+execute for the owner, second (5 or 0) for group, third (5 or 0) for others.

5Use a directory you own if you can't change permissions

If you lack sudo access and can't change ownership, copy to your home directory instead:

bash
scp /local/file.txt user@remote:~/file.txt

Your home directory (~) is always writable by your user. You can then move the file later if needed (assuming you have appropriate permissions for the destination).

6Check source file permissions if copying FROM remote

If you're copying FROM the remote server and getting permission denied, the source file must be readable by your SSH user:

bash
scp user@remote:/path/to/file.txt /local/destination/

Check what user owns it:

bash
ssh user@remote ls -l /path/to/file.txt

If a different user owns it and you lack read permissions, ask the file owner to change permissions:

bash
ssh user@remote chmod 644 /path/to/file.txt

This makes the file readable by everyone while keeping write access restricted to the owner.

7Verify SSH key configuration for authentication issues

If the above steps don't help, the issue might be SSH key related. Verify you're using the correct key:

bash
scp -i /path/to/private/key /local/file.txt user@remote:/destination/

Also ensure remote SSH directory permissions are correct:

bash
ssh user@remote chmod 700 ~/.ssh
ssh user@remote chmod 600 ~/.ssh/authorized_keys

Incorrect permissions on these files can prevent the correct user authentication, causing you to authenticate as a different user without write access.

8Use verbose mode to diagnose the exact error

For more detailed error information, use the verbose flag:

bash
scp -v /local/file.txt user@remote:/destination/

You can use multiple v's for even more detail:

bash
scp -vv /local/file.txt user@remote:/destination/
scp -vvv /local/file.txt user@remote:/destination/

The verbose output will show exactly where the permission check is failing - whether it's on the destination directory, an existing file, or SSH key authentication.

Advanced notes

SELinux and AppArmor: On systems with SELinux or AppArmor enabled, file permission issues can be masked by security policy denials. Check journalctl -xe for SELinux denials or /var/log/audit/audit.log for details. Umask differences: The remote server may have a restrictive umask (set in ~/.bashrc or /etc/profile) that prevents newly created files from being world-writable. Understanding umask: your effective permissions are (default permissions) AND NOT (umask). File already exists: If a file of the same name already exists in the destination with read-only permissions, scp cannot overwrite it. You may need to delete the existing file first: ssh user@remote rm /destination/file.txt. Root-owned system directories: Some directories like /var/www or /opt are typically owned by root. Copying to these requires either sudo access on the remote system or coordination with the system administrator to grant your user write access to a specific subdirectory. Consider requesting that an admin create a writable subdirectory for your use.

Frequently asked questions

What does "scp: Permission denied" mean?
SCP (Secure Copy Protocol) is unable to transfer your file because either you cannot read the source file on your local machine or you cannot write to the destination directory on the remote server. This is a file system permission issue, not an SSH authentication problem. The error indicates that while SSH authentication succeeded, the actual file operation failed due to insufficient filesystem permissions.
How do I fix "scp: Permission denied"?
The scp permission denied error occurs when your user account lacks read permissions on the source file or write permissions on the destination directory. This commonly happens due to file ownership mismatches, missing SSH keys, or incorrect file permissions on the remote server.
What causes "scp: Permission denied"?
The destination directory on the remote server is owned by a different user (e.g., root) and your SSH user lacks write permissions The source file you're trying to copy has read permissions restricted to its owner, and you're not the owner The destination directory has a umask that prevents your user from writing new files
Is the "scp: Permission denied" error serious?
It is a medium-severity error โ€” more of a blocker than a risk. The steps above resolve it.

Official resources & further reading