sftp da un error: "Mensaje recibido demasiado tiempo" y ¿cuál es el motivo?

26

Pude hacerlo sftpayer a una caja RHEL 5.4 (RedHat) y hoy no puedo.

El mensaje es "Received message too long 778199411", y después de un poco de investigación, se debió a que mi caja RHEL .bashrctenía una línea echo "running .bashrc", o me hizo eco de algo, creo.

Entonces, ¿por qué afectaría la impresión de una línea sftp? Se sintió un poco como un problema de diseño, ya que imprimir una línea en .bashrcobras en otras situaciones, como iniciar sesión o sshes difícil de rastrear cuando sftpfalla por una razón tan extraña.

Entonces, la pregunta es, ¿por qué imprimir una línea causa tal error y qué pasa si todavía nos gusta imprimir algo .bashrc? (principalmente para ver cuándo se obtiene / ejecuta este archivo).

sftp bashrc

— nopole
fuente

stackoverflow.com/questions/12440287/…

— quanta

26

Este es un problema de larga data. Lo encontré hace diez años cuando tuve que mezclar SSH comercial en el trabajo y SSH abierto en casa. Me encontré con él nuevamente hoy y encontré esta publicación.

Si hubiera buscado "sftp / scp falla pero ssh está bien", ¡me habría recordado la solución antes!

En pocas palabras, .bashrc y .bash_profile, etc. deben estar en silencio o interferir con el protocolo de conexión sftp / scp.

Consulte las preguntas frecuentes sobre SSH abierto:

2.9 - sftp / scp falla en la conexión, pero ssh está bien.

— Peter Scott
fuente

Las utilidades de shell de actualización automática son un buen culpable de este problema. Para mí, a menudo el administrador de Ruby Version interfiere con el despliegue de Jenkins sobre ssh.

— Eric P.

Gracias por esto, la eliminación de algunas declaraciones de eco de depuración que tenía en mi bashrc y bash_profile me resolvió esto.

— SgtPooki

3

.Bashrc incorrecto debe ser silencioso, .bash_profile puede hacer eco sin problemas.

— kubanczyk

2

Para cualquiera que aterrice aquí: como se sugiere en serverfault.com/a/630714 , puede usar ssh yourhost /usr/bin/truepara sondear la salida de su ssh. En mi caso, encontré algún comando en ~ / .bashrc que comenzó a producir errores.

— Yuval Atzmon

16

Al menos para SFTP, esto se puede solucionar mediante el uso del internal-sftpsubsistema, ya que no lee .bashrco /etc/motd.

Simplemente cambie el /etc/ssh/sshd_configarchivo y cambie el subsistema SFTP:

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

Y el error se ha ido.

— Kenneth
fuente

Me gusta este ... solo me pregunto si esto tiene alguna implicación de seguridad.

— RoyM

internal-sftpes, en mi opinión, una mejor manera de ofrecer soporte SFTP. Puede ver esta publicación relacionada: serverfault.com/questions/660160/…

— Kenneth

Después de su sugerencia de cambio sshd_config, maté a sshd y sftp (no estoy seguro de si había un demonio). La primera vez recibí el mensaje de error Recibido demasiado tiempo pero inició sesión de todos modos. Luego volvemos al mismo problema

— clearlight

2

Cada respuesta que he visto en alguna parte sobre esto afirma que es demasiada salida impresa a través de /etc/motd, o .bashrc, etc. No siempre es cierto. Si tiene una cuenta que no tiene .bashrc, /etc/motdestá vacía y el valor predeterminado .bashrces mínimo sin salida impresa. AÚN PUEDE tener el problema. Si tiene una cuenta de usuario con un shell de /sbin/nologino /bin/falseeste error seguirá ocurriendo.

¿¿¿Por qué harías esto??? Si intentaba conceder a alguien encarcelado de raíz sftp, sin acceso seguro, esto sucederá.

Evite: permita sshy póngalos en una cárcel raíz también. Este es un problema que debe abordarse ssh, es demasiado tiempo para llegar.

— TekOps
fuente

Tuve este problema exactamente debido a la salida personalizada demasiado larga en mi .bashrc (tengo captura de pantalla allí). Pero todavía estoy tratando de descubrir cómo hacer que ignore esto

— vladkras

Sí, ese podría ser el caso. Tienes que modificar ssh. En nuestro caso fue un problema con el shell. De hecho, utilizamos un cliente sftp específicamente para root-jail, por lo que no tuvimos que hacer todas las cosas de root-jail.

— TekOps

El punto es que no quiero modificar mi .bashrc. Quiero conectarme al servidor con cualquier longitud del primer mensaje. Entonces, tengo que modificar la configuración de mi IDE probablemente

— vladkras

2

simplemente ponga lo siguiente en la parte superior de ~ / .bashrc en el nombre de usuario de la identificación en la máquina remota si esa identificación usa bash

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

que simplemente sale temprano de ~ / .bashrc en lugar de obtener todo el archivo ... esto resuelve silenciar a .bashrc cuando no está iniciando sesión en esa identificación y solo está ejecutando su scp o sftp con ese nombre de usuario como la identificación remota ... para citar a @Peter Scott en otra respuesta: "En pocas palabras, .bashrc y .bash_profile, etc. deben permanecer en silencio o interfieren con el protocolo de conexión sftp / scp".

Alternativamente, si esa identificación remota usa zsh, coloque siguiente en la parte superior de su ~ / .zshrc

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

Si el shell en su máquina remota no usa ~ / .bashrc, haga la edición anterior en el archivo ~ / .bashrc_profile o ~ / .profile o similar para adaptarse a su shell en esa caja remota

— Scott Stensland
fuente

1

Puede haber una razón más. En RHEL 6 con openssh-5.3p1-122.el6.x86_64 hemos encontrado que se comporta mal cuando LOCALE permanece en "C". Cuando se cambia con:

export LC_ALL="en_US.UTF-8"

Entonces sftp se comporta correctamente. En el anterior openssh-5.3p1-118 no hemos experimentado tal comportamiento, por lo que es probable que haya algún error menor en esta compilación.

— Jaroslav Kucera
fuente

1

Esta sugerencia aparentemente extraña fue lo que funcionó para mi situación. ¡Gracias!

— jwd630

0

En mi caso, para que funcione, necesitaba deshabilitar el mensaje de bienvenida de Ubuntu.

— Walty Yeung
fuente