42

I was able to do sftp yesterday to a RHEL 5.4 box (RedHat) and today I can't.

The message is "Received message too long 778199411", and after some investigation, it was due to my RHEL box's .bashrc having a line echo "running .bashrc" -- or echoing anything at all, I think.

So why would printing out a line affect sftp? It felt a bit like a design issue as printing out a line in .bashrc works in other situations such as log in or ssh and it is kind of hard to track down when sftp fails for such a weird reason.

So the question is, why printing out a line cause such error and what if we still like to print out something in .bashrc? (mainly to see when this file gets sourced/executed).

Improve this question
3
  • stackoverflow.com/questions/12440287/…
    – quanta
    May 21, 2013 at 15:58
  • I had this problem after I had put some echo statements in various scripts in /etc/profile.d and in ~/.bashrc to diagnose some other problem (which was: why is there a delay on ssh-ing into a remote server? Turns out it was because a script to ssh had -Y as an argument to ssh and was waiting for an X server on the client, which wasn't running) - anyway, rather than delete the echo statements I'd put in various login scripts, I wondered if echoing the messages to stderr instead of stdout would avoid the sftp error and it did, e.g. `>&2 echo "info: this is my_script.sh". Not enough rep!
    – drkvogel
    Dec 29, 2020 at 1:36
  • If you have your custom scripts in the ~/.bashrc just comment those.
    – Mohan
    Jan 20 at 6:49

6 Answers 6

Reset to default
47

This is a longstanding problem. I found it ten years ago when I first had to mix commercial SSH at work and open-SSH at home. I ran into it again today and found this post.

If I had searched for "sftp/scp fails but ssh is OK" I would have been reminded of the solution sooner!

Put simply, .bashrc, .bash_profile, .cshrc, .profile, etc., have to be silent for non-interactive sessions or they interfere with the sftp / scp connection protocol. 

This output confuses the sftp/scp client.  You can verify if your shell is doing this by executing: 
    ssh yourhost /usr/bin/true
If the above command produces any output, then you need to modify your shell initialization.

From the open-SSH FAQ: 2.9 - sftp/scp fails at connection, but ssh is OK.

Improve this answer
4
  • Self-updating shell utilities are a good culprits for this problem. For me it has often been Ruby Version manager interfering with Jenkins' deploy-over-ssh.
    – Eric P.
    Sep 3, 2014 at 13:33
  • Thanks for this, removing some debugging echo statements I had in my bashrc and bash_profile solved this for me.
    – SgtPooki
    Nov 14, 2014 at 18:56
  • 4
    Wrong .bashrc needs to be silent, .bash_profile can echo with no problems.
    – kubanczyk
    Dec 13, 2015 at 22:52
  • 3
    For anyone landing here: As suggested in serverfault.com/a/630714, you can use ssh yourhost /usr/bin/true to probe the output of your ssh. In my case, I found some command in ~/.bashrc started to produce errors.
    – Yuval Atzmon
    May 29, 2017 at 11:22
31

At least for SFTP this can be fixed by using the internal-sftp subsystem, as that does not read .bashrc or /etc/motd.

Simply change the /etc/ssh/sshd_config file and change the SFTP subsystem:

#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp

And the error is gone.

Improve this answer
4
  • I like this one.. just wonder if this has any security implications?
    – RoyM
    Feb 8, 2017 at 18:57
  • internal-sftp is, IMO, a better way to offer SFTP support. You can see this related post: serverfault.com/questions/660160/…
    – Kenneth
    Feb 9, 2017 at 21:04
  • After your sshd_config change suggestion, I killed sshd and sftp (not sure if there was a demon). First time got the Received Message too long error but was logged in anyway. Then back to the same problem
    – clearlight
    Oct 23, 2017 at 1:01
  • Thanks, this is the only way I've found to have enabled sftp, ssh and X forwarding in my server for the same user.
    – Miguel Ortiz
    Feb 13, 2020 at 14:31
10

just put following into top of ~/.bashrc on username of id on remote machine if that id uses bash

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

which simply exits early from the ~/.bashrc instead of sourcing entire file ... this solves making .bashrc silent when you are not logging into that id and are just running your scp or sftp with that username as the remote id ... to quote @Peter Scott in other answer : "Put simply, .bashrc and .bash_profile etc have to be silent or they interfere with the sftp / scp connection protocol."

Alternatively, if that remote id uses zsh then put following at top of its ~/.zshrc

# If not running interactively, don't do anything and return early
[[ -o interactive ]] || exit 0

If the shell on your remote machine does not use ~/.bashrc then make above edit in file ~/.bashrc_profile or ~/.profile or similar to suit your shell on that remote box

.... UPDATE ... by putting above snippet into top of file ~/.bashrc for user on remote box any ssh connection will source file ~/.bashrc which will simply read ~/.bashrc until is sees this snippet then stop continuing to source the remainder of file ~/.bashrc so as to avoid polluting the shell on that remote box with things ssh connection does not need nor want ... do NOT put snippet into any file which must get sourced or executed to completion as the point of this snippet is to exit early from sourcing file ~/.bashrc ( NOTE there is a difference between sourcing a file versus executing a file ) ... file ~/.bashrc is always sourced never executed

Improve this answer
7
  • This worked for me. Kenneth's answer to use the internal-sftp subsystem would only work if you have root access. Where I work that is not the case.
    – John
    Jan 24, 2020 at 12:20
  • Watch out people! After adding this command I was unable to ssh to my server at all! SSH immediately disconnects you!
    – Marc
    Jan 4, 2022 at 13:28
  • @Marc I have above snippet in production on all my boxes who all use bash no problems ... assure you copy exactly as is ... note the - sign as in $- do not leave that out
    – Scott Stensland
    Jan 4, 2022 at 14:20
  • I am also using your exact code on CentOS7 - I can again confirm it kills ssh. The connection is successful and then you are disconnected. I placed your code in /etc/profile.d/ansible.sh.
    – Marc
    Jan 4, 2022 at 15:45
  • @Marc please see my UPDATE note
    – Scott Stensland
    Jan 4, 2022 at 19:26
3

Every response I've seen anywhere on this all claim it is too much printed output via /etc/motd, or .bashrc, etc. Not always true. If you have an account that has no .bashrc, the /etc/motd is empty, and the default .bashrc is minimal with no printed output YOU CAN STILL have the problem. If you have a user account with a shell of /sbin/nologin or /bin/false this error will still happen.

Why would you do this??? If you were trying to grant someone root-jailed sftp, with no secure-shell access this will happen.

Work around: allow ssh and put them in a root jail as well. This is a problem that needs to be addressed in ssh, it's far too long in coming.

Improve this answer
3
  • I had this problem exactly because of too long custom output in my .bashrc (I have screenfetch there). But I still trying to figure out how to make it ignore this
    – vladkras
    Aug 11, 2016 at 12:16
  • Yes, that could be the case. You have to modify ssh. In our case it was a problem with the shell. We actually used an sftp client specifically for root-jail so didn't have to do all the root-jail stuff.
    – TekOps
    Aug 12, 2016 at 16:11
  • The point is I don't want to modify my .bashrc. I want to connect to server with any length of first message. So I do have to modify settings of my IDE probably
    – vladkras
    Aug 15, 2016 at 13:56
1

There can be one more reason. On RHEL 6 with openssh-5.3p1-122.el6.x86_64 we have found, that it behaves wrong when LOCALE remains at "C". When changed with:

export LC_ALL="en_US.UTF-8"

Then sftp behaves correctly. In the previous openssh-5.3p1-118 we haven't experienced such a behaviour so it's probably some minor bug in this build.

Improve this answer
1
  • 1
    This seemingly odd suggestion was what worked for my situation. Thanks!
    – jwd630
    Aug 9, 2019 at 1:54
0

In my case, to make it work, I needed to disable Ubuntu's welcome message.

Improve this answer
1
  • How did you do that?
    – Shayan
    Sep 5, 2022 at 16:49

Not the answer you're looking for? Browse other questions tagged or ask your own question.