Permission denied (publickey): EC2 SSH 키·사용자·접속 경로 확인

AI Editter

EC2에 접속되지 않을 때 보안 그룹부터 전체 공개로 바꾸면 원인을 놓치고 노출 범위만 넓힐 수 있습니다. 시간 초과, 연결 거부, 공개키 인증 실패는 서로 다른 단계에서 생기는 증상입니다.

먼저 인스턴스 ID·리전·현재 주소·상태를 확인하고 최근 변경을 기록합니다. 인스턴스가 바뀌었거나 주소가 달라진 상황을 서버 내부 장애로 오해하지 않도록 합니다.

publickey 오류와 시간 초과는 다른 단계

Permission denied (publickey)가 보이면 일반적으로 SSH 서버와 인증 단계까지 진행한 상태입니다. 반면 연결 시간 초과는 주소·라우팅·보안 그룹·방화벽 등을 먼저 확인할 문제입니다. 인증 오류에서는 AMI에 맞는 로그인 사용자와 지정한 키가 맞는지 확인하고 ssh -vvv 출력에서 어떤 키를 제시했는지 봅니다. 로그를 공유할 때 사용자·내부 경로·주소 등은 가리며 개인 키 내용은 절대 붙이지 않습니다. 22번을 전체 인터넷에 여는 것은 잘못된 키 문제를 해결하지 않습니다.

오류 메시지에 따라 확인 지점을 나눈다

증상	우선 확인
Connection timed out	경로·보안 그룹·NACL·주소·VPN
Connection refused	대상 포트의 서비스와 OS 방화벽
Permission denied (publickey)	사용자명·키·authorized_keys·권한
Host key changed	대상 교체·주소 재사용·정당한 키 변경 여부
상태 검사 실패	시스템·인스턴스 상태와 부팅 로그

ssh -v의 진단 출력은 연결 단계 확인에 도움이 되지만 사용자명·주소·경로가 포함될 수 있으므로 공유할 때 필요한 부분만 남깁니다. 호스트 키 경고는 자동으로 무시하지 말고 실제 서버의 지문과 변경 이력을 대조합니다.

외부 경로부터 좁혀 본다

퍼블릭 접속이면 현재 퍼블릭 주소, 서브넷 경로, 인터넷 게이트웨이, 소스 IP 허용 범위를 확인합니다. 사설 접속이면 VPN·전용선·배스천 등 실제 경로가 살아 있는지 확인합니다.

보안 그룹과 NACL은 적용 지점과 응답 트래픽 처리 방식이 다릅니다. 같은 이름의 규칙을 봤다는 사실보다 대상 인스턴스의 실제 네트워크 인터페이스에 무엇이 연결돼 있는지 확인합니다. OS 방화벽 변경 이력도 함께 봅니다.

다른 인스턴스에는 접속되지만 이 서버만 실패하는지, 같은 서버가 다른 허용 경로에서는 접속되는지 비교하면 범위를 좁힐 수 있습니다. 진단 때문에 불필요한 전체 인터넷 허용을 추가하지 않습니다.

Session Manager가 준비돼 있다면 OS 내부를 확인

SSM은 SSH 포트를 열지 않고 관리 세션을 제공할 수 있지만 사전 조건이 있습니다. SSM Agent, 인스턴스의 역할과 권한, 서비스 엔드포인트로의 통신, 접속 사용자의 IAM 권한 등이 맞아야 합니다. Session Manager 사전 요구사항을 확인합니다.

관리형 노드로 온라인 표시되는지 확인한 뒤 세션을 시작합니다. 내부에서는 디스크 공간, sshd 상태, 최근 로그, 설정 문법을 읽기 위주로 점검합니다.

df -h
df -i
systemctl status sshd
sudo sshd -t

배포판에 따라 서비스 이름이 ssh일 수 있습니다. sshd -t로 문법을 확인한 뒤 필요한 수정과 재로드를 수행합니다. 기존 정상 관리 세션은 새 SSH 접속이 검증될 때까지 유지하면 복구 경로를 잃을 가능성을 줄일 수 있습니다.

시리얼 콘솔은 네트워크 장애와 다른 경로

네트워크 설정이 망가져 SSM도 접속되지 않는다면 EC2 Serial Console을 검토할 수 있습니다. 다만 지원 인스턴스와 상태, 계정·IAM 설정, OS 로그인·트러블슈팅 구성이 필요합니다. 장애가 난 뒤 버튼이 보인다는 이유만으로 바로 사용할 수 있다고 가정하지 않습니다.

시리얼 콘솔 사전 요구사항에 따라 자신의 환경을 확인합니다. 부팅 로그를 보고 파일 시스템·네트워크·서비스 설정 문제를 구분합니다. 콘솔에 접근할 수 있다는 사실이 OS 관리자 암호나 복구 절차를 대신하지는 않습니다.

볼륨을 다른 인스턴스에 연결하는 복구는 마지막 계획으로

다른 경로가 없고 루트 볼륨을 점검해야 한다면, 원본의 중지와 볼륨 분리·시험 인스턴스 연결이 필요한 방식이 있습니다. 서비스 중단, AZ, 암호화 키, 장치 이름, 파일 시스템 UUID와 연결 위치를 기록해야 합니다.

먼저 복구용 스냅샷과 원래 연결 정보를 확보하고, 실제 대상이 맞는지 확인합니다. 잘못된 볼륨을 연결하거나 마운트된 원본을 임의로 조작하면 장애를 키울 수 있습니다. 배포판과 파일 시스템에 맞는 공식 복구 절차를 사용합니다.

원본을 수정한 뒤에는 부팅뿐 아니라 서비스 데이터와 권한도 확인합니다. 파일 권한 문제를 해결하려고 전체 경로를 광범위하게 재귀 변경하지 않습니다.

복구가 끝나면 새 접속과 업무를 모두 시험

새 SSH 세션, 관리 세션, 앱 상태, 재부팅 후 지속 여부를 확인합니다. 임시로 추가한 네트워크 규칙과 복구 리소스는 기록을 보고 정리합니다.

원인	재발 방지
sshd 설정 오류	문법 검사 후 적용
디스크·inode 부족	사용량·증가율 알림
주소·경로 변경	자산 정보와 접속 경로 갱신
키·사용자 불일치	계정·키 수명 관리
복구 경로 미준비	평상시 SSM·콘솔 시험

다음 장애를 줄이는 가장 실용적인 조치는 정상일 때 대체 접속 경로를 한 번 열어 보는 것입니다. 설정 목록에 존재하는 복구 수단과 실제로 사용할 수 있는 복구 수단은 다를 수 있습니다.