sftp dá um erro: “Mensagem recebida muito longa” e qual é o motivo?

Question

Eu consegui fazer sftp ontem para uma caixa RHEL 5.4 (RedHat) e hoje não posso.

A mensagem é "Received message too long 778199411" e, após algumas investigações, foi devido a% ba_de% da minha caixa RHEL ter uma linha .bashrc - ou ao ecoar alguma coisa, eu acho.

Então, por que imprimir uma linha afetaria echo "running .bashrc" ? Parecia um problema de design, já que imprimir uma linha em sftp funciona em outras situações, como login ou .bashrc , e é difícil rastreá-lo quando ssh falha por um motivo tão estranho.

Então a questão é: por que imprimir uma linha causa tal erro e se ainda quisermos imprimir algo em sftp ? (principalmente para ver quando este arquivo é originado / executado).

    

Answer 1

Este é um problema de longa data. Descobri isso dez anos atrás quando tive que misturar SSH comercial no trabalho e abrir o SSH em casa. Eu encontrei novamente hoje e encontrei este post.

Se eu tivesse procurado por "sftp / scp falhar, mas ssh está OK", eu teria me lembrado da solução mais cedo!

Simplificando, .bashrc e .bash_profile etc precisam ficar em silêncio ou interferir no protocolo de conexão sftp / scp.

Veja as perguntas abertas do SSH:

2.9 - O sftp / scp falha na conexão, mas o ssh está OK. / a>

    

Answer 2

Pelo menos para o SFTP, isso pode ser corrigido usando o subsistema internal-sftp , pois isso não lê .bashrc ou /etc/motd .

Basta alterar o arquivo /etc/ssh/sshd_config e alterar o subsistema SFTP:

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

E o erro desapareceu.

    

Answer 3

Todas as respostas que eu vi em qualquer lugar sobre isso, todos afirmam que é muito saída impressa via /etc/motd , ou .bashrc , etc. Nem sempre é verdade. Se você tiver uma conta que não tenha .bashrc , o /etc/motd esteja vazio e o padrão .bashrc seja mínimo sem saída impressa, VOCÊ PODE TER o problema. Se você tiver uma conta de usuário com um shell de /sbin/nologin ou /bin/false , esse erro ainda ocorrerá.

Por que você faria isso? Se você estava tentando conceder a alguém root-coailed sftp , sem acesso seguro ao shell, isso acontecerá.

Trabalhe em torno: permita ssh e coloque-os em uma cadeia raiz também. Este é um problema que precisa ser resolvido em ssh , está demorando para acontecer.

    

Answer 4

Pode haver mais um motivo. No RHEL 6 com o openssh-5.3p1-122.el6.x86_64, descobrimos que ele se comporta mal quando LOCALE permanece em "C". Quando alterado com:

export LC_ALL="en_US.UTF-8"

Então o sftp se comporta corretamente. No openssh-5.3p1-118 anterior, nós não experimentamos tal comportamento, então é provavelmente um pequeno bug nesta build.

    

Answer 5

No meu caso, para que funcionasse, eu precisava desativar a mensagem de boas-vindas do Ubuntu.