Ubuntu VPS에서 SSH 연결 오류를 진단하는 방법

작동하는 세션을 유지하고 실패 한 번 기록하기

이미 연결된 SSH 세션은 닫지 말고 제공업체의 복구 콘솔을 확보하세요. 클라이언트 명령은 컴퓨터의 Linux·macOS·WSL 터미널에서, 서버 명령은 기존 연결이나 인증된 복구 콘솔에서 실행합니다. 두 환경을 혼동하지 마세요.

문서용 203.0.113.10, 사용자 ubuntu, 포트 22와 개인 키 경로를 실제 값으로 바꿉니다. 먼저 적용된 클라이언트 설정을 출력한 뒤 새 연결을 한 번 시도하세요.

ssh -G -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10
ssh -v -S none -o ConnectTimeout=10 -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

hostname, user, port, identityfile과 프록시 설정을 확인합니다. 두 번째 명령은 이번 시도에서 연결 공유를 끕니다. 시각과 최종 오류를 기록하고 새 호스트 키 질문은 아래 신원 확인 절차로 검증하세요. 디버그 출력 공유 전 주소·사용자·경로를 가리고 개인 키는 보내지 않습니다.

메시지로 점검 경로 선택하기

표를 가로로 움직이면 나머지 열을 볼 수 있습니다.

메시지는 범위를 좁히는 단서이지 원인 하나의 증명은 아닙니다. 시간 초과 전에 이미 Connection established가 나왔다면 모든 패킷이 차단됐다고 가정하지 말고 SSH 핸드셰이크와 서버 로그를 확인하세요.

시간 초과라면 실제 네트워크 경로 확인하기

ssh -v에 나온 목적지를 제공업체 패널의 현재 주소와 비교하세요. 호스트명을 쓴다면 오래된 DNS나 다른 IPv6 목적지로 가는지 확인합니다. 이 서버가 공인 주소, VPN 또는 점프 호스트를 요구하는지도 검토하세요.

인스턴스가 실행 중인지, 공개 라우팅과 실제 SSH 포트가 맞는지 확인합니다. 컴퓨터 공인 주소는 바뀌었는데 /32 허용 규칙은 그대로일 수 있습니다. 게스트 방화벽도 콘솔에서 확인하세요.

OCI에서는 보안 목록, NSG, 경로와 게스트 방화벽을 모두 봐야 합니다. 원래 이미지 규칙을 유지하고 진단 목적으로 UFW를 설치하거나 iptables를 비우지 않습니다. Oracle 네트워크 설정을 참고하세요. ping 실패만으로 SSH도 안 된다고 판단할 수는 없습니다.

연결 거부라면 수신 서비스 확인하기

연결 거부가 왔다고 그 서버가 의도한 VPS임이 인증되는 것은 아닙니다. 신원과 포트를 확인한 뒤 기존 연결 또는 복구 콘솔의 서버에서 읽기 전용 점검을 실행하세요.

systemctl status ssh.service ssh.socket --no-pager
sudo ss -lntp
sudo /usr/sbin/sshd -t
sudo journalctl -u ssh.service -u ssh.socket --since '15 minutes ago' --no-pager

실제 주소·포트의 수신 상태와 시도 시각의 로그를 대조합니다. Ubuntu는 소켓 활성화를 사용할 수 있으므로 ssh.socket이 수신 중이라면 ssh.service의 비활성 표시만으로 장애를 판정하면 안 됩니다.

sshd -t는 데몬을 시작하지 않고 설정과 호스트 키 유효성을 검사합니다. 출력 없이 성공해도 네트워크 접근성은 별개입니다. 오류가 있다면 해당 파일·설정을 찾은 뒤 적용 여부를 판단하고 무작정 재시작하지 마세요.

공개 키 인증 실패라면 계정과 제시한 키 비교하기

사용자 이름을 추측하지 말고 제공업체 초기 계정 또는 생성한 관리자를 사용하세요. 클라이언트 로그에서 실제 제시한 키 지문을 찾습니다. 에이전트의 불필요한 키 제시를 줄이려면 컴퓨터에서 다음과 같이 재시도합니다.

ssh -v -S none -o IdentitiesOnly=yes -o StrictHostKeyChecking=ask -p 22 -i ~/.ssh/ubuntu_vps ubuntu@203.0.113.10

설정된 IdentityFile 항목은 계속 적용될 수 있으므로 ssh -G를 확인하세요. 키 읽기 실패나 과도하게 열린 개인 키 권한은 서버를 바꾸기 전에 로컬 파일에서 해결합니다.

서버에서 대상 계정과 허용 공개 키를 검사합니다. 아래 /home/ubuntu는 예시이며 getent가 반환한 실제 홈으로 바꿉니다.

getent passwd ubuntu
sudo ls -ld /home/ubuntu /home/ubuntu/.ssh /home/ubuntu/.ssh/authorized_keys
sudo ssh-keygen -lf /home/ubuntu/.ssh/authorized_keys

허용된 지문과 클라이언트가 제시한 지문을 비교하고 소유권, 권한, 계정 정책 오류를 로그에서 찾으세요. 기본 경로가 아니라면 AuthorizedKeysFile, Include 조각과 Match 규칙을 확인합니다. 제공업체의 키 관리 서비스도 방식에 영향을 줄 수 있습니다. 기존 키를 보존하며 원인을 숨기려고 StrictModes를 끄거나 비밀번호 인증을 켜지 않습니다.

호스트 키가 바뀌었다면 신원부터 검증하기

재구축이나 IP 재할당으로 키가 바뀔 수 있지만 잘못된 접속 대상이나 중간자 개입 가능성도 있습니다. 인증된 패널에서 인스턴스 식별자와 예정된 재구축을 확인하세요.

신뢰하는 게스트 콘솔에서 클라이언트에 표시된 알고리즘의 공개 호스트 키를 검사합니다. Ed25519 예시는 다음과 같습니다.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

SHA256 지문을 경고와 비교하세요. 이는 서버 키이며 로그인 키나 제공업체 콘솔 게이트웨이 키가 아닙니다. 정당한 교체를 확인했다면 저장 파일을 백업하고 해당 서버 항목만 갱신하세요. known_hosts 전체 삭제나 검증 우회는 하지 않습니다. 신원이 설명되지 않으면 연결을 멈춥니다.

확인된 원인을 수정하고 새 연결로 검증하기

확인한 주소, 사용자, 키, 좁은 네트워크 규칙 또는 설정 오류만 수정하세요. 서버 변경 중 독립적인 접근 경로를 유지하고 적용 전에 SSH 설정을 검사합니다. 포트 변경은 서비스 재시작 외에 소켓 활성화 설정도 관련될 수 있습니다.

연결 공유를 끈 원래 시도를 반복하고 새 로그인이 예상 계정으로 들어가는지, 필요한 sudo가 작동하는지 확인합니다. 기존 세션 유지와는 다른 검사입니다. 실패 원인과 변경 내용을 기록한 뒤 배포 절차를 계속하세요.