当使用sftp或者scp时出现错误解决办法。

godmoney

                （1）ssh连接正常，但是当使用sftp或者scp时出现Received message too long (or "Bad packet length") 1399791731。
$ sftp user@yourIP
Connecting to XX.XX.XX.XX...
user@XX.XX.XX.XX's password:
Received message too long 1399791731
这个通常是由于在服务器端，有过多的输出造成的，例如在~/.bashrc下加入了echo命令，
$cat ~/.bashrc
So so so lag.
So so so lag.
So so so lag.
So so so lag.
这个时候就会出现以上错误。
附上ssh FAQ相关部分，
SSH Frequently Asked Questions
When I try to use sftp or scp2, I get a message like this:
Received message too long (or "Bad packet length") 1416586337
and the connection fails.  What's wrong?
sftp and scp2 both actually work by running ssh
in a subprocess, to connect to the remote host and run the file-transfer
server (usually named sftp-server).  For instance, the command
sftp server might result in the following command being
run (OpenSSH):  
ssh server -s -oForwardX11=no -oForwardAgent=no -oProtocol=2 sftp
scp2/sftp and sftp-server use a special file-transfer
protocol, which they speak over this SSH session.  The protocol is in fact
based on the same packet protocol used by SSH.
In order for this to work, the SSH session must be "clean" — that is,
it must have on it only information transmitted by the programs at either
end.  What often happens, though, is that there are statements in either
the system or per-user shell startup files on the server
(.bashrc, .profile, /etc/csh.cshrc,
.login, etc.) which output text messages on login, intended to be
read by humans (like fortune, echo "Hi there!", etc.).
Such code should only produce output on interactive logins, when there is
a tty attached to standard input.  If it does not make this test, it will
insert these text messages where they don't belong: in this case,
polluting the protocol stream between scp2/sftp and
sftp-server.  The first four bytes of the text gets interpreted
as a 32-bit packet length, which will usually be a wildly large number,
provoking the error message above.  Notice that:
1416586337 decimal = 546F6461 hex = "Toda" ASCII  
suggesting a string beginning "Today..." (or maybe "Thank-you" in
transliterated Hebrew).
The reason the shell startup files are relevant at all, is that sshd
employs the user's shell when starting any programs on the user's behalf
(using e.g. /bin/sh -c "command").  This is a Unix
tradition, and has advantages:

• The user's usual setup (command aliases, environment variables,
  umask, etc.)  are in effect when remote commands are run.
  
• The common practice of setting an account's shell to
  /bin/false to disable it will prevent the owner from running any
  commands, should authentication still accidentally succeed for some
  reason.
  

There has been a lot of argument about whether this is the right behavior,
since having sshd instead exec sftp-server directly,
without the shell, would avoid this frequent problem.  I personally feel
that using the shell is the right thing to do: having startup files that
emit text messages when there is no user to read them is just a
mistake.
SSH2 has a Boolean configuration statement
AllowCshrcSourcingWithSubsystems, set false by default, which
causes sshd2 to pass the -f flag to the shell when
running subsystem programs (sftp-server is run as an SSH-2
"subsystem").  With most shells, -f causes the shell to omit the
normal startup file processing.  This prevents the corruption problem, but
introduces other difficulties.  With file transfers, the umask setting is
important, and people are confused when they find that the umask they set
in their ~/.login file works with random remote commands
(e.g. ssh server touch foo), but is mysteriously ignored
when using scp2/sftp.
               
               
               
               
               

本文来自ChinaUnix博客，如果查看原文请点：http://blog.chinaunix.net/u3/92845/showart_2116082.html