An error occurred while connecting SFTP to the server.

Example:

When xshell is used in windows, a server does not respond for a long time.

However, ssh logon is still accessible.

Some error messages are displayed when you connect to the SFTP command on Linux:

[[email protected] ~]# sftp -o Port=5555 [email protected]:/usr/local/gdns/
Connecting to 192.168.18.15...
[email protected]‘s password:
Received message too long 1131376761




The reason is that there are standard output statements in. bashrc on the server.

[[email protected] etc]# cat ~/.bashrc


# .bashrc# User specific aliases and functionsalias rm=‘rm -i‘alias cp=‘cp -i‘alias mv=‘mv -i‘# Source global definitionsif [ -f /etc/bashrc ]; then     . /etc/bashrcfisource /opt/intel/vtune_amplifier_xe_2013/amplxe-vars.sh




The last script program will output:

Copyright (C) 2009-2014 Intel Corporation. All rights reserved.
Intel(R) VTune(TM) Amplifier XE 2013 (build 353306)




You need to remove these outputs, so change

source /opt/intel/vtune_amplifier_xe_2013/amplxe-vars.sh 1>/dev/null 2>&1




According to the related descriptions in SFTP, the first four bytes of the output character "copy" are spliced into 32-bit integers Based on the ASCII value. The hexadecimal value is436f7079, decimal is 1131376761, which is used as the packet length field in the transmission protocol. Therefore, this is a very large number, resulting in a connection error.

Attached FAQs

SSH frequently asked questionswhen I try to use SFTPOr SCP2, I get a message like this:

Received message too long (or "Bad packet length") 1416586337

And the connection fails. What's wrong?

SFTPAndSCP2Both actually work by runningSSHIn a subprocess, to connect to the remote host and run the file-Transfer Server (usually namedSftp-Server). For instance, the commandSFTPServerMight result in the following command being run (openssh ):

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

SCP2/SFTPAndSftp-ServerUse 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 (likeFortune,Echo "Hi there! ", Etc .). such code shoshould 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 streamSCP2/SFTPAndSftp-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/Bin/falseTo disable it will prevent the owner from running any commands, shocould authentication still accidentally succeed for some reason.

There has been a lot of argument about whether this is the right behavior, since havingSshdInstead ExecSftp-ServerDirectly, without the shell, wocould 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 statementAllowcshrcsourcingwithsubsystems, Set false by default, which causesSshd2To pass-FFlag to the shell when running subsystem programs (Sftp-ServerIs run as an SSH-2 "subsystem"). With most shells,-FCauses the shell to omit the normal Startup File Processing. this prevents the uption 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~ /. LoginFile works with random remote commands (e.g.SSHServerTouch foo), But is mysteriously ignored when usingSCP2/SFTP.

An error occurred while connecting SFTP to the server.