sftp昨天我可以对RHEL 5.4盒子（RedHat）进行操作，而今天我做不到。
消息是"Received message too long 778199411"，经过一番调查，这是由于我的RHEL框上.bashrc有一条线echo "running .bashrc"-我想是完全没有回声。
那么为什么打印一条线会产生影响sftp呢？感觉有点像设计问题，因为.bashrc在其他情况下（例如登录或登录）在工作中打印一条线，ssh并且sftp由于这种奇怪的原因而在失败时很难追查。
所以问题是，为什么打印出一行会导致这种错误？如果我们仍然喜欢在其中打印出什么内容.bashrc呢？（主要是查看此文件何时获得/执行）。
Answers:
这是一个长期存在的问题。十年前，当我第一次不得不在工作中混合使用商用SSH并在家中使用开放式SSH时，我发现了它。我今天再次碰到它，找到了这篇文章。
如果我搜索了“ sftp / scp失败，但ssh正常”，我将很快被提醒该解决方案！
简而言之，.bashrc和.bash_profile等必须保持静音，否则它们会干扰sftp / scp连接协议。
请参阅open-SSH常见问题解答：
ssh yourhost /usr/bin/true用来探测ssh的输出。就我而言，我发现〜/ .bashrc中的某些命令开始产生错误。
至少对于SFTP，可以使用internal-sftp子系统来解决此问题，因为它不会读取.bashrc或/etc/motd。
只需更改/etc/ssh/sshd_config文件并更改SFTP子系统：
#Subsystem sftp /usr/lib/openssh/sftp-server
Subsystem sftp internal-sftp
错误消失了。
internal-sftpIMO是提供SFTP支持的更好方法。：你可以看到这个相关的帖子serverfault.com/questions/660160/...
我在任何地方看到的每个响应都声称它是通过/etc/motd，或.bashrc等产生的过多打印输出。并非总是如此。如果您的帐户没有no .bashrc，则其/etc/motd为空，并且默认.bashrc值为最小值，并且没有打印输出，您仍然会遇到问题。如果您的用户帐户的外壳为/sbin/nologin或，/bin/false则仍然会发生此错误。
你为什么要这样做？？？如果您试图授予某人root-jailed sftp，而没有安全外壳访问权限，则会发生这种情况。
解决方法：允许ssh并将它们也放入根监狱。这是一个需要解决的问题，ssh时间太长了。
只需将以下内容放在远程计算机上ID的用户名的〜/ .bashrc顶部，如果该ID使用bash
# If not running interactively, don't do anything and return early
[[ $- == *i* ]] || return
它只是从〜/ .bashrc提前退出而不是获取整个文件...解决了当您不登录该ID并仅使用该用户名作为远程ID运行您的scp或sftp时使.bashrc静音的问题...在其他答案中引用@Peter Scott：“简单地说，.bashrc和.bash_profile等必须保持沉默，否则它们会干扰sftp / scp连接协议。”
或者，如果该远程标识使用zsh，则在其〜/ .zshrc顶部放置以下内容
# If not running interactively, don't do anything and return early
[[ -o interactive ]] || exit 0
如果远程计算机上的外壳不使用〜/ .bashrc，则在〜/ .bashrc_profile或〜/ .profile或类似文件中进行上述编辑，以适合您在该远程框中的外壳
可能还有另一个原因。我们发现在带有openssh-5.3p1-122.el6.x86_64的RHEL 6上，当LOCALE保持在“ C”时，它的行为是错误的。当更改为：
export LC_ALL="en_US.UTF-8"
则sftp行为正确。在先前的openssh-5.3p1-118中，我们还没有遇到过这种行为，因此这可能是该版本中的一些小错误。