☰

SSH 연결 시간 초과 문제를 진단하는 방법은 무엇입니까?

tag-icon • tag-icon debian ssh openssh troubleshooting
SSH 연결 시간 초과 문제를 진단하는 방법은 무엇입니까?

Debian 7을 실행하는 VPS가 있고 Windows 시스템에서 PuTTY를 사용하여 연결합니다. 대부분의 경우 PuTTY가 잘 접속이 되어 정상적으로 로그인이 됩니다. 그러나 PuTTY는 때때로 이 상태를 보고합니다 Connection Timeout.

지난번에 이런 일이 발생했을 때 SSH를 실행하는 포트에 텔넷을 시도했지만 연결할 수 없었습니다. 그런 다음 서비스가 실행되고 있는 것으로 알고 있는 VPS의 다른 포트에 텔넷을 시도했는데 연결은 괜찮았습니다.

"재생"이 시작되면 5~10번 연결을 시도하면 성공적으로 연결할 수 있습니다. 시스템 로그를 확인했지만 이 문제를 해결하는 데 도움이 될 만한 흥미로운 내용을 찾지 못했습니다. 가치가 있다면 서버가 "실행 중"인 동안 서버에 연결하면 속도가 느려지는 것 같습니다(명령을 입력하면 SSH 창에 표시되는 데 1~2초 정도 걸립니다).

대부분의 경우 방화벽이 작동하기 때문에 방화벽 문제는 아닌 것 같지만 때로는 그렇지 않은 경우도 있습니다. 호스트가 유지 관리를 하고 있는 것 아닐까요?

편집: TCPKeepAlive가 활성화되었습니다. 방금 다시 나타났으며 SSH 포트에 텔넷을 시도하면 실제로 연결할 수 있습니다. 이상한.

답변1

진단하려면 먼저 putty.exe의 상세 모드를 사용해야 합니다.

cmd를 열고 다음을 사용하십시오.

putty.exe -v -ssh user@]host

-v는 더 많은 정보를 보여줍니다.

긴밀한 연결을 방지하려면 설정을 확인하십시오.

PuTTY(Win): 세션 속성 > 연결로 이동하고 빈 패킷을 보내 세션을 유지합니다. 아래에서 연결 유지 간격(0은 꺼짐)을 300(5분)으로 설정합니다.

Linux(ssh)의 경우: 시스템 전체에서 연결 유지를 활성화하려면 다음을 수행하십시오.

  • 모든 사용자의 경우: /etc/ssh/ssh_config를 편집하십시오.
  • 당신에게 맞는 방법: 대신 ~/.ssh/config를 편집하세요.

다음을 삽입하세요.

Host *
    ServerAliveInterval 300
    ServerAliveCountMax 2

/etc/ssh/sshd_config에 다음을 추가하여 OpenSSH 서버가 클라이언트에 대한 모든 연결을 유지하도록 활성화할 수도 있습니다.

KeepAlive yes
ClientAliveInterval 300
ClientAliveCountMax 2

이러한 설정으로 인해 SSH 클라이언트 또는 서버는 300초(5분)마다 상대방에게 빈 패킷을 보내고, 2회 시도 후에도 응답이 수신되지 않으면 연결이 끊어질 가능성이 가장 높은 지점에서 포기하게 됩니다. 어쨌든 폐기되었습니다.

ssh_config 매뉴얼 페이지에서:

서버 최대 활동 수ssh(1)가 서버로부터 메시지를 다시 받지 못하는 경우 보낼 수 있는 서버 활성 메시지 수(아래 참조)를 설정합니다. 서버 활동 메시지를 보내는 동안 이 임계값에 도달하면 ssh는 서버와의 연결을 끊고 세션을 종료합니다. 서버 활동 메시지의 사용은 TCPKeepAlive(아래)와 매우 다르다는 점에 유의하는 것이 중요합니다. 서버 활동 메시지는 스푸핑될 수 없도록 암호화된 채널을 통해 전송됩니다. TCPKeepAlive 활성화된 TCP keepalive 옵션은 스푸핑 가능합니다. 서버 활동성 메커니즘은 클라이언트나 서버가 연결이 비활성화되는 시기를 알아야 하는 경우에 유용합니다.

기본값은 3입니다. 예를 들어, ServerAliveInterval(아래 참조)이 15로 설정되고 ServerAliveCountMax가 기본값으로 남아 있는 경우 서버가 응답하지 않으면 약 45초 후에 ssh의 연결이 끊어집니다. 이 옵션은 프로토콜 버전 2에만 적용됩니다. 프로토콜 버전 1에는 서버 활동 메시지에 응답하도록 서버에 요청하는 메커니즘이 없으므로 연결을 끊는 것은 TCP 스택의 책임입니다.

