Tengo algunos problemas con SSH en mi servidor Linux que ejecuta CentOS. Puedo conectarme bien a mi servidor usando PuTTY o ssh desde Windows cmd. Lo mismo ocurre con el uso de FTP seguro. Puedo conectarme al servidor, obtener una lista de archivos y todo está bien. El problema ocurre cuando intento enviar cualquier cantidad de datos a través de la red.
Cada vez que intento transferir algo más allá de un cierto umbral, la conexión falla y veo el mensaje 'Restablecimiento de la conexión por igual'. Tengo un archivo sql de aproximadamente 3 MB en mi directorio de inicio. Si intento enviarlo por FTP, comenzará la transferencia y morirá después de que se hayan transferido aproximadamente 48k. Luego iniciará una nueva conexión y transferirá otros 48k. Si uso PuTTY y abro una sesión, puedo conectarme e iniciar sesión bien. Si intento cat file.sqlnuevamente, la conexión finaliza y aparece el mensaje 'Restablecimiento de la conexión por igual'. Ir de mi estación de trabajo local al servidor es la misma situación. Tengo un poco de código fuente que necesito confirmar en mi repositorio svn alojado en el servidor, pero aparece el mismo mensaje 'Restablecimiento de conexión por igual'.
Sé que el problema está en mi estación de trabajo local porque puedo usar el macbook y ssh de mi esposa en el servidor sin problemas. Puedo ingresar a la caja de Linux de un amigo (usando la misma instalación de masilla) y enviarlo a mi servidor desde su servidor y descargar el archivo, abrir otra sesión de SSH desde su caja a mi servidor y capturar el archivo. Entonces, algo está sucediendo, pero no estoy seguro de qué. ¿Alguien tiene alguna idea?
Actualizar
He estado tratando de resolver esto un poco más, y parece que hay un límite estricto de la cantidad de datos que puedo transferir en una sola sesión ssh. Lo hago de inmediato si lo hago, cat file.sqlpero también puedo seguir escribiendo ls -lun número constante de veces y también recibiré el mensaje 'Restablecimiento de la conexión por igual'. He intentado:
- generar nuevas claves ssh
- reiniciar mi enrutador
- reiniciando mi computadora
- reiniciar el servidor remoto
Escribí un tcpdump en el servidor remoto, pero no entiendo TCP a un nivel tan detallado que tiene mucho sentido para mí. Encendí la depuración en ssh y aquí está la parte del registro que conduce a la conexión que se restablece:
Jul 24 23:10:56 server sshd[4507]: debug1: permanently_set_uid: 500/503
Jul 24 23:10:56 server sshd[4507]: debug1: Entering interactive session for SSH2.
Jul 24 23:10:56 server sshd[4507]: debug1: server_init_dispatch_20
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384
Jul 24 23:10:56 server sshd[4507]: debug1: input_session_request
Jul 24 23:10:56 server sshd[4507]: debug1: channel 0: new [server-session]
Jul 24 23:10:56 server sshd[4507]: debug1: session_new: init
Jul 24 23:10:56 server sshd[4507]: debug1: session_new: session 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_open: channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_open: session 0: link with channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_open: confirm session
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_req: channel 0 request pty-req reply 1
Jul 24 23:10:56 server sshd[4507]: debug1: session_by_channel: session 0 channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_input_channel_req: session 0 req pty-req
Jul 24 23:10:56 server sshd[4507]: debug1: Allocating pty.
Jul 24 23:10:56 server sshd[4505]: debug1: session_new: init
Jul 24 23:10:56 server sshd[4505]: debug1: session_new: session 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_pty_req: session 0 alloc /dev/pts/2
Jul 24 23:10:56 server sshd[4507]: debug1: server_input_channel_req: channel 0 request shell reply 1
Jul 24 23:10:56 server sshd[4507]: debug1: session_by_channel: session 0 channel 0
Jul 24 23:10:56 server sshd[4507]: debug1: session_input_channel_req: session 0 req shell
Jul 24 23:10:56 server sshd[4508]: debug1: Setting controlling tty using TIOCSCTTY.
Jul 24 23:10:59 server sshd[4507]: Read error from remote host <my-ip>: Connection reset by peer
Jul 24 23:10:59 server sshd[4507]: debug1: do_cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: do_cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: cleanup
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: deleting credentials
Jul 24 23:10:59 server sshd[4505]: debug1: PAM: closing session
Jul 24 23:10:59 server sshd[4505]: pam_unix(sshd:session): session closed for user <me>
Jul 24 23:10:59 server sshd[4505]: debug1: session_pty_cleanup: session 0 release /dev/pts/2
ACTUALIZACIÓN 2:
Hace aproximadamente una semana, modifiqué mi configuración de ssh en mi servidor usando esta publicación de wiki: http://wiki.centos.org/HowTos/Network/SecuringSSH
Debido a que ocasionalmente necesito acceder a mi servidor desde el trabajo, y debido a que el puerto 21 está abierto en nuestro firewall, cambié el puerto ssh a 21. Para diagnosticar aún más este problema, intenté revertir mi configuración ssh y cambié el puerto ssh a 22 Bajo y he aquí, no encuentro el error cuando uso el puerto 22. Vuelva a cambiarlo a 21, y como un reloj cuando llego a 48k de datos transferidos - Restablecimiento de la conexión por igual.
Dado que puedo obtener la conexión inicial y que no he tenido problemas en el pasado para establecer conexiones ftp en el puerto 21, no parece que el problema sea la configuración de mi firewall.
Al menos en este punto, tengo el problema reducido al puerto ssh en mi servidor. Cambie a 21 y problemas instantáneos, vuelva a cambiar a 22, no hay problema en absoluto ...
¿Alguien puede pensar por qué el puerto de escucha marcaría la diferencia? Nuevamente, solo en mi caja de Windows XP está causando problemas. Avíseme si alguien tiene alguna idea sobre lo que podría causar esto.
Actualización 2:
Simplemente reduje el problema y me corrijo: es un problema de firewall, pero un problema de firewall de Windows, no en mi enrutador. Si uso el puerto 21 y desactivo el firewall de Windows, no encuentro el mensaje 'Restablecimiento de la conexión por igual'. Para responder a la pregunta obvia, sí, el puerto 21 está abierto en el firewall de Windows.
Dado que esta computadora está detrás del firewall en mi enrutador, puedo deshabilitarla por ahora, pero me interesaría averiguar qué está pasando aquí.
Respuestas:
Puede resolver el uso de la línea de comando con este comando (escriba esto como administrador):
netsh advfirewall set global statefulftp disablefuente
Esto podría estar relacionado con el enrutador que intenta manejar el seguimiento de la conexión FTP NAT automáticamente. Solo ocurriría en el puerto 21, no en el 22. Visite http://www.faqs.org/docs/iptables/complexprotocols.html
fuente