ssh-keygen 한 번에 개인키를 날렸을 때 (덮어쓰기 함정과 복구 경로)

옵션 하나를 빼먹어서 유일한 접속 키를 잃은 과정과, 그때 확인해야 할 곳들을 정리한 글입니다.

서버가 비밀번호 로그인을 막아 두어서 공개키를 새로 만들어야 했는데, 아무 생각 없이 ssh-keygen 만 치고 엔터를 눌렀습니다.

기본 저장 경로를 묻길래 그대로 넘겼고, 그 다음에 나온 덮어쓸지 묻는 줄에서 y 를 누른 순간 기존 키가 사라졌습니다.

문제는 그 키가 그 서버에 들어갈 수 있는 유일한 수단이었다는 것이고, 이미 접속해 있던 창 하나만 살아 있는 상태가 됐습니다.

- ssh-keygen 은 -f 를 안 주면 기본 파일을 덮어쓴다

- 덮어쓰기 확인 줄이 유일한 방어선인데 그냥 지나치기 쉽다

- 개인키는 어디에도 자동 백업되지 않는다

- authorized_keys 는 >> 로 붙인다(> 는 기존 키를 전부 지운다)

- 새 키로 접속되는 걸 확인하기 전에 기존 세션을 닫지 않는다

1. 사고는 한 줄에서 난다

ssh-keygen -t ed25519 만 실행하면 저장 위치를 묻는데, 여기서 엔터를 치면 기본 경로가 그대로 쓰입니다.

이미 파일이 있으면 덮어쓸지 한 번 묻고, 그 확인에 y 를 누르면 원본은 그 자리에서 사라집니다.

되돌릴 방법이 없어서 이 한 줄이 사실상 유일한 안전장치인데, 키를 만드는 흐름이 짧다 보니 확인 줄을 그냥 넘기게 됩니다.

2. 어디에도 백업이 없다

키를 잃고 나면 어디선가 남아 있지 않을까 싶어 찾게 되는데, 확인해야 할 곳이 정해져 있습니다.

결론부터 말하면 개인키를 자동으로 복사해 두는 장치는 없어서, 직접 백업하지 않았다면 전부 헛수고입니다.

- .ssh 디렉터리의 예전 사본

- ssh-agent 가 저장한 키(윈도우는 레지스트리, 서비스가 꺼져 있으면 없음)

- WSL 등 다른 환경의 홈 디렉터리

- 클라우드 동기화 폴더

ssh-agent 에 올려 뒀다면 남아 있을 수도 있는데, 서비스가 사용 안 함 상태면 애초에 저장된 적이 없습니다.

3. 살아 있는 세션이 유일한 구명줄이다

키를 잃어도 이미 붙어 있는 접속창은 그대로 동작합니다. 인증은 접속할 때 한 번만 하기 때문입니다.

그래서 그 창에서 새 공개키를 직접 등록하면 되고, 이번에도 그 창 하나로 상황이 풀렸습니다.

반대로 말하면 그 창을 닫는 순간 끝이라, 새 키로 들어가는 걸 확인하기 전에는 절대 닫으면 안 됩니다.

4. 새 키는 반드시 이름을 준다

같은 실수를 반복하지 않으려면 처음부터 -f 로 파일명을 지정하는 습관이 안전합니다.

용도별로 이름을 나눠 두면 기본 파일을 건드릴 일이 없고, 나중에 어떤 키가 어디에 쓰이는지도 알아보기 쉽습니다.

5. 등록할 때 방향을 확인한다

공개키를 서버에 넣을 때 > 와 >> 를 헷갈리면 남의 키까지 날립니다.

> 는 파일을 새로 쓰기 때문에 기존에 등록돼 있던 키가 전부 사라지고, 공용 계정이면 다른 사람도 같이 못 들어오게 됩니다.

권한도 정해져 있어서 디렉터리는 700, 파일은 600 이 아니면 sshd 가 무시합니다.

6. 정리

Permission denied (publickey) 를 보면 서버 설정을 열어 보고 싶어지는데, 대부분은 설정 문제가 아니라 등록된 키가 없는 것뿐입니다.

정리하면 이렇습니다.

- ssh-keygen 은 항상 -f 로 파일명을 준다

- 덮어쓰기 확인 줄에서 한 번 멈춘다

- 개인키는 직접 백업하지 않으면 남지 않는다

- 살아 있는 세션은 확인 전까지 닫지 않는다

- authorized_keys 는 >>, 권한은 700 / 600

키를 잃는 사고 자체는 흔한데 복구 방법이 없다는 게 특징이라, 미리 정해 둔 습관 말고는 대비할 방법이 없습니다.

여기까지 ssh-keygen 덮어쓰기 사고에 대해서 작성해봤습니다. 여기까지 읽어주셔서 감사합니다!