The Secure Copy Protocol (SCP) is a widely used method for securely transferring files between computers over SSH. While it’s highly efficient and secure, system administrators and developers alike often run into a frustrating issue— “Permission denied” errors. These errors can arise due to a variety of reasons, such as incorrect permissions, user rights, missing directories, or key authentication problems. Fortunately, resolving this issue usually just requires a bit of troubleshooting and understanding of how SCP and SSH permissions work.
TL;DR
A “Permission denied” error when using SCP usually stems from incorrect file or directory permissions, authentication issues, or incorrect syntax. Start by checking the file and directory permissions on the destination or source. Verify that you’re using the correct username and that SSH key authentication is set up properly. Always double-check your SCP command syntax and path locations before diving deeper into debugging.
Understanding the SCP “Permission Denied” Error
The error message typically looks like this:
scp file.txt user@remote:/home/user/
Permission denied, please try again.It may also be accompanied by:
Permission denied (publickey,password).This clearly indicates SCP was unable to authenticate you or access the intended file or directory.
Common Causes of the Error
Here are the most common causes behind a “Permission denied” error when using SCP:
- Incorrect username: You may be attempting to connect with a user account that doesn’t exist or lacks access to the target location.
- Insufficient file or directory permissions: The directory you are copying to or from may not allow access for your user.
- Missing SSH key or agent forwarding issue: SCP relies on SSH authentication. If the key is missing, insecure, or the agent is not properly forwarding, you’ve got a problem.
- Restricted shell environment: Some servers restrict SCP access via special shells like `rbash` or `nologin`.
- Using sudo on remote: SCP does not support invoking `sudo` directly on the remote shell, which can cause permissions issues.
Step-by-Step Fixes for the “Permission Denied” Error
1. Check the Username and Host Information
Start by ensuring the username you’re using in the SCP command exists on the remote server and has the right permissions:
scp file.txt correct-user@remote-host:/home/correct-user/If you’re unsure, try manually SSH-ing into the server:
ssh user@remote-hostIf this fails, SCP won’t work either.
2. Verify File and Directory Permissions
If the username is correct, check the permissions of the directory or file you’re transferring:
- Destination directory: Use
ls -ld /path/to/dirto verify it’s writable by your user account. - Source file: Ensure your account can read the file you’re copying.
To fix permissions, use:
chmod u+w /path/to/dir
chown user:user /path/to/dirNote: Use these with caution. Never globally open write permissions—especially on sensitive directories.
3. Set Correct Ownership
Ownership is crucial. Even if a directory is writable, if it’s not owned correctly, problems can occur. On the remote machine, use:
chown user:user /target/directoryThis sets the permissions so your current user has authority over the directory or file.
4. Avoid Using ‘sudo’ in SCP Directly
You might think you can copy files requiring elevated permissions using `sudo`, but SCP does not allow using `sudo` directly for remote commands:
scp file.txt user@remote:"sudo /root/file.txt" # This won't workIf you need root access to the destination directory, consider first copying the file to a directory your user owns, then SSH into the server and move it using sudo:
scp file.txt user@remote:/home/user/
ssh user@remote
sudo mv /home/user/file.txt /root/
5. Check SSH Key Authentication
If your account uses SSH key-based authentication, ensure:
- The key exists in
~/.ssh/on your local machine. - The public key is added to
~/.ssh/authorized_keyson the remote server.
You can test if your key works by running:
ssh -i ~/.ssh/id_rsa user@remoteIf SSH works but SCP still throws a permissions error, check agent forwarding or permissions of your private key:
chmod 600 ~/.ssh/id_rsa6. Use Verbose Output for Troubleshooting
To get more insight into the issue, use SCP with the -v (verbose) flag:
scp -v file.txt user@remote:/home/user/This will show the authentication steps and where the process is failing, making it easier to narrow down the problem.
7. Verify the Remote Shell Configuration
Ensure the remote account has a valid shell. If the shell is set to /sbin/nologin or /bin/false, SCP will not work. You can check the shell using:
cat /etc/passwd | grep userIf the shell is incorrect, update it (if you have access):
chsh -s /bin/bash user
8. Check SELinux or Firewall Restrictions (if applicable)
Systems using SELinux may deny certain access even when permissions seem correct. You can check SELinux status with:
getenforceIf it returns Enforcing, it might be the cause. You can test by setting it to permissive (note: do this only in safe environments):
sudo setenforce 0In addition, ensure that firewalls like `ufw` or `firewalld` aren’t interfering with SSH or SCP connections.
A Quick Word on SCP Alternatives
While SCP is effective, it’s considered outdated and its underlying protocol cannot handle some modern security expectations. Consider using:
- rsync over SSH: Offers robust features and better error reporting.
- sftp: Allows interactive sessions and more flexible file operations.
Conclusion
Getting the alarming “Permission denied” error when using SCP can halt your work and lead to unnecessary head-scratching. However, by methodically checking each potential cause—user identity, directory permissions, SSH authentication, and shell configuration—you’ll be equipped to resolve it reliably. Don’t forget to leverage tools like verbose output to identify the root cause quickly. And where possible, consider alternatives like rsync or sftp for more complex file transfers.
With careful configuration and best practices in SSH key management and file ownership, SCP can continue being a powerful part of your SysAdmin toolkit.