SCP Silently Ignored on the Remote Machine

Understanding the Silent Failure Mechanism

The Secure Copy Protocol (SCP) operates over an SSH connection by executing a specific command on the remote host to read or write files. Unlike interactive sessions, SCP expects a clean, unadulterated channel for its internal communication. When the remote system initializes the user's environment, it often runs scripts like .bashrc, .bash_profile, or /etc/profile. If these scripts contain commands that print text to standard output—such as welcome messages, uptime displays, or error warnings—that text gets mixed into the SCP data stream.

The SCP client interprets this unexpected textual garbage as part of the file data or as a protocol error. Because the SSH connection itself remains technically open and authenticated, the command does not return a visible error code to the terminal. Instead, the transfer appears to hang indefinitely or completes with zero bytes transferred, leaving the administrator confused about why the operation "silently" failed. This behavior is distinct from authentication failures or network timeouts, which produce explicit error messages.

Distinguishing SCP from SFTP

It is crucial to distinguish between SCP and SFTP in this context. While older versions of OpenSSH used the SCP protocol directly, modern implementations often tunnel SFTP through the SCP command line interface for security reasons. However, the issue of stdout interference remains relevant if the underlying subsystem still interacts with the user's shell environment during initialization. If you switch to using the sftp command explicitly, you might bypass some shell initialization issues, but relying on pure SCP requires strict control over shell startup scripts.

Identifying the Culprit Scripts

The first step in troubleshooting is identifying which script is generating the unwanted output. You can do this by simulating the non-interactive login that SCP performs. Run the following command on your local machine, replacing user and remote_host with your actual credentials:

ssh -T user@remote_host echo "test"

If this command outputs anything other than the word "test," then your shell configuration is interfering with non-interactive sessions. Common sources include:

• .bashrc: Often contains prompts or color definitions that print characters.
• .bash_profile: May source other files that generate output.
• /etc/profile: System-wide configurations that might display MOTD (Message of the Day).
• /etc/bashrc: System-wide bash settings.

If you find output here, that script is likely the cause of your SCP silence. For more complex connectivity issues, you might also want to review Troubleshooting kex_exchange_identification Error in Linux SSH Connection to rule out key exchange problems.

Implementing Fixes for Shell Initialization

Once you have identified the offending script, you need to modify it to suppress output during non-interactive sessions. The most robust method is to wrap any output-generating commands in a conditional check that verifies if the session is interactive.

Using the $PS1 Variable Check

In Bash, the variable $PS1 is set only for interactive shells. You can use this to guard your output statements. Add the following logic at the top of your .bashrc or .bash_profile:

# If not running interactively, don't do anything
case $- in
    *i*) ;;
      *) return;;
esac

This snippet checks the flags in the current shell. If the i flag is not present, the script returns immediately, preventing any subsequent lines from executing. This ensures that aliases, functions, and print statements are skipped during SCP transfers.

Redirecting Output Explicitly

If you cannot modify the core logic of a script, you can redirect standard output to /dev/null for specific commands known to cause issues. For example, if a script prints a welcome banner, change:

echo "Welcome to CentOS"

To:

[[ $- == *i* ]] && echo "Welcome to CentOS"

This one-liner ensures the message only appears if the shell is interactive. Be careful not to redirect output for commands that SCP might rely on for status updates, though typically, SCP handles its own status reporting independently of the shell's initial setup.

Alternative Transfer Methods

If modifying shell scripts is not feasible due to permission constraints or organizational policies, consider using alternative transfer methods that are less sensitive to shell initialization noise. Troubleshooting: Curl SFTP Uploads Empty File without Error highlights how different protocols handle data streams differently, which may inform your choice of tool.

Using rsync over SSH

The rsync command is often more resilient to minor shell output issues because it uses a different synchronization algorithm. It establishes an SSH connection and runs a daemon process on the remote side. While it can still be affected by severe stdout pollution, it generally provides better error reporting and recovery capabilities than SCP. Use the following syntax:

rsync -avz /local/path user@remote_host:/remote/path

This method is particularly useful for large directories or incremental backups where stability is paramount.

Using SFTP Directly

You can also use the interactive sftp client. While it requires manual input for individual files, it can be scripted using a batch file. This approach bypasses the SCP-specific protocol entirely, relying instead on the SFTP subsystem of SSH, which has stricter separation between administrative commands and file data.

Verifying the Solution

After applying the fixes, test the connection again using the diagnostic command provided earlier. Ensure that ssh -T user@remote_host echo "test" returns only "test". Then, attempt a small file transfer using SCP. If the transfer succeeds, gradually increase the file size to ensure the solution holds under load. Monitor the remote server's logs in /var/log/secure or /var/log/auth.log to confirm that no unexpected authentication warnings are appearing.

Frequently Asked Questions

Why does SCP work for small files but fail for large ones?

This is rarely the case with silent failures; usually, both small and large files fail equally. If small files succeed, the issue might be related to buffer sizes or network timeouts rather than shell output corruption. Check your SSH configuration for MaxStartups or bandwidth limits.

Can I disable the MOTD to fix this issue?

Yes, disabling the Message of the Day in /etc/motd or the PAM configuration can resolve the issue if that is the source of the output. Edit /etc/pam.d/sshd and comment out the line referencing pam_motd.so to prevent the message from being displayed during login.

Does this issue affect SFTP transfers as well?

SFTP is generally less susceptible because it uses a dedicated subsystem within SSH. However, if your shell scripts exit with a non-zero status or print critical errors before the SFTP subsystem starts, it may still fail. Testing with ssh -T helps identify if the root cause is shell-based.

How do I check if my shell is interactive?

You can check the value of the $- variable. If it contains the letter 'i', the shell is interactive. In non-interactive scripts or connections, this flag is absent. This is the standard way to guard profile scripts against unintended execution.

What if I don't have access to modify .bashrc?

If you cannot modify remote shell scripts, you may need to contact your system administrator. Alternatively, you can try using rsync with the --rsh option to specify a custom remote shell command that suppresses output, though this is complex to configure correctly.