SSH 키 관리 실수로 서버 잠겼을 때 비용 차이와 해결법 직접 경험담

서버 관리하다가 SSH 키 관리 실수로 접속 불가 상황에 빠져본 적, 저만 그런 게 아니더라고요. 사실 이걸 구현하다가 생각보다 삽질을 많이 했어요. 특히 클라우드 환경에서 비용 차이가 얼마나 나는지 직접 겪으면서 체감했거든요.

이 글에서는 제가 SSH 키를 잘못 관리해서 서버 접속이 막혔던 경험과, 그 문제를 해결하는 과정에서 드는 비용 차이도 구체적으로 비교해봤어요. 그리고 명령어와 설정값까지 넣어두었으니, 비슷한 상황 겪는 분들은 이 글 하나면 걱정 없을 거예요.

개발 환경 / 버전 정보

제가 사용한 서버는 Ubuntu 22.04 LTS이고, 클라우드는 AWS EC2 t3a.micro 인스턴스를 사용했습니다. SSH 클라이언트는 OpenSSH 9.3 버전입니다.

SSH 키 관리 실수로 서버 잠긴 과정과 문제 원인

사실 이 부분이 제일 아찔했는데요, 저는 로컬 머신에서 SSH 키를 재생성하면서 기존 키를 덮어씌웠어요. 이를 서버에 등록된 공개키와 맞춰서 업데이트하지 않아서, 당연히 키 인증에 실패해 서버 접속 자체가 안 됐죠.

기존 SSH 키는 id_rsa와 id_rsa.pub였고, 서버의 ~/.ssh/authorized_keys에 등록되어 있었어요. 그런데 로컬에서 다음 명령어를 쳤습니다.

ssh-keygen -t rsa -b 4096 -f ~/.ssh/id_rsa

이러다 보니 기존에 서버에 등록돼 있던 공개키와 완전히 달라진 SSH 키가 생겨났죠. 서버 접속 시도하면 이렇게 나옵니다.

Permission denied (publickey).

이때부터 서버 접속을 완전히 못 했어요. 보통은 다른 키를 써서 다시 등록하면 되는데, 저는 키 파일 자체를 덮어씌워버려서 기존 인증키 정보를 잃은 상태였거든요.

비용 차이 확인하면서 문제 해결법 찾기

그런데 여기서 막힌 게 문제가 아니라, 문제를 해결하려다 비용이 얼마 차이 나는지도 생각보다 컸습니다. 제가 쓰던 t3a.micro 인스턴스는 시간당 0.0104달러였는데, 접속 불가 문제를 해결하려다 임시로 더 비싼 인스턴스를 잠시 띄우고, 전문가에게 SSH 복구 작업을 맡겼거든요.

일단 상황별 비용 비교부터 보여드릴게요.

상황	시간당 비용(USD)	추가 비용(USD)	비고
기존 t3a.micro 인스턴스	0.0104	-	기본 운영 비용
문제 해결용 t3.large 인스턴스 임시 생성	0.0832	0.0728	1시간 운영 기준
전문가 SSH 복구 서비스	-	≈50.00	1회성 비용

여기서 보시면, 만약 처음부터 조금 더 신중하게 SSH 키를 관리했다면 임시 인스턴스 비용 0.0728달러와 고액의 전문가 비용 50달러를 절약할 수 있던 셈이죠.

SSH 키 문제 해결법 실제 명령어와 과정

이때 저는 결국 다음 방식으로 문제를 극복했습니다. 제가 SSH 키를 다시 서버에 등록할 수 없으니, 클라우드 콘솔의 'EC2 인스턴스 접근' 기능을 이용해 임시 키를 생성하고, 이를 통해 서버에 접근했어요.

# AWS Systems Manager (SSM) 세션 매니저 설치 및 확인
aws ssm start-session --target i-xxxxxxxxxxxxxxx --region ap-northeast-2

# 임시 복구를 위해 루트로 들어간 후
sudo su -

# 새 SSH 공개키 생성 후 등록
mkdir -p ~/.ssh
chmod 700 ~/.ssh

# 로컬에서 새로 생성한 공개키 내용을 authorized_keys에 추가
echo "ssh-rsa AAAAB3... user@local" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

# SSH 데몬 재시작 (필요 시)
sudo systemctl restart sshd

이렇게 하니 바로 접속이 가능해졌고, 기존의 덮어씌운 키 문제를 해결할 수 있었어요.

여기서 막혔던 부분과 삽질 포인트

그런데 여기서 많이들 헷갈려하시는 게, authorized_keys 파일 권한 문제였어요. 권한이 600보다 느슨하면 SSH 데몬이 인증을 거부하거든요. 한참 에러 로그를 뒤져보면서

Authentication refused: bad ownership or modes for directory /home/ubuntu/.ssh

이 에러가 왜 나는지 한참 찾았는데, 결국 권한을

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

이렇게 고치니까 해결됐어요.

심화: 비용 절감 팁과 SSH 키 관리 노하우

제가 하면서 느낀 건데, SSH 키 관리가 미흡하면 인프라 비용이 생각보다 크게 늘어날 수 있어요. 그래서 저는 다음과 같은 습관을 들였어요.

• 키 생성 시 백업부터 꼭 해두기 (클라우드 저장 혹은 안전한 USB)
• 주기적으로 ssh-add -l로 현재 로컬 키 리스트 확인
• 서버 authorized_keys는 수동 변경 최소화, 변경 시 반드시 SSM 같은 우회 방법 확보
• 중요 인스턴스는 IAM 역할 및 SSM 세션 매니저 활성화해, SSH 접속 막혀도 접근 가능하도록 하기

이렇게 해두면 비용도 안 들고, 불필요한 고가 복구 서비스를 안 써도 돼서 돈 절약에 꽤 도움이 됐어요.

자주 물어보시는 것들

Q. SSH 키 덮어씌우면 무조건 복구 어렵나요?

A. 원격 서버에 다른 접근 경로(콘솔, SSM, 데이터베이스 등)가 있으면 복구가 가능해요. 만약 이런 게 전혀 없다면 복구가 어렵고 비용도 올라가니 예방이 중요해요.

Q. AWS EC2 인스턴스 중 어떤 타입이 SSH 복구에 적합한가요?

A. t3a.micro 같은 저가형을 운영용으로 쓰고, 복구용은 t3.large 이상 정도로 잠깐 쓰는 게 비용과 성능 면에서 균형이 맞아요.

Q. authorized_keys 권한 설정은 꼭 이렇게 해야 하나요?

A. 네, SSH 데몬은 보안 때문에 권한이 너무 넓으면 접속을 거부합니다. 반드시 700과 600 권한 설정을 지키셔야 해요.

이런 부분들 신경 안 쓰면 시간이 지날수록 비용 누적도 커지고, 예상치 못한 다운타임으로 인한 손해도 커지니까요.

제가 직접 SSH 키 관리 실수로 서버 잠갔던 경험을 공유하면서, 비용 차이가 이렇게 실질적으로 벌어질 수 있다는 걸 알게 됐어요. 만약 여러분도 키 관리 때문에 막혀 있다면, 위 과정과 팁 참고하시면 좋을 것 같아요.