26

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 get sourced/executed).

26

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 and .bash_profile etc have to be silent or they interfere with the sftp / scp connection protocol.

See the open-SSH FAQ:

2.9 - sftp/scp fails at connection, but ssh is OK.

  • 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 '14 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 '14 at 18:56
  • 3
    Wrong .bashrc needs to be silent, .bash_profile can echo with no problems. – kubanczyk Dec 13 '15 at 22:52
  • 2
    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 '17 at 11:22
16

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.

  • I like this one.. just wonder if this has any security implications? – RoyM Feb 8 '17 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 '17 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 '17 at 1:01
2

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

  • 1
    For ~/.zshrc: [[ -o interactive ]] || exit 0 – Christopher yesterday
1

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.

  • 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 '16 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 '16 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 '16 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.

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

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

protected by Community Jul 22 '18 at 5:41

Thank you for your interest in this question. Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).

Would you like to answer one of these unanswered questions instead?

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