SSH 키 관리 실수로 서버 잠긴 경험과 실전 해결법 공유

저도 처음엔 SSH 키 관리 같은 거 별거 아니라고 생각했는데, 이걸 직접 세팅하다가 서버 접속이 통째로 막혀버렸어요. 이 부분에서 한참 고생했고, 나중에 보니 저뿐만 아니라 여러 사람들도 비슷한 실수로 난감해한다는 걸 알게 됐거든요.

이번 글에서는 제가 겪은 SSH 키 관리 실수 사례와 그 해결법, 그리고 다른 분들의 경험이나 유명한 상품 별 SSH 키 관리 특성까지 비교해서 최대한 꼼꼼히 정리해봤어요.

개발 환경 / 버전 정보

제가 주로 사용하는 서버는 Ubuntu 22.04 LTS에 OpenSSH 8.9p1가 설치되어 있는 환경입니다. 로컬 환경은 주로 macOS Monterey에서 작업했고, 클라우드는 AWS EC2 인스턴스와 DigitalOcean Droplet 두 군데를 비교하며 사용했어요.

SSH 키 관리 실수해서 서버 잠갔던 경험 관련 정보

SSH 키 관리 이렇게 하면 됩니다

사실 이 부분이 막히면 서버 접속이 완전히 불가능해져서 긴장하게 되는데요, 제가 직접 겪은 절차를 중심으로 알려드릴게요.

# 새 SSH 키 쌍 생성(기존키 덮어쓰기 피하기 위해 별도 이름 부여)
ssh-keygen -t ed25519 -f ~/.ssh/my_custom_key -C "your_email@example.com"

# 공개키 내용 확인
cat ~/.ssh/my_custom_key.pub

# 서버에 공개키 추가 (remoteuser는 서버 사용자명, server_ip는 서버 주소)
echo "$(cat ~/.ssh/my_custom_key.pub)" | ssh remoteuser@server_ip 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

# 권한 설정 확인
ssh remoteuser@server_ip 'chmod 700 ~/.ssh && chmod 600 ~/.ssh/authorized_keys'

# 접속 테스트
ssh -i ~/.ssh/my_custom_key remoteuser@server_ip

이렇게 하면 서버에 내 키가 등록되어 안전하게 접속할 수 있는데, 여기서 많이들 실수하는 게 authorized_keys 파일 덮어쓰기나 권한 설정 문제더라고요.

또한, 저는 실수로 기존 키 파일을 덮어썼다가 접속 불가 상태가 되어버려서, 후에 복구할 때 별도의 콘솔 접근(예: AWS 세션 매니저) 없이는 정말 난감했어요.

SSH 키 관리 실수해서 서버 잠갔던 경험 관련 정보

여기서 삽질했던 부분들

가장 크게 문제 됐던 게, 공개키 추가할 때 기존 authorized_keys 내용을 덮어써서 이전 키가 전부 사라진 거였어요. 아래처럼 명령어 한 줄 잘못 써서 그런 경우가 많더라고요.

# 잘못된 예시: 기존 키 덮어쓰기
cat ~/.ssh/my_custom_key.pub | ssh remoteuser@server_ip 'cat > ~/.ssh/authorized_keys'

이게 보통 하려고 하는 건 공개키를 authorized_keys에 추가하는 거지만, 위 명령어는 기존 파일을 통째로 덮어쓰게 됩니다. 그래서 기존 키들을 모두 잃고 접속이 막힌 거죠.

저는 이걸 깨닫고 나서 너무 당황해서 수십 분간 AWS 세션매니저로 서버에 직접 들어가서 키를 다시 등록했는데, 만약 세션매니저 같은 게 없다면 복구 자체가 거의 불가능해요. 그래서 SSH 키 관리는 정말 조심해야 합니다.

SSH 키 관리 실수해서 서버 잠갔던 경험 관련 정보

다른 사람들 사례와 상품별 SSH 키 관리 차이

그런데 저만 이런 실수 하는 건 아니더라고요. 커뮤니티마다 많이들 하는 실수랑, 클라우드 상품별로 SSH 키 관리 특성이 좀 달라서 간단히 정리해봤어요.

클라우드 / 상품	SSH 키 등록 방식	복구 편의성	특이점 / 주의사항
AWS EC2	인스턴스 생성 시 키페어 지정, 나중에 직접 authorized_keys 편집 필요	SSM 세션매니저로 콘솔 접근 가능해 복구 용이	기존 키 덮어쓰기 주의, SSM 미설정 시 복구 어려움
DigitalOcean Droplet	마이 계정 내 SSH 키를 등록 후 인스턴스에 자동 추가	콘솔에서 복구 가능하나 SSH 키 접근 못하면 제한적	키 관리 간편하지만 직접 권한 조작 필요할 때 주의 필요
GCP Compute Engine	메타데이터 서버에서 SSH 키 관리, 자동 배포	메타데이터 조작으로 키 쉽게 추가/삭제 가능	잘못된 메타데이터 키 등록 시 접속 불가 가능성 존재

위 표를 보면 AWS는 SSM 콘솔 접근이 복구 키 역할을 해서 편리한 반면, DigitalOcean은 그런 게 없어서 키 잃어버리면 쥐약이에요. GCP는 메타데이터로 한번에 키 관리 가능한 점이 장점입니다.

심화: SSH 키 관리 자동화 팁

나는 앞으로 이런 실수를 피하기 위해 SSH 키 관리를 자동화해보려고 하는데, Ansible 스크립트로 authorized_keys 자동 관리하는 게 꽤 괜찮더라고요.

- name: Add SSH public key to authorized_keys
  authorized_key:
    user: "{{ ansible_user }}"
    state: present
    key: "{{ lookup('file', '~/.ssh/my_custom_key.pub') }}"

이렇게 하면 키를 여러 서버에 한꺼번에 등록하거나 제거할 때 실수 확률이 확 줄어요. 직접 한 번 써보니까 확실히 편했습니다.

자주 물어보시는 것들

Q. 기존 authorized_keys에 새 키 추가하는 안전한 방법은?

A. 기존 파일에 덮어쓰기 대신 꼭 아래처럼 >> 연산자로 내용을 추가해야 합니다.
cat ~/.ssh/my_custom_key.pub | ssh remoteuser@server_ip 'cat >> ~/.ssh/authorized_keys'

Q. 키 파일 권한은 어떻게 설정해야 안전한가요?

A. 서버에선 ~/.ssh 디렉터리 권한은 700, authorized_keys 파일은 600으로 설정해야 SSH가 허용합니다.

Q. SSH 키 분실 시 복구 방법은?

A. 콘솔 접근 가능한 클라우드 서비스는 콘솔로 로그인 후 키 재등록이 가능하며, 그렇지 않으면 백업된 키 없이는 서버 접속이 어렵습니다.

이번 경험 덕분에 SSH 키 관리는 단순히 키 하나 생성하는 작업이 아니라, 백업 체계와 복구 계획까지 같이 세워야 하는 중요한 인프라 관리 과정임을 확실히 느꼈어요. 앞으로는 꼭 자동화 도구도 같이 쓰면서 신중히 관리하려 합니다.

📌 함께 보면 좋은 글

• Linux 명령어, 인프라 초보도 매일 쓰는 실무 필수 정리법
• 2026년 Linux 메모리 부족 원인 추적하면서 알게 된 변화와 팁
• 2026년 바뀐 점까지 반영한 Linux cron job 실수하기 쉬운 부분들