bad packet length

I can sftp (Port 22) from the (1) command line, (2) using Fugu, and have previously done so using (3) Transmit. Interestingly, however, Cyberduck fails too, if that's a clue ...?

I think I saw that bad packet message when the remote user account has stuff in the login scripts that produce output even for non-interactive SSH sessions.

Try to temporarily move aside .bashrc, .bash_profile, .profile, .login and other similar files.

It's been a while since I had this issue so I wanted to know myself. Here's a video that shows the issue:

http://screencast.com/t/ZQN0X3a9xay

Commands that produce output should go into the profile files because the shell doesn't execute these for non-interactive sessions. The rc files are executed both for interactive (or, more precisely, login sessions) and non-interactive sessions and they should contain only settings that don't produce output, such as variable assignments etc.

As an aside, sometimes that is annoying because the profile files are also *not* executed for new interactive sessions in programs like "screen", because strictly speaking those are not login sessions, but you'd really want them to run there. For that reason I sometimes do put commands producing output into .bashrc but I guard them with something like this:

[ $SSH_TTY ] && echo foo

OK, back to the issue at hand, the sftp and other commands that talk to a program and not to a shell on the other side expect a clean channel. Additional bytes coming in from the remote side confuse them.

rsync is the same:

$ rsync test.txt minime.local:
protocol version mismatch - is your shell clean?
(see the rsync man page for an explanation)
rsync error: protocol incompatibility (code 2) at /SourceCache/rsync/rsync-31/rsync/compat.c(60)
$ ssh -t minime.local vi .bashrc
[ ... cleaning out .bashrc ]
$ rsync test.txt minime.local:

The rsync man page does have helpful information in its DIAGNOSTICS section:

This message is usually caused by your startup scripts or remote shell facility producing unwanted garbage on the stream that rsync is using for its transport. The way to diagnose this problem is to run your remote shell like this:

ssh remotehost /bin/true > out.dat

then look at out.dat. If everything is working correctly then out.dat should be a zero length file. If you are getting the above error from rsync then you will probably find that out.dat contains some text or data. Look at the contents and try to work out what is producing it. The most common cause is incorrectly configured shell startup scripts (such as .cshrc or .profile) that contain output statements for non- interactive logins.

Hi Marc,

Thanks -- that's a really good lead and a very clear description of some diagnostics -- unfortunately, it doesn't seem to be the problem in my particular case. The remote host does have a .cshrc with some set, setenv, and source commands, but pushing the output of 'ssh remotehost /bin/true' to out.dat as you suggest does reveal a file of zero length, as it properly should.

Another possible source could be ssh version mismatches. Is the one machine that fails running a particularly old or new ssh daemon?

Maybe you can compare the output of command line sftp with the "-v" flag when connecting to the servers that work and the one that doesn't work. That might reveal a pattern.

Interesting ... ok, admittedly, it's a small sample (n=5), but all the successful ExpanDrive connections give:

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.7

whereas the one that is failing from ExpanDrive and Cyberduck (but working from the command line, Transmit, and Fugu) gives:

debug1: Remote protocol version 2.0, remote software version OpenSSH_4.5

The local computer has the following:
OpenSSH_5.0p1, OpenSSL 0.9.8h 28 May 2008

Could this be caused then by the mismatch between 4.5 on the remote computer and 5.0 on the local? On the otherhand, the command line sftp still works fine ... ?

thanks for your continuing help on this

Interesting that your Mac has OpenSSH_5.0p1, on my Leopard machine "ssh -v" gives me

OpenSSH_4.7p1, OpenSSL 0.9.7l 28 Sep 2006

Did you install an updated OpenSSH package? What is the output of "which ssh" on your machine?

What happens if you try it in a completely fresh, unmodified Mac OS X user account? Or the guest account?

Also, do you have a config file in $HOME/.ssh?

Sometimes cipher incompatibilities are also an issue, but I thought that was only in very old versions:

http://www.omnigroup.com/mailman/arch...

I know I had to use a "Cipher" line in my $HOME/.ssh/config file a few years ago, but not recently.

The OpenSSH 5.0 was from a machine with the macports version first in the path, but even switching it so that /usr/bin/ssh is used (4.7, as you indicate) gives the same error message in ExpanDrive

p.s. I've been able to reproduce the problem on two different Macbook Pros now, and with a new, clean user, so I dont think that's it either

Now I'm out of new ideas :-)

Yea, I get this too on only one of my SFTP accounts. Any progress on fixing this issue?

I am having the very same problem when trying to make a connection to an FTP server on port 21.

I am having a similar problem. I can FTP just fine to a site with CyberDuck, but ExpanDrive gives me a bad packet length error.

Jeff - I was remembered that SFTP Drive for windows supported both FTP and SFTP, thought ExpanDrive uses same both protocols.

Thank you

Mark - as you can see one post below yours Jeff just posted that at the moment ExpanDrive doesn't support FTP but only SFTP.

I am looking forward for this FTP support as well as many users I guess ;)