Re: SFTP is not working
From: Sale (blah@blah.bla)Date: 09/16/02
- Next message: Bernd Eckenfels: "Re: Fingerprints"
- Previous message: Ryan: "Fingerprints"
- In reply to: Ramakrishna Dasari: "SFTP is not working"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Sale" <blah@blah.bla> Date: Mon, 16 Sep 2002 01:09:25 -0400
Ramakrishna Dasari" <rdarsai@cisco.com> wrote in message
news:3D6DB723.6060608@cisco.com...
> Hi All,
> I can do ssh, scp but when i do sftp, after entering the password, i get
> "Received message too long 2020828788"
> How do i fix it ?
> Thanks
> Rama
>
Read FAQs
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.csrch, .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.
- Next message: Bernd Eckenfels: "Re: Fingerprints"
- Previous message: Ryan: "Fingerprints"
- In reply to: Ramakrishna Dasari: "SFTP is not working"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
