나는 -i 옵션을 줬는데, 왜 다른 SSH 키가 사용됐을까?

1. 문제 상황

EC2 서버에 접속하기 위해 다음과 같이 SSH 명령어를 사용하고 있었다.

ssh -i C:\AWS_Key\qroad_ed25519.pem ubuntu@api.qroad.info

 

나는 분명 -i 옵션으로 특정 키 파일을 지정하고 있었다.
그래서 해당 키로만 인증이 이루어진다고 생각했다.

그런데 어느 날 로컬 .ssh 폴더에 있던 기본 키 파일들을 정리한 후,
갑자기 SSH 접속이 되지 않는 문제가 발생했다.

이상한 점은 명확했다.

나는 -i 옵션으로 다른 키를 지정하고 있었는데,
왜 .ssh 기본 키를 삭제하자 접속이 막힌 걸까?

---

2. 내가 했던 착각

당시 나는 이렇게 생각하고 있었다.

• -i 옵션을 사용하면 지정한 키만 사용된다.
• 따라서 다른 키 파일은 접속과 무관하다.

하지만 이 가정이 틀렸다.

---

3. SSH의 실제 동작 방식

SSH는 생각보다 “자동으로 많은 것을 시도”한다.

기본적으로 SSH는 다음 순서로 키를 시도할 수 있다.

1. ssh-agent에 등록된 키
2. ~/.ssh 디렉토리의 기본 키들 (id_rsa, id_ed25519 등)
3. -i 옵션으로 지정한 키

즉,

-i는 “이 키만 써라”가 아니라
“이 키도 추가로 시도해라”에 가깝다.

실제로 디버그 모드로 확인해보면 다음과 같은 로그를 볼 수 있다.

ssh -v -i C:\AWS_Key\qroad_ed25519.pem ubuntu@api.qroad.info

 

로그에는 다음과 같이 출력된다.

Offering public key: C:\Users\...\.ssh\id_rsa
Offering public key: C:\Users\...\.ssh\id_rsa.pem

 

이 말은, 내가 지정한 키 외에도 다른 키들을 함께 시도하고 있었다는 뜻이다.

결국 나는 다음과 같은 상황에 있었다.

• 서버의 authorized_keys에는 A 키가 등록되어 있었고
• 나는 B 키로 접속한다고 생각했지만
• 실제 인증은 A 키로 성공하고 있었다.

그리고 A 키를 삭제하자 접속이 실패한 것이다.

---

4. 문제 해결 방법

혼란을 정리하기 위해 다음과 같이 조치했다.

1. 새로운 SSH 키 쌍을 생성
2. 서버의 authorized_keys 초기화
3. 새로 생성한 공개키만 등록
4. 해당 키로만 접속 테스트

이 과정을 통해 인증 흐름을 명확하게 정리했다.

이제는:

• 어떤 키가 서버에 등록되어 있는지
• 어떤 키로 접속하는지
• 인증이 어떤 키로 이루어지는지

모두 명확하게 추적 가능한 상태가 되었다.

---

5. 이 경험을 통해 배운 점

이번 경험을 통해 깨달은 점은 단순하다.

“명령어를 알고 있는 것”과
“동작 원리를 이해하는 것”은 다르다.

나는 ssh -i 옵션을 사용하고 있었지만,
SSH 인증 흐름 자체를 정확히 이해하고 있지는 못했다.

운영 환경에서는 특히 다음이 중요하다.

• 어떤 키가 실제로 인증에 사용되는지 명확히 알고 있어야 한다.
• 추측이 아니라 검증 가능한 상태여야 한다.
• 인증 구조는 항상 단순하고 예측 가능해야 한다.

이번 경험은 단순한 접속 오류가 아니라,
SSH 인증 구조를 제대로 이해하게 된 계기였다.

---

마무리

SSH는 단순히 “키 파일을 넣고 접속하는 도구”가 아니다.
내부적으로 여러 인증 시도를 하며 동작하는 프로토콜이다.

이번 경험을 통해 운영 환경에서는 “내가 생각하는 동작”이 아니라
“실제로 어떤 동작이 일어나는지”를 확인하는 습관이 중요하다는 것을 배웠다.