Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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).

share|improve this question
    

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: http://www.openssh.org/faq.html

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

share|improve this answer
    
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
    
Wrong .bashrc needs to be silent, .bash_profile can echo with no problems. – kubanczyk Dec 13 '15 at 22:52

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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