01 · OVERVIEW

개요

로컬 PC에서 기존에 사용하던 SSH 개인키로 OVH VPS에 접속하려 했지만 공개키 인증이 더 이상 통과하지 않았습니다. 서비스는 동작 중이었지만 운영과 배포를 위한 서버 접근이 중단된 상태였습니다.

02 · PROBLEM & IMPACT

문제와 영향

기존에 사용하던 로컬 개인키로 운영 VPS에 로그인할 수 없었습니다. 서버의 서비스 상태를 확인하거나 파일을 올리고 Nginx·Docker 배포를 진행할 관리 경로가 막혔습니다.

ssh ubuntu@server
Permission denied (publickey)
IP, 공개키 원문, 지문은 보안상 공개하지 않습니다. 장애의 핵심은 서비스 중단이 아니라 운영자 접근 중단이었습니다.
03 · SIGNALS

오류 신호를 분리했습니다

인증 실패22번 포트 연결 뒤 publickey 단계에서 거부
다른 키도 실패별도 배포 키 역시 대상 계정에서 승인되지 않음
일시적 타임아웃확인 중에는 TCP 연결 자체가 지연된 시점도 존재

인증 실패와 네트워크 타임아웃은 같은 오류로 묶지 않고 별도의 신호로 취급했습니다.

04 · TIMELINE

진단 타임라인

  1. 기존 계정과 기본 개인키로 접속해 publickey 거부를 확인했습니다.
  2. 전용 배포 키를 명시해 계정·키 선택 문제인지 비교했습니다.
  3. 디버그 접속으로 서버 도달 단계와 인증 단계를 나눠 확인했습니다.
  4. 일반 SSH만으로는 서버 측 등록 상태를 바꿀 수 없어 공급자 콘솔로 전환했습니다.
  5. 키를 재등록한 뒤 동일한 ubuntu 계정으로 다시 접속했습니다.
세션 기록상 인증 거부 확인 후 OVH 콘솔 복구를 거쳐 같은 날 일반 SSH 접속이 성공했습니다.
05 · HYPOTHESIS

가설과 배제 범위

잘못된 계정ubuntu 계정으로 복구 후 성공해 계정 자체는 유효
잘못된 로컬 키 선택여러 키를 명시했지만 모두 거부돼 서버 측 상태 확인 필요
네트워크 차단초기에는 SSH 데몬까지 도달했으므로 인증 실패와 별개
서버 측 키 등록 불일치공개키 재등록 후 같은 계정의 접속이 복구됨
06 · CAUSE RANGE

확정한 것과 확정하지 못한 것

서버에 등록된 공개키와 로컬 개인키의 대응 상태, ubuntu 계정의 authorized_keys, 파일 권한 또는 SSH 접근 제어 범위로 좁혔습니다. 다만 재등록 전 서버 파일의 정확한 차이를 보존하지 못해 단일 원인은 확정하지 않았습니다.

확정: 재등록 전 인증 실패 → OVH 콘솔에서 초기화·재등록 → 재등록 후 동일 계정 접속 성공. 미확정: 기존 항목이 사라졌는지, 잘못된 키였는지, 권한이 달랐는지.
07 · RECOVERY DECISION

복구 경로를 바꿨습니다

일반 SSH는 인증에 성공해야만 서버 측 키를 고칠 수 있으므로 막힌 경로 안에서 반복하지 않았습니다. OVH가 제공하는 웹 콘솔/CMD를 별도의 관리 평면으로 사용했습니다.

  1. OVH 콘솔로 서버에 접속
  2. 기존 SSH 공개키 인증 상태 초기화
  3. 로컬 개인키와 대응하는 공개키를 ubuntu 계정에 재등록
  4. 일반 SSH 경로로 돌아와 재검증
08 · VERIFICATION

로그인만 보고 끝내지 않았습니다

  • ssh ubuntu@server 세션 생성 성공
  • 호스트명 vps-da71b9ff 확인
  • Linux 6.8 x86_64 환경 확인
  • 현재 위치 /home/ubuntu 확인
  • 홈 디렉터리 쓰기 권한 확인
  • 후속 파일 업로드, Nginx 구성, 서비스 배포 작업 진행
09 · RESULT

결과

운영 서버 관리 접근을 복구했고, 중단됐던 배포 작업을 이어갈 수 있었습니다. 인증 성공뿐 아니라 쓰기 작업과 후속 운영 명령까지 통과해 실제 관리 권한이 복구됐음을 확인했습니다.

종료 조건: 일반 SSH 로그인 + 대상 계정 홈 쓰기 + 후속 배포 작업 수행. 세 조건을 모두 확인했습니다.
10 · RUNBOOK

재발 대비 체크리스트

  1. 공급자 콘솔 접근 권한과 복구 경로를 정기 확인합니다.
  2. 서버별 계정·로컬 키 파일·공개키 지문의 대응표를 보관합니다.
  3. 키 교체 전 기존 세션을 유지하고 새 키 접속을 별도 창에서 검증합니다.
  4. ssh -v로 TCP 연결, 호스트 확인, 키 제안, 서버 승인 단계를 구분합니다.
  5. 비밀키 원문은 문서·저장소·포트폴리오에 넣지 않습니다.
11 · RECORD LIMITS

기록하지 못한 부분

OVH 콘솔에서 사용자가 직접 실행한 초기화·재등록 명령과 수정 전 authorized_keys 내용은 Codex 세션에 남아 있지 않습니다. 따라서 명령을 추측해 쓰지 않았고, “공개키 재등록으로 복구됐다”는 검증 가능한 수준까지만 기록했습니다.

추가하면 가장 좋은 자료: 비밀값을 제거한 ssh -vv 로그, 키 지문 전후 비교, 권한 확인 출력, 콘솔 복구 명령의 마스킹된 기록.
12 · LEARNING

배운 점

SSH는 서버 운영의 단일 진입점이 될 수 있으므로 공급자 콘솔 같은 독립적인 복구 경로가 필요합니다. 또한 “접속이 안 된다”를 하나의 오류로 보지 않고 네트워크 도달, 계정 선택, 키 제안, 서버 승인 단계로 나눠야 빠르게 복구할 수 있습니다.