When the SCP server on localhost fails, the issue usually stems from SSH service misconfigurations, permission denials, or network stack errors. This guide walks you through verifying the SSH daemon status, checking file permissions, and resolving common authentication failures to restore secure file transfer capabilities immediately.
Verifying the SSH Daemon Status
The most common reason for an SCP failure is that the underlying SSH service is not running or has crashed. Since SCP relies entirely on the Secure Shell protocol, a non-functional SSH daemon will cause immediate connection drops. You must first confirm that the service is active on your local machine. On Linux systems, use thesystemctl command to check the status of the SSH service. Run sudo systemctl status sshd (or ssh on some distributions). If the output shows inactive or dead, the service is down. Start it using sudo systemctl start sshd and enable it to start at boot with sudo systemctl enable sshd. On Windows, ensure the OpenSSH Server feature is installed and started via the Services manager or PowerShell using Start-Service sshd.
If the service is running but still failing, check the logs for specific error codes. On systemd-based Linux systems, view recent logs with journalctl -u sshd --no-pager -n 50. Look for lines indicating port binding failures or key exchange issues. A failed bind often means another process is already using port 22, such as a conflicting SSH server instance or a residual zombie process. Killing the conflicting process and restarting SSH usually resolves this conflict.
For more details on handling intermittent connectivity issues that may affect SSH stability, refer to our guide on Troubleshooting SSH Connection Issues.
Checking File Permissions and Ownership
SCP enforces strict security policies regarding file ownership and permissions. If the source file or directory has overly permissive settings, or if the target directory lacks write access for the user, the transfer will fail silently or with a generic error. The SSH daemon refuses to handle files owned by other users or directories with world-writable permissions to prevent privilege escalation attacks. Verify the permissions of the file you are trying to send usingls -l filename. The owner should be the user executing the SCP command. If the file is owned by root or another user, change ownership using sudo chown $USER:$USER filename. Similarly, check the destination directory on the remote host (or localhost) to ensure it is writable. Use chmod 755 or chmod 700 on directories to restrict access appropriately while allowing the intended user to write.
Avoid using chmod 777 on any file or directory involved in the transfer. While this might seem like a quick fix, modern SSH configurations often reject connections if sensitive paths have insecure permissions. Correcting ownership and tightening permissions typically resolves "Permission denied" errors during SCP operations.
Resolving Authentication and Key Issues
Authentication failures are frequent culprits when SCP cannot establish a session. This includes incorrect passwords, expired keys, or mismatched authorized keys. When connecting to localhost, the client and server share the same identity, which can sometimes confuse key verification processes if multiple key pairs exist. First, ensure you are using the correct username. Connecting asscp file user@localhost:/path uses the current logged-in user by default, but explicitly specifying it avoids ambiguity. Check the ~/.ssh/authorized_keys file on the target account to ensure the public key used by the client is present and correctly formatted. Each key should be on a single line without trailing spaces.
If you are using password authentication, verify that the SSH daemon allows it. In the /etc/ssh/sshd_config file, ensure PasswordAuthentication yes is set. After changing configuration files, restart the SSH service with sudo systemctl restart sshd. For key-based auth, ensure the private key has restrictive permissions (chmod 600) and matches the public key uploaded to the server.
Debugging Network and Port Conflicts
Sometimes the failure is not with the application logic but with the network layer. Localhost transfers use the loopback interface, which should always be available. However, firewall rules or network managers might block local traffic between services. Check if any firewall is blocking local communication. While rare for localhost, tools likeufw or firewalld might have rules affecting loopback interfaces. Temporarily disable the firewall to test if the transfer succeeds. If it does, adjust the rules to allow traffic on port 22 for the loopback address specifically.
Additionally, verify that no proxy settings are interfering. Environment variables like http_proxy or https_proxy can sometimes redirect SCP traffic unexpectedly. Unset these variables before running the command: unset http_proxy https_proxy. This ensures SCP connects directly to the SSH daemon without intermediate redirections.
If you encounter similar connectivity hurdles in containerized environments, such as Docker containers failing to reach external servers, see our article on Docker Container Can't Connect to Outside Oracle Server for broader networking diagnostics.
Frequently Asked Questions
Why does SCP fail with "Connection refused" on localhost?
This error indicates that nothing is listening on port 22. Verify that the SSH daemon is actually running and bound to the correct interface. Restarting the service often clears temporary binding errors.
Can I use SCP to copy files between two different users on the same machine?
Yes, but you must specify the target username explicitly in the command syntax. Ensure the source user has read access to the file and the target user has write access to the destination directory.
What causes "Permission denied (publickey)" even with correct keys?
This usually happens if the private key file has incorrect permissions (not 600) or if the corresponding public key is missing or malformed in the authorized_keys file. Check both sides for consistency.
Does SCP work over IPv6 on localhost?
SCP defaults to IPv4 unless configured otherwise. If your system prioritizes IPv6, try forcing IPv4 by adding -4 to your SCP command or adjusting your SSH config to prefer IPv4 addresses for localhost.
How do I increase the timeout for large file transfers?
Use the -o ServerAliveInterval option to send keep-alive messages. For example, -o ServerAliveInterval=60 sends a ping every 60 seconds to prevent the connection from dropping due to inactivity.