sftp登录linux Received message too long (or "Bad packet length") 原因，已解决

sftp and scp2 both actually work by running sshin a subprocess, to connect to the remote host and run the file-transferserver (usually namedsftp-server). For instance, the commandsftpserver might result in the following command beingrun (OpenSSH):

ssh server -s -oForwardX11=no -oForwardAgent=no -oProtocol=2 sftp

scp2/sftp and sftp-server use a special file-transferprotocol, which they speak over this SSH session. The protocol is in factbased 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 eitherend. What often happens, though, is that there are statements in eitherthe 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 beread by humans (likefortune,echo "Hi there!", etc.).Such code should only produce output on interactive logins, when there isa tty attached to standard input. If it does not make this test, it willinsert these text messages where they don't belong: in this case,polluting the protocol stream between scp2/sftp andsftp-server. The first four bytes of the text gets interpretedas 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" intransliterated Hebrew).

The reason the shell startup files are relevant at all, is that sshdemploys the user's shell when starting any programs on the user's behalf(using e.g./bin/sh -c "command"). This is a Unixtradition, 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 anycommands, should authentication still accidentally succeed for somereason.

There has been a lot of argument about whether this is the right behavior,since havingsshd instead execsftp-server directly,without the shell, would avoid this frequent problem. I personally feelthat using the shell is the right thing to do: having startup files thatemit text messages when there is no user to read them is just amistake.

SSH2 has a Boolean configuration statementAllowCshrcSourcingWithSubsystems, set false by default, whichcausessshd2 to pass the-f flag to the shell whenrunning subsystem programs (sftp-server is run as an SSH-2"subsystem"). With most shells,-f causes the shell to omit thenormal startup file processing. This prevents the corruption problem, butintroduces other difficulties. With file transfers, the umask setting isimportant, and people are confused when they find that the umask they setin their~/.login file works with random remote commands(e.g. ssh server touch foo), but is mysteriously ignoredwhen usingscp2/sftp.

Check your .bashrc and .bash_profile on the server, remove anything that can echo. For now, comment the lines out.

一句话，把bashrc，bash_profile所有带echo的都去掉