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

sftpOntem consegui fazer uma caixa RHEL 5.4 (RedHat) e hoje não posso.

A mensagem é "Received message too long 778199411"e, após alguma investigação, foi devido ao fato de minha caixa RHEL .bashrcter uma linha echo "running .bashrc"- ou ecoar qualquer coisa, eu acho.

Então, por que a impressão de uma linha afetaria sftp? Parecia um problema de design, imprimir uma linha em .bashrctrabalhos em outras situações, como logon ou, sshe é meio difícil rastrear quando sftpfalha por um motivo tão estranho.

Portanto, a pergunta é: por que imprimir uma linha causa esse erro e se ainda gostamos de imprimir alguma coisa .bashrc? (principalmente para ver quando esse arquivo é originado / executado).

Este é um problema de longa data. Eu o encontrei há dez anos quando tive que misturar SSH comercial no trabalho e SSH aberto em casa. Encontrei-o novamente hoje e encontrei este post.

Se eu tivesse pesquisado "sftp / scp falha, mas ssh está OK", teria sido lembrada da solução mais cedo!

Simplificando, .bashrc e .bash_profile etc devem ser silenciosos ou interferem no protocolo de conexão sftp / scp.

Veja o FAQ open-SSH:

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

Pelo menos para SFTP, isso pode ser corrigido usando o internal-sftpsubsistema, pois ele não lê .bashrcou /etc/motd.

Simplesmente altere o /etc/ssh/sshd_configarquivo e o subsistema SFTP:

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

E o erro se foi.

Todas as respostas que eu já vi em qualquer lugar afirmam que é muita saída impressa via /etc/motd, ou .bashrcetc. Nem sempre é verdade. Se você possui uma conta que não possui .bashrc, a /etc/motdestá vazia e o padrão .bashrcé mínimo, sem saída impressa. AINDA PODE AINDA ter o problema. Se você tiver uma conta de usuário com um shell /sbin/nologinou /bin/falseesse erro ainda ocorrerá.

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

Solução alternativa: permita sshe coloque-os em uma prisão raiz também. Esse é um problema que precisa ser resolvido ssh, e demora demais para chegar.

basta colocar o seguinte no topo de ~ / .bashrc no nome de usuário do id na máquina remota se esse ID usar o bash

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

que simplesmente sai mais cedo do ~ / .bashrc, em vez de buscar o arquivo inteiro ... isso resolve silenciar o .bashrc quando você não está efetuando login nesse ID e está executando seu scp ou sftp com esse nome de usuário como o ID remoto ... para citar Peter Scott em outra resposta: "Simplificando, .bashrc e .bash_profile etc precisam ficar em silêncio ou interferem no protocolo de conexão sftp / scp."

Como alternativa, se esse ID remoto usar zsh, coloque o seguinte no topo de seu ~ / .zshrc

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

Se o shell em sua máquina remota não usa ~ / .bashrc, faça a edição acima no arquivo ~ / .bashrc_profile ou ~ / .profile ou similar para se adequar ao shell nessa caixa remota

Pode haver mais um motivo. No RHEL 6, com o openssh-5.3p1-122.el6.x86_64, descobrimos que ele se comporta errado 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ão experimentamos esse comportamento, portanto é provavelmente um bug menor nesta compilação.

No meu caso, para fazê-lo funcionar, eu precisava desativar a mensagem de boas-vindas do Ubuntu.