sftp fails with 'message too long' error

Question

My java program uses ssh/sftp for transferring files into linux machines (obviously...), and my library for doing so is JSch (though it's not to blame).

Now, some of these linux machines, have shell login startup scripts, which tragically causes the ssh/sftp connection to fail, with the following message:

Received message too long 1349281116

After briefly reading about it, it's clearly a known ssh design issue (not a bug - see here). And all suggested solutions are on ssh-server side (i.e. disable scripts which output messages during shell login).

My question - is there on option to avoid this issue on client side?

Sawmill

Interesting analysis: 1349281116 (decimal) = 506C655C (hexadecimal) = Ple\ (text ASCII) When you connect directly with a terminal $ ssh ... do you get a response containing "Ple\"? – Paleography

Possible duplicate of SFTP error "Received message too long" – Ornithischian

Answer 1

Here's a quick-n'-dirty solution, but it seems to work - also on binary files. All credits goes to uvgroovy.

Given file 'some-file.txt', just do:

cat some-file.txt | ssh root:1.1.1.1 /bin/bash -c "cat > /root/some-new-file.txt"

Still, if anyone know a sftp/scp built-in way to do so on client side, it'll be great.

Sawmill

Answer 2

put following into the top of file ~/.bashrc on username of id on remote machine

# If not running interactively, don't do anything just return early from .bashrc
[[ $- == *i* ]] || return  

this will just exit early from the .bashrc instead of sourcing entire file which you do not want when performing a scp or sftp onto that target remote machine ... depending on shell of that remote username, make this edit on ~/.bashrc or ~/.bash_profile or ~/.profile or similar

Goldin

This is by far the cleanest solution. It will help to retain your precious .bashrc files by just bailing out in case of non-interactive shells, such as scp. Perfect. Thanks. – Further

Answer 3

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

Try again. You should not be seeing this message again.

Butane

thanks, but I was looking for a solution on client side only, i.e. without changing anything on ssh-server side. – Sawmill

I could be wrong, but I don't think that can be done from the client side, since this is a server side issue. But if you or anyone else finds otherwise, I'd be interested to know. – Butane

FYI Only .bashrc should be silent, .bash_profile can contain echo commands without causing the unwanted behavior. This is because only .bashrc is called when starting a subshell. – Heresy

In my case , this was the culprit, recently had added something to .bashrc at server side that was even prompting for a password. removed it and worked. – Enjoin

Answer 4

I got that error too, during and sftp get call in a bash script.

And according to the TO's error message, which was similar to mine, it looks like the -B option of the sftp command was set. Although a buffer size of 1349281116 bytes is "a bit" too high.

In my case I also did set the buffer size explicitly (with "good intentions"), which cause the same error message, followed by my set value.

Removing the forced value and letting sftp run with the default of 32K solved the problem to me.

-B buffer_size
         Specify the size of the buffer that sftp uses when transferring
         files. Larger buffers require fewer round trips at the cost of 
         higher memory consumption. The default is 32768 bytes.

In case it confirms to be the same issue, that whould suite as client side solution.

Normalie

Answer 5

NOTE: I had to fix .bashrc output on the remote hosts, not the host that's issuing the scp or sftp command.

Taegu