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.
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.
First, check if the destination directory actually exists and what permissions it has:
ssh user@remote ls -ld /path/to/destinationIf the directory doesn't exist, create it first:
ssh user@remote mkdir -p /path/to/destinationLook at the output - the first 10 characters show permissions. If it shows drwxr-xr-x with a different owner, that's likely your issue.
Verify who owns the destination directory:
ssh user@remote ls -l /path/to/destinationThe 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:
ssh user@remote whoamiIf the destination directory is owned by root (or another user) but you need write access, change ownership to your user:
ssh user@remote sudo chown -R user:user /path/to/destinationReplace 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.
Even if you own the directory, it needs write (w) permissions:
ssh user@remote chmod 755 /path/to/destinationOr if you want stricter permissions (only you can write):
ssh user@remote chmod 700 /path/to/destinationThe first number (7) means read+write+execute for the owner, second (5 or 0) for group, third (5 or 0) for others.
If you lack sudo access and can't change ownership, copy to your home directory instead:
scp /local/file.txt user@remote:~/file.txtYour 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).
If you're copying FROM the remote server and getting permission denied, the source file must be readable by your SSH user:
scp user@remote:/path/to/file.txt /local/destination/Check what user owns it:
ssh user@remote ls -l /path/to/file.txtIf a different user owns it and you lack read permissions, ask the file owner to change permissions:
ssh user@remote chmod 644 /path/to/file.txtThis makes the file readable by everyone while keeping write access restricted to the owner.
If the above steps don't help, the issue might be SSH key related. Verify you're using the correct key:
scp -i /path/to/private/key /local/file.txt user@remote:/destination/Also ensure remote SSH directory permissions are correct:
ssh user@remote chmod 700 ~/.ssh
ssh user@remote chmod 600 ~/.ssh/authorized_keysIncorrect permissions on these files can prevent the correct user authentication, causing you to authenticate as a different user without write access.
For more detailed error information, use the verbose flag:
scp -v /local/file.txt user@remote:/destination/You can use multiple v's for even more detail:
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.
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.
Load key "/home/user/.ssh/id_rsa": invalid format
How to fix 'Load key invalid format' in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH
Connection closed by UNKNOWN port 65535
How to fix 'Connection closed by UNKNOWN port 65535' in SSH
Offending ECDSA key in /home/user/.ssh/known_hosts:line
How to fix "Offending ECDSA key in known_hosts" in SSH