sftp dà un errore: "Messaggio ricevuto troppo a lungo" e qual è il motivo?

Sono stato in grado di fare sftpieri con una scatola RHEL 5.4 (RedHat) e oggi non posso.

Il messaggio è "Received message too long 778199411", e dopo alcune indagini, era dovuto al fatto che il mio box RHEL .bashrcaveva una linea echo "running .bashrc"- o echeggiava qualcosa, credo.

Quindi, perché la stampa di una linea dovrebbe influire sftp? Sembrava un problema di progettazione come stampare una linea in .bashrclavori in altre situazioni come il login o sshed è un po 'difficile rintracciare quando sftpfallisce per una ragione così strana.

Quindi la domanda è: perché stampare una riga causa tale errore e cosa succede se ci piace ancora stampare qualcosa .bashrc? (principalmente per vedere quando questo file viene fornito / eseguito).

Questo è un problema di vecchia data. L'ho trovato dieci anni fa quando per la prima volta ho dovuto mescolare SSH commerciale al lavoro e SSH a casa. L'ho incontrato di nuovo oggi e ho trovato questo post.

Se avessi cercato "sftp / scp fallisce ma ssh è OK" mi sarei ricordato prima della soluzione!

In parole povere, .bashrc e .bash_profile ecc. Devono essere silenziosi o interferiscono con il protocollo di connessione sftp / scp.

Vedi le domande frequenti su open-SSH:

2.9 - sftp / scp non riesce alla connessione, ma ssh è OK.

Almeno per SFTP questo può essere risolto usando il internal-sftpsottosistema, in quanto ciò non legge .bashrco /etc/motd.

Basta cambiare il /etc/ssh/sshd_configfile e cambiare il sottosistema SFTP:

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

E l'errore è sparito.

Ogni risposta che ho visto da nessuna parte su tutto ciò sostiene che si tratta di un output stampato eccessivo tramite /etc/motd, o .bashrc, ecc. Non sempre vero. Se si dispone di un account che non ha .bashrc, /etc/motdè vuoto e il valore predefinito .bashrcè minimo senza output stampato È POSSIBILE ANCORA avere il problema. Se si dispone di un account utente con una shell /sbin/nologino /bin/falsequesto errore si verificherà comunque.

Perché dovresti farlo ??? Se stavi tentando di concedere a qualcuno il root-jailing sftp, senza accesso sicuro alla shell questo accadrà.

Aggira: consenti sshe inseriscili anche in una prigione root. Questo è un problema che deve essere affrontato ssh, è troppo lungo per venire.

inserisci semplicemente in cima a ~ / .bashrc il nome utente dell'id sul computer remoto se quell'id usa bash

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

che semplicemente esce presto da ~ / .bashrc invece di reperire l'intero file ... questo risolve rendere silenzioso .bashrc quando non si accede a quell'id e si esegue semplicemente scp o sftp con quel nome utente come id remoto ... per citare @Peter Scott in un'altra risposta: "In parole povere, .bashrc, .bash_profile ecc. devono essere silenziosi o interferiscono con il protocollo di connessione sftp / scp".

In alternativa, se quell'ID remoto utilizza zsh, inserisci quanto segue in cima al suo ~ / .zshrc

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

Se la shell sul tuo computer remoto non usa ~ / .bashrc, esegui le modifiche sopra nel file ~ / .bashrc_profile o ~ / .profile o simili per adattarle alla shell su quel box remoto

Può esserci un motivo in più. Su RHEL 6 con openssh-5.3p1-122.el6.x86_64 abbiamo riscontrato che si comporta in modo errato quando LOCALE rimane su "C". Se modificato con:

export LC_ALL="en_US.UTF-8"

Quindi sftp si comporta correttamente. Nel precedente openssh-5.3p1-118 non abbiamo riscontrato un simile comportamento, quindi è probabilmente un bug minore in questa build.

Nel mio caso, per farlo funzionare, avevo bisogno di disabilitare il messaggio di benvenuto di Ubuntu.