Pude hacerlo sftp
ayer 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 .bashrc
tení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 .bashrc
obras en otras situaciones, como iniciar sesión o ssh
es difícil de rastrear cuando sftp
falla 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).
Respuestas:
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.
fuente
ssh yourhost /usr/bin/true
para sondear la salida de su ssh. En mi caso, encontré algún comando en ~ / .bashrc que comenzó a producir errores.Al menos para SFTP, esto se puede solucionar mediante el uso del
internal-sftp
subsistema, ya que no lee.bashrc
o/etc/motd
.Simplemente cambie el
/etc/ssh/sshd_config
archivo y cambie el subsistema SFTP:Y el error se ha ido.
fuente
internal-sftp
es, en mi opinión, una mejor manera de ofrecer soporte SFTP. Puede ver esta publicación relacionada: serverfault.com/questions/660160/…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/motd
está vacía y el valor predeterminado.bashrc
es mínimo sin salida impresa. AÚN PUEDE tener el problema. Si tiene una cuenta de usuario con un shell de/sbin/nologin
o/bin/false
este 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
ssh
y póngalos en una cárcel raíz también. Este es un problema que debe abordarsessh
, es demasiado tiempo para llegar.fuente
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
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
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
fuente
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:
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.
fuente
En mi caso, para que funcione, necesitaba deshabilitar el mensaje de bienvenida de Ubuntu.
fuente