서버 활동 간격서버로부터 데이터가 수신되지 않는 경우 ssh(1)가 암호화된 채널을 통해 메시지를 보내 서버에 응답을 요청하는 시간 초과 간격(초)을 설정합니다. 기본값은 0입니다. 이는 BatchMode 옵션이 설정된 경우 이러한 메시지가 서버로 전송되지 않음을 의미하며 기본값은 300입니다. 이 옵션은 프로토콜 버전 2에서만 사용할 수 있습니다. ProtocolKeepAlives 및 SetupTimeOut은 이 옵션에 대한 데비안 전용 호환성 별칭입니다.

답변2

더 넓은 네트워크 문제를 배제하려는 것처럼 들리며 그렇게 하는 것이 아마도 옳을 것입니다.

ping(저는 항상 및 을 보면서 네트워크 대기 시간 측정을 측정하는 것을 고려합니다 . 로컬 인터넷 연결과 관련될 수 있는 매우 광범위한 문제가 있는지 확인하는 데 traceroute시간이 너무 오래 걸리지 않기 때문입니다 .)ping

VPS를 사용할 때 알아야 할 두 가지 일반적인 문제가 있다고 생각합니다.

  1. 너무 작은 VPS에서 너무 많은 콘텐츠를 실행하려고 하는 경우. 너무 많은 메모리를 사용하고 디스크 안팎으로 데이터/코드를 지속적으로 교환할 수 있습니다. 이제 디스크 사용량이 매우 많아 모든 것이 느려집니다. 예를 들어 SSH를 로드하는 데 시간이 오래 걸립니다.

    진단: 메모리 사용량을 모니터링합니다.

    위에메모리 사용량 및 기타 성능 정보에 대한 매우 대략적인 로그를 생성하는 편리한 방법일 수 있습니다. atop운영 비용은 RAM(32비트 및 64비트)의 약 5/10M입니다. 이는 Xen 또는 KVM 기반 VPS에서 작동합니다. OpenVZ(또는 기타 컨테이너 기반 VPS)에서 얼마나 잘 작동할지 잘 모르겠습니다.

  2. "시끄러운 이웃" 문제. 때로는 이전 문제를 겪고 있는 다른 사람으로 인해 발생하는 경우도 있습니다. :) 가상 시스템에서는 다른 많은 사람들과 하드웨어를 공유합니다. 누군가 "예상"보다 더 많은 디스크 IO(또는 더 많은 메모리)를 사용하는 경우 동일한 하드웨어의 다른 VPS가 영향을 받습니다.

    모니터링은 이를 진단하는 데에도 도움이 될 수 있습니다. 하지만 이는 좀 더 어렵고 전문적인 질문일 수 있습니다.

서비스의 실제 응답 시간에 가깝게 측정하고 모니터링할 수 있는 것(로그/차트)에 집중하는 것이 좋습니다. 이는 귀하의 VPS가 주로 공개 웹 서버이고 이를 수행할 수 있는 무료 평가판/제한된 서비스가 있는 경우 일반적인 요구 사항입니다.

좋은 호스트는 두 가지 모니터링 유형 모두에 대한 기본적인 조언 및/또는 도구를 제공할 것이라고 결론을 내릴 수 있지만 이것이 실제로 얼마나 일반적인지는 잘 모르겠습니다 :).

귀하의 VPS 제공업체는 이러한 유형의 문제를 알고 있을 것입니다. 진단 방법 중 하나는 해당 기관에 연락하여 발생한 문제를 설명하는 것입니다. :-).

답변3

왜 이런 일이 발생하는지 모르겠습니다(우리가 본 것처럼 소스, 대상 및 네트워크 구성 요소에 영향을 미치는 많은 요소가 있다는 것이 일반적인 합의인 것 같습니다).

scp그러나 실제 작업을 수행하기 전에 작은 더미 파일을 복사하면 ssh여러 Linux 및 AIX 환경에서 이 문제가 거의 해결되는 것으로 나타 났습니다 .

echo Copying small dummy file to $DESTINATION_IP
scp -o StrictHostKeyChecking=no -o PasswordAuthentication=no dummy.tmp testuser@$DESTINATION_IP:/tmp/. 
echo Testing ssh again
ssh -n -tt -o StrictHostKeyChecking=no -o PasswordAuthentication=no testuser@DESTINATION_IP

관련 정보