ssh_exchange_identification : 읽기 : 피어에 의한 연결 재설정

OS X에서 우분투 12.04 서버로 ssh하려고합니다. 갑자기 물건이 작동을 멈출 때까지 SSH를 사용할 수있었습니다. 이것을 -v디버깅 하기 위해 온라인을 읽었습니다 . 출력은 아래와 같습니다. 다른 상자에 넣은 다음 해당 상자에서 서버로 ssh하면 로그인 할 수 있습니다. 이 문제를 디버깅하는 방법을 모르지만 배우고 싶습니다.

$ ssh -v me@server
OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
debug1: Reading configuration data /etc/ssh_config
debug1: /etc/ssh_config line 20: Applying options for *
debug1: /etc/ssh_config line 53: Applying options for *
debug1: Connecting to server [IP] port 22.
debug1: Connection established.
debug1: identity file /Users/me/.ssh/id_rsa type 1
debug1: identity file /Users/me/.ssh/id_rsa-cert type -1
debug1: identity file /Users/me/.ssh/id_dsa type -1
debug1: identity file /Users/me/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.2
ssh_exchange_identification: read: Connection reset by peer

지금까지 (메시지 보드의 조언에 따라) 호스트 거부 파일을 찾았 지만 내 컴퓨터에는 해당 파일이 없습니다.

$ cat /etc/hosts.deny 
cat: /etc/hosts.deny: No such file or directory

클라이언트 컴퓨터에는 관리자 액세스 권한이 있지만 서버에는 없습니다.

서버 sshd구성 에서 구성 파일을 변경하면 갑작스러운 변경이 발생할 수 있지만 관리자 권한 없이는이를 확인하거나 변경할 수 없습니다. 서버 관리자에게 (시간 내에) 도달 할 수없는 경우에도 다음을 시도 할 수 있습니다.

로그에는 로컬 버전 문자열 만 표시 sshd되므로 서버 및 중간 시스템 에서 실행중인 버전을 확인해야 합니다.

이러한 버전 (특히 중간 컴퓨터와 서버 사이의 로컬 컴퓨터와 서버 덜 사이에) 다른 경우 일부 협상 호환성, 이것은있을 수 있습니다 전에 일어났다 에서 ssh. 해결책은 명령 줄 ( ssh -c aes256-ctr등) 또는에서 암호, HostKeyAlgorithms 및 / 또는 MAC 항목을 단축하는 것이 었습니다 /etc/ssh/ssh_config.

-c/ Ciphers, -o HostKeyAlgorithms/ HostKeyAlgorithms및 -m/ MACs명령 줄 resp의 인수로 적절한 값을 보려면 디버그 정보 (중간체를 통해 연결에서 서버로 연결)를 찾아야 합니다. ssh_config가 변경되었습니다.

나는이 문제를 잠시 동안 경험하지 않았지만 IIRC를 수행했을 때 Ciphers 및 HostKeyAlgorithms 설정을 수동으로 강제 실행하기에 충분하여 서버 sshd버전을 업데이트 할 수 있었고 문제는 사라졌습니다.

