DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

SSH 연결이 느린 이유는 무엇인가요? 지연 시간 문제를 해결하는 다섯 가지 즉각적인 수정 방법

Secure Shell(SSH) 연결에서 발생하는 답답한 지연 시간을 진단하고 제거하세요. 이 가이드에서는 DNS 조회 및 GSSAPI 인증 비활성화를 포함한 다섯 가지 즉각적인 구성 수정 방법을 설명하여 빠른 터미널 응답 시간을 복원합니다. 암호화 최적화 및 연결 다중화 활용을 통해 원격 생산성을 향상시키는 실용적인 단계를 알아보세요.

SSH 연결이 느린 이유는 무엇인가요? 지연 시간 문제를 해결하는 다섯 가지 즉각적인 수정 방법

느린 SSH는 단일 문제가 아닙니다. 때로는 프롬프트가 나타나기도 전에 지연이 발생합니다. 때로는 로그인은 빠르지만 모든 키 입력이 끈적거리는 느낌이 듭니다. 때로는 느린 셸 시작 스크립트, 차단된 DNS 조회, 또는 노트북과 세계 반대편에 있는 클라우드 리전 간의 패킷 손실이 있는 네트워크 경로 때문에 SSH가 비난받기도 합니다.

설정을 변경하기 전에 간단한 테스트를 하나 실행하세요:

time ssh -vvv [email protected] exit

time 출력은 전체 연결이 느린지 알려줍니다. -vvv 출력은 클라이언트가 시간을 소비하는 위치를 알려줍니다. 반복되는 키 시도, GSSAPI 메시지, DNS 관련 일시 중지, 또는 인증 시작 전의 긴 간격을 찾아보세요. ssh user@host exit가 빠르지만 대화형 로그인이 느리다면 문제는 SSH 자체보다는 원격 셸 시작 파일에 있을 가능성이 높습니다.

세 가지 일반적인 패턴이 있습니다:

  1. 인증 전 느림: 일반적으로 DNS, GSSAPI, 호스트 키 조회, 또는 느린 인증 백엔드.
  2. 인증 후 프롬프트 전 느림: 일반적으로 .bashrc, .profile, .zshrc, 네트워크 마운트 홈 디렉토리, 또는 셸 플러그인.
  3. 입력 또는 전체 화면 도구 사용 중 느림: 일반적으로 실제 네트워크 지연 시간, 패킷 손실, 과부하된 엔드포인트, 압축 오버헤드, 또는 터미널 렌더링.

아래 수정 방법은 실제 SSH 지연 시간 문제를 해결하는 빈도 순으로 정렬되어 있습니다.

1. 서버에서 역방향 DNS 조회 비활성화

역방향 DNS는 내부 네트워크에서 느린 SSH 로그인의 전형적인 원인입니다. 서버가 TCP 연결을 수락한 다음 연결된 클라이언트 IP 주소를 호스트 이름으로 확인하려고 시도합니다. 역방향 DNS가 없거나, 잘못 구성되었거나, 느린 리졸버가 처리하는 경우 로그인이 몇 초 동안 일시 중지될 수 있습니다.

이것은 서버 측 설정입니다. /etc/ssh/sshd_config에 다음 줄을 추가하거나 업데이트하세요:

UseDNS no

그런 다음 SSH를 테스트하고 다시 로드하세요:

sudo sshd -t
sudo systemctl reload sshd

일부 배포판에서는 서비스 이름으로 ssh를 사용합니다:

sudo systemctl reload ssh

기존 세션을 열어두고 새 로그인을 테스트하세요. 새 로그인이 빠르면 지연을 찾은 것입니다. 변경 사항이 없으면 환경에 맞다면 설정을 그대로 두되 계속 문제를 해결하세요.

2. Kerberos를 사용하지 않는 경우 GSSAPI 비활성화

GSSAPI는 Kerberos 기반 환경에서 유용합니다. 이러한 환경 외부에서는 불필요한 인증 시도를 추가할 수 있습니다. 증상은 일반적으로 공개 키 인증이 계속되기 전에 연결 설정 중 일시 중지가 발생하는 것입니다.

로컬 ~/.ssh/config에 다음을 설정하세요:

Host *
    GSSAPIAuthentication no

지연이 하나의 서버에서만 발생하는 경우 해당 호스트로 설정을 범위를 지정하세요:

Host legacy-admin
    HostName legacy-admin.example.com
    User admin
    GSSAPIAuthentication no

ssh -vvv legacy-admin을 실행하고 전후를 비교하세요. 클라이언트가 GSSAPI를 건너뛰고 공개 키 또는 암호 인증으로 직접 이동하는 것을 볼 수 있습니다.

3. 잘못된 키 제공 중단

