How to fix scp: Received message too long in SSH

SSHINTERMEDIATEMEDIUMUpdated Sep 21, 2026· 719 views

The SFTP "Received message too long" error happens when shell startup files print text during login, corrupting the binary SFTP stream. The large number is those bytes read as a packet size.

Quick fix

Fixes scp: Received message too long

ssh user@host /bin/true
  1. Confirm extraneous output is the cause
  2. Find which startup file prints the text
  3. Guard output with an interactive-session check
  4. Send unavoidable output to stderr or remove it
ssh — error
ssh user@host /bin/true
scp: Received message too long

What this error means

SFTP runs over SSH using a binary packet protocol: every message begins with a 4-byte big-endian integer giving the length of the packet that follows. When the remote account's shell startup files (.bashrc, .bash_profile, /etc/profile, etc.) write any text to stdout during a non-interactive SSH session, that text reaches the SFTP client before the real protocol does. The client reads the first four bytes of that stray text as a packet length. Because arbitrary text bytes form a huge value, the length looks far larger than any legitimate packet, and the client aborts with "Received message too long." For example, the value 1416128883 is just the four ASCII bytes 0x54 0x68 0x69 0x73 — the characters "This" — interpreted as a 32-bit big-endian integer. In other words, the "size" the client complains about is literally the leading bytes of whatever your login scripts printed. Interactive SSH logins still work because the stray output is harmless on a terminal; only the byte-exact SFTP/SCP protocol is broken by it.

Typical symptoms

  • SFTP connection fails immediately with "Received message too long" followed by a large number
  • SCP transfers fail with the same or a similar packet-size error
  • Interactive SSH login (ssh user@host) works fine, but sftp/scp fails
  • GUI clients such as WinSCP, FileZilla, or Cyberduck report a packet/length error on connect
  • The large number stays the same between attempts when the startup output is unchanged (it is the leading bytes of that output, not random)
  • Running a remote command over SSH unexpectedly prints text before its real result

Common causes

  1. Shell startup files (.bashrc, .bash_profile, .profile, /etc/profile, .cshrc) run commands that print text on every login — echo, printf, fortune, neofetch, motd scripts, etc.
  2. System-wide initialization scripts in /etc emit a banner or status text without first checking whether the session is interactive
  3. Debugging or diagnostic print statements were left in a shell config file
  4. Output is sent to stdout instead of stderr, or is not guarded by an interactive/TTY check, so it leaks into non-interactive SFTP sessions
  5. On Windows OpenSSH, the user's PowerShell profile prints text and runs even though the shell is launched non-interactively

How to fix "scp: Received message too long"

1Confirm extraneous output is the cause

Run a non-interactive remote command and watch for any output. A clean account should print nothing:

bash
ssh user@host /bin/true

If you see any text, spaces, or banner output, your login scripts are writing to the stream that SFTP needs to keep clean. That stray output is the root cause.

2Find which startup file prints the text

For a non-login interactive shell, bash reads ~/.bashrc. For a login shell, it reads /etc/profile then the first of ~/.bash_profile, ~/.bash_login, ~/.profile. Inspect them and the system-wide files for anything that produces output:

bash
cat ~/.bashrc
cat ~/.bash_profile
cat ~/.profile
cat /etc/profile
cat /etc/bash.bashrc
ls /etc/profile.d/

Look for echo, printf, cat, fortune, neofetch, motd, banner, or any command whose output is not redirected. On csh/tcsh accounts check ~/.cshrc and ~/.login.

3Guard output with an interactive-session check

Wrap any output-producing commands so they only run for interactive sessions. The most reliable guard checks bash's own interactivity flag; you can additionally require a TTY on stdout:

bash
# In ~/.bashrc — skip everything below for non-interactive shells
case $- in
  *i*) ;;      # interactive: continue
  *) return ;; # non-interactive (SFTP/SCP/remote command): stop here
esac

# From here on it is safe to print
if [ -t 1 ]; then
  echo "Welcome to my server"
  fortune
fi

case $- in *i*) tests whether the shell is interactive; [ -t 1 ] tests whether stdout is a terminal. Either guard prevents output from leaking into the SFTP byte stream.

4Send unavoidable output to stderr or remove it

If a command must run during non-interactive sessions but you cannot suppress its chatter, redirect that chatter to stderr so it does not corrupt the SFTP data stream on stdout:

bash
some_setup_command >&2

For purely cosmetic or diagnostic output (debug prints, fortune, banners), the cleaner fix is to delete it or move it inside the interactive guard from the previous step. As a rule of thumb, put login-only setup (run once per login) in ~/.bash_profile and interactive-shell tweaks (prompt, aliases) in ~/.bashrc, but the interactive guard — not the file location — is what actually keeps SFTP working.

5Re-test SSH and SFTP

Verify the stream is clean, then confirm SFTP connects:

bash
ssh user@host /bin/true   # should print nothing
sftp user@host            # should connect with no error
6(Admin) Force the internal SFTP subsystem

If you administer the server and cannot rely on every user's startup files being clean, configure OpenSSH to use its built-in SFTP server. internal-sftp is handled inside sshd and does not spawn a login shell, so startup-file output can no longer corrupt the stream.

Edit /etc/ssh/sshd_config:

bash
Subsystem sftp internal-sftp

Validate the config, then reload (reload re-reads config without dropping existing sessions):

bash
sudo sshd -t
sudo systemctl reload ssh    # Debian/Ubuntu; use sshd on RHEL/Fedora

Note this fixes SFTP but not plain scp when scp uses its legacy shell-based mode; modern scp (OpenSSH 9+) defaults to the SFTP protocol and benefits from this change.

Advanced notes

The number in the error message is decimal and decodes directly to the offending bytes. Treat the value as a 32-bit big-endian integer and convert it to four bytes: 1416128883 = 0x54686973 = the ASCII characters "This". Whatever text your login scripts print first is what you will see encoded there, so the value is a useful clue to which line is responsible.

Protocol limits: the SFTP/SSH transport caps packet size (RFC 4253 requires implementations to accept at least 32768 bytes of payload, and OpenSSH refuses packets beyond roughly 256 KB), so any length derived from random text almost always exceeds the ceiling and trips the error.

Windows: with the Win32 OpenSSH server, the user's PowerShell profile (profile.ps1) can still run and print output for SSH-invoked shells. Either keep the profile silent for non-interactive use or define the sftp subsystem as sftp-server.exe / internal-sftp in sshd_config so no profile is sourced.

Large directory listings are a separate issue and are not caused by startup output — do not conflate them with this error.

Frequently asked questions

What does "scp: Received message too long" mean?
SFTP runs over SSH using a binary packet protocol: every message begins with a 4-byte big-endian integer giving the length of the packet that follows. ) write any text to stdout during a non-interactive SSH session, that text reaches the SFTP client before the real protocol does. The client reads the first four bytes of that stray text as a packet length.
How do I fix "scp: Received message too long"?
The SFTP "Received message too long" error happens when shell startup files print text during login, corrupting the binary SFTP stream. The large number is those bytes read as a packet size.
What causes "scp: Received message too long"?
Shell startup files (.bashrc, .bash_profile, .profile, /etc/profile, .cshrc) run commands that print text on every login — echo, printf, fortune, neofetch, motd scripts, etc. System-wide initialization scripts in /etc emit a banner or status text without first checking whether the session is interactive Debugging or diagnostic print statements were left in a shell config file
Is the "scp: Received message too long" error serious?
It is a medium-severity error — more of a blocker than a risk. The steps above resolve it.

Official resources & further reading