[GCP - ssh] Compute Engine SSH 접속 실패 원인과 해결 – 콘솔 SSH로 직접 고친 방법 (Product : SpeakNote)

SSH 키 등록했는데 로컬에서 접속이 안 됐던 문제 (해결까지 한 번에 정리)

Compute Engine 인스턴스를 생성하면서
초기 설정 화면에서 SSH 공개키를 분명히 등록했습니다.

하지만 인스턴스 생성 이후, 로컬 터미널에서 다음과 같이 접속을 시도했을 때

ssh user@<외부 IP>

SSH 접속이 정상적으로 이루어지지 않았습니다.

즉,

• VM 생성 단계에서 SSH 키를 넣었음
• GCP 콘솔에서는 인스턴스가 정상적으로 떠 있음
• 그런데 로컬 터미널에서는 SSH 접속 실패

라는 상황이었습니다.

---

당시 문제 상황 정리

이 시점에서 확인했던 사항은 다음과 같습니다.

• VM에는 외부 IP가 정상적으로 할당되어 있었고
• 방화벽에서도 22번 포트는 열려 있는 상태였으며
• SSH 키 자체도 로컬에 정상적으로 존재했습니다

즉, 네트워크나 포트 문제라기보다는 SSH 키 적용 방식 문제로 판단했습니다.

---

원인으로 판단한 부분

GCP에서는 SSH 키를 등록하는 위치가 여러 군데 존재합니다.

• VM 생성 시 입력하는 SSH 키
• 프로젝트 메타데이터(Project-wide SSH keys)
• 인스턴스 메타데이터(Instance-level SSH keys)

이 중에서,

• 생성 단계에서 입력한 SSH 키가 실제 인스턴스에 제대로 반영되지 않았거나
• 프로젝트/인스턴스 메타데이터 적용 우선순위 문제로
• 로컬 SSH 접속 시 인증이 실패한 것으로 보였습니다.

이런 경우에는
“왜 안 되는지 끝까지 파고들기”보다
가장 확실한 방식으로 키를 다시 적용하는 것이 빠르다고 판단했습니다.

---

실제로 사용한 해결 방법 (삽질하다가 해결방법 찾음.. 위에꺼 다 해봐도 안됐음.)

이 문제는 GCP 콘솔에서 제공하는 브라우저 기반 SSH 터미널로 먼저 접속한 뒤,
인스턴스 내부에서 SSH 키를 직접 갱신하는 방식으로 해결했습니다.

진행한 순서는 다음과 같습니다.

1. GCP 콘솔 → Compute Engine → 해당 인스턴스 → [SSH] 버튼 클릭
2. 브라우저 기반 SSH 터미널로 인스턴스에 접속
3. 접속 후, 인스턴스 내부에서 아래와 같은 방식으로
   로컬에서 사용 중인 공개키를 authorized_keys에 직접 추가

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

nano ~/.ssh/authorized_keys

1. 로컬에서 사용 중인 공개키(~/.ssh/id_ed25519.pub 등)의 내용을
   authorized_keys 파일에 그대로 붙여넣기
2. 저장 후 권한 설정

chmod 600 ~/.ssh/authorized_keys

1. 브라우저 SSH 세션 종료 후, 로컬 터미널에서 다시 SSH 접속 시도

ssh user@<외부 IP>

위 과정을 거친 이후,
로컬 터미널에서 SSH 접속이 정상적으로 이루어졌습니다.

 

---

이 방식이 효과적이었던 이유

• VM 생성 단계에서 등록한 SSH 키가
  메타데이터/계정 생성 과정에서 정상 반영되지 않은 상태였고
• 인스턴스 내부의 authorized_keys 파일에는
  실제로 유효한 키가 존재하지 않았던 상황이었습니다

그래서

• GCP 메타데이터를 우회
• 인스턴스 내부 SSH 인증 파일을 직접 수정하여
• SSH 인증 경로를 명확하게 맞춘 것이 핵심이었습니다

---

참고로 정리해두는 포인트

• SSH 접속이 안 될 때
  “키를 어디에 넣었는지”보다
  ~/.ssh/authorized_keys에 실제로 키가 들어가 있는지가 더 중요합니다.
• 브라우저 SSH는 되는데 로컬 SSH가 안 되면
  거의 대부분 이 파일 문제로 귀결됩니다.

---

정리

• Compute Engine 생성 시 SSH 키를 넣었음에도
• 로컬 SSH 접속이 되지 않는 경우가 발생할 수 있음
• 이때는 복잡하게 원인을 모두 추적하기보다는
  • 인스턴스 수정 → SSH 키 직접 등록
    방식이 가장 확실한 해결책이었습니다.

SSH 접속 문제 없이 서버 설정, 포트별 서비스 실행, Load Balancer 설정을
정상적으로 진행할 수 있었습니다.