SSH 에이전트에 많은 키가 있는 경우 클라이언트는 서버가 수락하는 키에 도달하기 전에 여러 ID를 제공할 수 있습니다. 이는 필요한 것보다 느리며 일부 서버는 너무 많은 실패한 제공 후 로그인을 거부합니다.

자세한 출력에서 이를 명확히 볼 수 있습니다:

debug1: Offering public key: /Users/me/.ssh/id_personal
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/me/.ssh/id_old_vendor
debug1: Authentications that can continue: publickey
debug1: Offering public key: /Users/me/.ssh/id_prod

올바른 ID를 고정하세요:

Host prod-api
    HostName 203.0.113.20
    User deploy
    IdentityFile ~/.ssh/id_ed25519_prod
    IdentitiesOnly yes

IdentitiesOnly yes가 중요합니다. 이것이 없으면 클라이언트는 구성된 파일 전이나 함께 에이전트 키를 계속 제공할 수 있습니다.

에이전트가 로드한 내용을 확인할 수도 있습니다:

ssh-add -l

목록이 지저분하면 에이전트에서 오래된 키를 제거하고 현재 작업에 필요한 키만 추가하세요:

ssh-add -D
ssh-add ~/.ssh/id_ed25519_prod

4. 도움이 되는 경우에만 압축 사용

압축은 보편적인 속도 스위치가 아닙니다. 대역폭이 제한된 링크와 데이터가 압축 가능한 경우(예: 느린 VPN을 통한 긴 텍스트 로그) 도움이 될 수 있습니다. 빠른 네트워크에서는 양쪽 모두가 압축 및 압축 해제에 CPU를 소비하기 때문에 오히려 해가 될 수 있습니다.

좁은 범위에서 사용하세요:

Host distant-bastion
    HostName bastion.example.net
    User ops
    Compression yes

일상적인 연결에 도움이 된다고 측정하지 않는 한 전역적으로 활성화하지 마세요. 일반적인 클라우드-노트북 SSH의 경우 기본값이 더 나은 경우가 많습니다.

입력이 느린 경우 압축이 첫 번째 수정 방법인 경우는 드뭅니다. 네트워크 경로를 테스트하세요:

ping server.example.com
mtr server.example.com

높은 지연 시간이나 패킷 손실이 보이면 SSH 구성으로 할 수 있는 일은 한계가 있습니다. 더 가까운 배스천을 통해 이동하거나, VPN 경로를 수정하거나, 운영자에게 더 가까운 리전을 사용하세요.

5. 다중화로 연결 재사용

첫 번째 SSH 연결이 몇 초 걸리지만 모든 새 터미널 탭이 그 비용을 반복하는 경우 연결 다중화가 깔끔한 해결책입니다. SSH는 하나의 제어 연결을 열어두고 동일한 사용자, 호스트 및 포트에 대한 이후 세션에 재사용합니다.

~/.ssh/config에 다음을 추가하세요:

Host *
    ControlMaster auto
    ControlPath ~/.ssh/controlmasters/%r@%h:%p
    ControlPersist 10m

소켓 디렉토리를 생성하세요:

mkdir -p ~/.ssh/controlmasters
chmod 700 ~/.ssh/controlmasters

첫 번째 연결은 여전히 일반적인 핸드셰이크 및 인증 비용을 지불합니다. 다음 연결은 거의 즉각적으로 느껴져야 합니다.

네트워크 변경 후 다중화된 연결이 멈춘 경우 마스터 소켓을 닫으세요:

ssh -O exit [email protected]

또는 ~/.ssh/controlmasters에서 일치하는 소켓을 제거하세요.

SSH를 비난하기 전에 셸 시작 확인

이것은 놓치기 쉽습니다. SSH가 빠르게 인증한 다음 셸 시작 파일이 프롬프트가 나타나기 전에 몇 초를 소모할 수 있습니다.

다음을 비교하세요:

time ssh [email protected] true
time ssh [email protected] 'bash --noprofile --norc -i -c exit'

그런 다음 .bashrc, .bash_profile, .profile, .zshrc 및 이들이 소싱하는 모든 것을 검사하세요. 일반적인 속도 저하에는 대규모 디렉토리에서 Git 명령을 실행하는 프롬프트 테마, 원격 API를 쿼리하는 kubectl 또는 클라우드 CLI 완성, 패키지 관리자 초기화, 차단된 NFS 홈 디렉토리, 로그인 중 내부 서비스를 호출하는 스크립트가 포함됩니다.

가장 빠른 SSH 수정은 실제로 볼 수 있는 일시 중지와 일치하는 것입니다. -vvv를 사용하고, 한 번에 하나씩 변경하고, 현재 세션을 열어둔 상태에서 두 번째 터미널에서 테스트하세요.