fail2ban또는에 의해 금지되었을 수 있습니다 denyhosts. 이 경우 (그리고 확인하기 위해) 서버 제공 업체의 도움을받지 않으려면 다른 IP 주소 (예 : 다른 서버 또는 친구의 집 연결 또는 Wi-Fi 핫스팟 또는 TOR와 함께 SSH 사용.

로그인하면 IP 주소가 /etc/hosts.deny서버쪽에 실제로 나타나는지 확인하십시오 . 그렇다면 실제로 fail2ban또는 denyhosts범인이 범인이어야합니다.

denyhosts주소가 계속 차단 되지 않도록 하려면 이 질문에 대한 답변을 참조하십시오 . 들어 fail2ban와 IP를 발견 iptables -L --line-number하고하는 IP 차단 해제 iptables -D <chain> <chain number>, 당신은에 대한 자세한 내용 확인 howtoforge을 .

문제가 다시 발생하지 않도록 IP 주소를 화이트리스트 에 추가 fail2ban하고 denyhosts화이트리스트 (각각 /etc/fail2ban/jail.conf, line ignoreip및 /var/lib/denyhosts/allowed-hosts, 필요한 경우 생성 (배포에 따라 경로가 다를 수 있음))를 원할 수 있습니다.

호스트 서버에서 다음 위치에있는 ssh pub.key를 제거 ~/.ssh/authorized_keys하십시오 (Mac 용). 그런 다음 tail -f /var/log/auth.log다른 터미널을 열고 ssh를 다시 시도하십시오 ssh -v me@server. 암호를 묻는 메시지가 표시되면 ssh 키에 문제가있는 것입니다. 'ssh_exchange_identification : read : Connection reset by peer'응답이 계속 표시되면 시도가 실패한 후 '/var/log/auth.log'파일의 로그 항목에서 문제점을 식별 할 수 있어야합니다. 로그인하기.

여전히 연결에 실패하면 여기에 인증 파일에서 기록 된 항목을 게시하면 답변을 수정하겠습니다.

네트워크에 동일한 MAC 주소를 가진 여러 시스템이있는 경우 (예 : 가상 시스템의 사본을 작성하고 MAC 변경을 잊어 버린 경우) 발생할 수 있습니다.

의 ISP 이름 서버로 인해이 정보를 얻었습니다 /etc/resolv.conf. 이러한 네임 서버는 종종 과부하가 걸리며 역방향 DNS 조회에 실패 sshd하면 연결이 끊어집니다. 보다 안정적인 네임 서버를 사용하여 문제를 해결했습니다 (예 :) 8.8.8.8.

나는 같은 문제에 직면했다. ssh 세션을 성공적으로 열지 만 시간이 지나면 재설정됩니다. 게인을 즉시 연결하려고하면 "연결이 거부되었습니다"라는 오류가 발생합니다. 세션을 디버깅 할 때 연결이 재설정 될 때이 메시지가 표시되었습니다.

debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: client_input_channel_req: channel 0 rtype keepalive@openssh.com reply 1  
debug1: channel 0: free: client-session, nchannels 1                             
debug3: channel 0: status: The following connections are open:                   
  #0 client-session (t4 r0 i0/0 o0/0 fd 4/5 cfd -1)                              

debug3: channel 0: close_fds r 4 w 5 e 6 c -1                                    
Read from remote host 10.x.y.z: Connection reset by peer                    
Connection to 10.x.y.z closed.                                              
debug1: Transferred: stdin 0, stdout 0, stderr 100 bytes in 1029.9 seconds       
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.1                      
debug1: Exit status -1                                                           

이 시점에서 나는 네트워크에서 IP 주소 충돌이 있음을 깨달았다. 다른 주소로 변경했는데 문제가 해결되었습니다

로그는 서버 측에서 연결을 끊는 것을 의미합니다. 이유를 찾으려면 서버 측 로그를 참조해야하며 연결이 끊어진 이유를 표시해야합니다. 거의 항상 / var / log / messages에서 로그를 찾을 수 있어야합니다.

클라이언트가 버전 번호를 보낸 직후 연결이 끊어지면 서버가 클라이언트를 호환되지 않는 것으로 위협합니다.

나는 같은 문제가 있었지만 원인이 다르다는 것이 밝혀졌다. 나는 잘못된 포트를 사용하고 있었다.

최신 버전의 ssh오류는 Connection refused또는 Bad port입니다.

이전 버전에서 제공된 오류는 ssh_exchange_identification: read: Connection reset by peer

따라서 오류가 발생하면 포트가 올바른지 확인하십시오.

나는이 질문이 오래되었다는 것을 알고 있지만 내가 얻은 몇 가지 결과를 공유하고 싶었습니다. /var/empty/sshd서버에서 적절한 소유권과 권한이 있는지 확인하십시오 .

일부 디렉토리 권한을 업데이트하기 위해 chef 스크립트가 수정되었지만 의도하지 않은 대상 아래의 디렉토리를 업데이트하여 / var의 소유권을 응용 프로그램 사용자 / 그룹으로 변경하고 권한을 775로 변경했습니다.

답변에서 명시 적으로 언급되지 않았 으므로이 오류가 나타날 수있는 또 다른 방법은 서버와 사용자 사이의 네트워크 기반 방화벽이 연결을 차단하기로 결정한 경우입니다. 방화벽은 OS X 시스템의 IP로부터 "너무 많은"연결이 있다고 판단하여 차단하기 시작했습니다. 다른 시스템에서 아직 "너무 많은"연결이 없었으므로 허용되었습니다.

서버로부터받은 마지막 메시지는 인증 시도를 시작하기 전에 발생하여 계정, 키 또는 비밀번호를 둘러싼 많은 가능성을 배제한 것입니다.

임의의 벤더 샘플링에서 얻은 이러한 무차별 정책의 예는 다음과 같습니다.

• CloudFlare : 속도 제한을 사용하여 무차별 대입 공격을 방지하려면 어떻게해야합니까?
• F5 : 무차별 대입 공격 보호 구성
• FortiNet : 패턴 속도를 탐지하기위한 사용자 정의 IPS 서명 작성-무차별 대입 공격 탐지 예
• 팔로 알토 : 무차별 대입 공격 방지
• Sonicwall : SRA를 사용하여 무차별 대입 및 사전 공격을 차단하는 방법