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.
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.
Run a non-interactive remote command and watch for any output. A clean account should print nothing:
ssh user@host /bin/trueIf 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.
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:
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.
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:
# 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
ficase $- 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.
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:
some_setup_command >&2For 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.
Verify the stream is clean, then confirm SFTP connects:
ssh user@host /bin/true # should print nothing
sftp user@host # should connect with no errorIf 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:
Subsystem sftp internal-sftpValidate the config, then reload (reload re-reads config without dropping existing sessions):
sudo sshd -t
sudo systemctl reload ssh # Debian/Ubuntu; use sshd on RHEL/FedoraNote 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.
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.
sign_and_send_pubkey: no mutual signature supported
How to fix "sign_and_send_pubkey: no mutual signature supported" in SSH
sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation
How to fix "sign_and_send_pubkey: signing failed for RSA from agent: agent refused operation" in SSH
Bad owner or permissions on /home/user/.ssh/config
How to fix "Bad owner or permissions on .ssh/config" in SSH
No more authentication methods to try.
How to fix "No more authentication methods to try." in SSH
Error connecting to agent: Connection refused
How to fix "Error connecting to agent: Connection refused" in SSH