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?

Interesting analysis: 1349281116 (decimal) = 506C655C (hexadecimal) = Ple\ (text ASCII) When you connect directly with a terminal $ ssh ... do you get a response containing "Ple\"? — Boris, Nov 10 '17 at 17:31
Possible duplicate of [SFTP error "Received message too long"](https://stackoverflow.com/questions/8250379/sftp-error-received-message-too-long) — Kenster, Sep 22 '18 at 15:20

score 3 · Answer 1 · answered Feb 01 '15 at 16:22

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.

answered Feb 01 '15 at 16:22

R J

1,906
1
17
15

2

thanks, but I was looking for a solution on client side only, i.e. without changing anything on ssh-server side. – tomper Feb 01 '15 at 18:33
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. – R J Feb 02 '15 at 01:27
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. – RichTBreak Jul 12 '18 at 14:33
1

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. – Leo Jun 12 '20 at 02:06

Scott Stensland · Answer 2 · 2020-08-18T17:22:15.503

3

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

edited Aug 18 '20 at 17:22

answered Mar 11 '19 at 14:22

Scott Stensland

26,870
12
93
104

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. – user1052080 May 03 '19 at 07:08

score 2 · Answer 3 · answered Jan 26 '17 at 15:54

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.

score 0 · Answer 4 · answered Oct 23 '17 at 01:14

0

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

answered Oct 23 '17 at 01:14

clearlight

12,255
11
57
75

score -2 · Accepted Answer · edited May 23 '17 at 11:45

-2

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.

edited May 23 '17 at 11:45

Community

1
1

answered Feb 02 '15 at 05:53

tomper

717
2
11
25

sftp fails with 'message too long' error

5 Answers5