터미널 프롬프트를 표시하는 원격 Linux 호스트에서 ~15초 지연이 가능한 이유는 무엇입니까?

터미널 프롬프트를 표시하는 원격 Linux 호스트에서 ~15초 지연이 가능한 이유는 무엇입니까?

Linux 호스트에 로그인 하려고 하면 ssh로컬 컴퓨터에 ssh 명령을 입력한 후 약 15초 후에 터미널 프롬프트가 나타납니다. 후속 연결에는 2~3초가 소요됩니다. 그러나 잠시 기다린 후 원격 호스트와의 연결을 끊었다가 다시 연결하면 ssh소요되는 시간은 처음과 동일합니다.

  • 운영 체제는 Amazon Linux 2입니다.
  • CPU 및 네트워크 다이어그램에는 전후에 이상이 없습니다.
  • UseDNS주석 처리되었습니다 /etc/ssh/sshd_config.

가능한 곳을 살펴 봐야겠습니다.

답변1

"Amazon Linux 2"라고 하셨는데, 이게 클라우드 호스트인가요?

그렇다면 현재 호스트가 클라우드에 어디에 있는지 정확히 파악하고 적절한 NAT 매핑을 생성하여 SSH 연결을 그곳으로 라우팅하는 데 많은 시간이 걸릴 수 있습니다. 그러나 기존 연결이 있는 경우 매핑이 이미 적용되고 있으며 두 번째 및 후속 연결이 더 빠르게 설정됩니다.

클라우드 호스트에서 실행 중인 특정 항목이 없는 경우 클라우드 공급자는 호스트가 완전히 유휴 상태이고 전원을 절약하기 위한 네트워크 연결이 없음을 감지하면 호스트를 자동으로 일시 중단할 수도 있습니다. 또는 가상 호스트를 데이터 센터의 다른 하드웨어 장치로 이동하여 로드를 최적화할 수 있으며, 처음 들어오는 SSH 연결은 CPU 리소스 및 네트워크 연결의 재최적화만 트리거하여 가상 머신이 다른 하드웨어 장치.

기본적으로 이것은 호스팅 제공업체에 문의해야 할 사항입니다.

답변2

설명에서 지연이 발생하는 위치가 명확하지 않습니다. 명령줄에서 "Enter"를 누른 후의 단계를 고려하세요.

  1. 컴퓨터가 SSH 구성을 확인합니다. 질문하셨기 때문에 오버헤드가 크지 않을 것 같지만 매우 복잡한 구성이라도 일반적으로 신속하게 처리할 수 있습니다.

  2. 컴퓨터는 (첫 번째) SSH 엔드포인트에 DNS 요청을 하고 응답을 기다려야 합니다. 응답이 없으면 약 30초의 시간 초과가 발생합니다. 액세스 구성 방법에 따라 여러 홉이 있을 수 있습니다.

  3. 컴퓨터가 엔드포인트와 TCP 핸드셰이크를 시작합니다. TelcoM이 말했듯이, 현명한 라우팅 및/또는 방화벽이 진행되고 있다면 시간이 걸릴 수 있습니다. 연결을 제한하여 DOS를 완화하는 것은 드문 일이 아닙니다.

  4. 서버는 공개 키를 제공하고 이를 컴퓨터에서 확인합니다.

  5. 서버는 셸 실행을 시작하고 모든 시작 파일을 실행합니다. 이는 캐시에 반드시 존재하지 않는 많은 파일이 준비되어 있음을 의미합니다. 여기에는 배너 메시지, 구성 경로 및 프롬프트 표시가 포함될 수 있습니다.

  6. (선택 사항) 점프 호스트인 경우 서버는 다음 홉의 클라이언트가 되어 2~5단계를 수행합니다.

  7. 원격 시스템으로부터 메시지를 받습니다.

ssh는 연결을 다중화하므로 두 번째 연결을 할 때 5단계부터 시작합니다.

ssh -v(또는 더 나은 방법 ) 을 사용하면 ssh -vvv이러한 단계에 걸리는 시간에 대한 통찰력을 얻을 수 있습니다.

답변3

잠재적인 원인이 너무 많아서 모두 나열할 수는 없습니다.모두, 무작위로 떠오르는 아이디어를 시도하는 데 시간이 오래 걸릴 수 있습니다.

(느린 응답, 잘못 구성된 LDAP 호출로 인한 적절한 인덱싱 부족으로 인해 속도가 느려지는 것을 보았습니다. 매우 바쁜 VM 호스트에서 커널의 성능 버그로 인해 속도가 느려지는 것을 보았습니다. 이는 이러한 문제를 추적하는 데 매우 어려울 수 있습니다.) .

대신, 로그인한 상태에서 돈을 어디에 쓰고 있는지 알아보는 것이 좋습니다.

나는 다음과 같이 시작할 것입니다 :

script -fc 'ssh -v server' -t /dev/null

이로 인해 ssh많은 단계가 기록되고 script행 사이에 경과된 시간이 (stderr에서) 방출됩니다.

더 간단한 예를 살펴보겠습니다.

script -fc 'echo a; sleep 1; echo b; sleep 1; echo c' -t /dev/null 
Script started, output log file is '/dev/null', timing file is '/dev/stderr'.
a
0.000733 3
          b
1.000921 3
          c
1.001222 3
          Script done.

여기서 우리는 라인 "a"와 "b" 사이에 약 1초가 걸렸고 라인 "b"와 "c" 사이에 약 1초가 걸렸다는 것을 알 수 있습니다( script타이밍 정보를 내보냅니다 ).뒤쪽에철사).

ssh -vscript너무 장황해서 스크립트 세션에서 명령 자체를 실행하고 싶을 수도 있습니다 . :)

이를 통해 속도 저하가 클라이언트와 서버 사이에서 발생하는지 아니면 주로 서버에서 발생하는지에 대한 단서를 얻을 수 있습니다.

또한 서버 자체에서 연결을 시도하여 클라이언트와 서버 간의 지연을 제거할 수도 있습니다.

속도 저하가 주로 서버에서 발생하는 경우 SSH 서버 및 PAM(예: `journalctl -u ssh -ef)에 대한 로그를 살펴보고 연결 시 상단을 주시하는 것이 좋습니다.

관련 정보