Periodically when I would upgrade OpenSSH on various servers (yes, I bought BSD CD set to help support them, you could do that or donate) I am responsible for, I would find that sftp to that server would break such that an sftp login would result in the cursed "Received message too long 458961005" error. If you google for a solution all answers point to the shell emitting text when sftp tries to connect. That is all fine and well, but how the heck do you fix it on a GNU/Linux (my favorite flavor today) box using GNU/bash as the shell ? I tried the various solutions such as ~/.hushlogin etc. and confirmed that nothing would be emitted even if I used ssh. So what was the problem?
The latest bout of 'no sftp' had gone on long enough so I again started searching for a fix. I came upon this link and it gave me a new clue. In my .bashrc startup file I typically do the following
test -s ~/.bashrc-local && . ~/.bashrc-localI don't have anything in .bashrc-local that emits any text so I never thought anything of it. However, what the heck, nothing else has worked, so I used the clue from the above link and did this
if [ ${TERM} != "dumb" ]; then
test -s ~/.bashrc-local && . ~/.bashrc-local
fi
and, by gosh, now I could sftp to this server! What the heck! Well, I
do color code my servers' login screens by using a program by
Moshe Jacobson
called color. So, my .bashrc-local was emitting
characters, though not text, when I would ssh or sftp to the
machine. Adding the test for "dumb" fixed the problem.
I hope this helps you. I have seen many postings with the problem and few solutions.
%%end