Você pode resolver usando a linha de comando com este comando (digite isso como administrador):
netsh advfirewall set global statefulftp disable
Estou tendo alguns problemas com o SSH no meu servidor Linux executando o CentOS. Eu posso conectar ao meu servidor bem usando PuTTY ou ssh do windows cmd. O mesmo vale para usar o FTP seguro. Eu posso conectar ao servidor, obter uma lista de arquivos e tudo está bem. O problema ocorre quando tento enviar qualquer quantidade de dados pela rede.
Sempre que tento transferir algo além de um determinado limite, a conexão falha e vejo uma mensagem "Conexão redefinida por peer". Eu tenho um arquivo sql que é cerca de 3 MB no meu diretório home. Se eu tentar FTP, ele começará a transferência e morrerá depois que aproximadamente 48k tiverem sido transferidos. Em seguida, ele iniciará uma nova conexão e transferirá outro 48k. Se eu usar o PuTTY e abrir uma sessão, posso me conectar e fazer login. Se eu tentar cat file.sql novamente, a conexão será encerrada e receberei uma mensagem 'Conexão redefinida por peer'. Indo da minha estação de trabalho local para o servidor é a mesma situação. Eu tenho um pouco de código-fonte que eu preciso para confirmar o meu repositório svn hospedado no servidor, mas a mesma mensagem 'Connection reset by peer' aparece.
Eu sei que o problema está na minha estação de trabalho local porque eu posso usar o macbook e o ssh da minha esposa no servidor sem problemas. Eu posso ssh na caixa linux de um amigo (usando a mesma putty install) e sftp para o meu servidor a partir deles e baixar o arquivo, abrir outra sessão ssh de sua caixa para o meu servidor e catar o arquivo. Então, algo está acontecendo, mas não tenho certeza do que. Alguém tem alguma ideia?
Atualizar
Eu tenho tentado descobrir isso um pouco mais, e parece que há um limite rígido da quantidade de dados que eu posso transferir em uma única sessão ssh. Eu bati imediatamente se eu faço cat file.sql , mas eu também posso continuar digitando ls -l um número consistente de vezes e também irá receber a mensagem 'Connection reset by peer'. Eu tentei:
Eu escrevi um tcpdump no servidor remoto, mas não entendo o TCP em um nível tão detalhado que faz muito sentido para mim. Liguei a depuração em ssh e aqui está a parte do log que leva à conexão sendo redefinida:
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
UPDATE 2:
Cerca de uma semana atrás, modifiquei minhas configurações do ssh no meu servidor usando esta postagem na wiki: link
Como ocasionalmente preciso acessar meu servidor do trabalho e, como a porta 21 está aberta no firewall, alterei a porta ssh para 21. Para diagnosticar ainda mais esse problema, tentei reverter minhas configurações ssh e alterei a porta ssh de volta para 22. Baixo e eis que oI não encontra o erro quando eu uso a porta 22. Mude de volta para 21, e goste de um relógio quando atingir 48k de dados transferidos - Conexão redefinida pelo peer.
Dado que eu posso obter a conexão inicial e que não tive nenhum problema no passado estabelecendo conexões ftp na porta 21, não parece que a configuração do meu firewall é o problema.
Pelo menos neste ponto, tenho o problema reduzido à porta ssh no meu servidor. Vire para 21 e problemas instantâneos, mude para 22, sem problemas ...
Alguém pode pensar em por que a porta de escuta faria diferença? Novamente, é apenas na minha caixa do Windows XP que está causando problemas. Deixe-me saber se alguém tem alguma opinião sobre o que pode causar isso.
Atualização 2:
Apenas reduzi o problema e sou corrigido - é um problema de firewall, mas um problema de firewall do Windows, não do meu roteador. Se eu usar a porta 21 e desativar o firewall do Windows, não encontrarei a mensagem 'Conexão redefinida pelo peer'. Para responder a pergunta óbvia, sim, a porta 21 está aberta no firewall do Windows.
Como este computador está atrás do firewall no meu roteador, posso desativá-lo por enquanto, mas estaria interessado em descobrir o que está acontecendo aqui.
Isso pode estar relacionado ao seu roteador que está tentando lidar com o rastreamento da conexão NAT do FTP automaticamente. Isso só aconteceria na porta 21 e não na 22. Confira o link