- Published on
ssh 키 생성 명령어 기초 정리
- Authors
- Name
- Indo Yoon
ssh 키 생성 명령어는 결국 ssh-keygen 하나로 정리됩니다. 터미널에서 키 종류를 지정해 실행하고 저장 경로와 암호를 입력하면 공개키와 개인키가 만들어져요. 이 글은 서버 운영과 배포를 담당하는 백엔드 개발자를 기준으로 생성부터 등록, 권한 점검까지 순서대로 정리했어요.
한눈에 보기
ssh-keygen은 OpenSSH에 함께 들어 있는 도구라서 별도 설치 없이 대부분의 리눅스 배포판과 macOS에서 바로 실행할 수 있어요. 윈도우에서는 OpenSSH 클라이언트 기능을 켜거나 별도 클라이언트를 사용해요.
전체 흐름은 단순해요. 키 종류를 정하고, 저장 경로와 암호를 입력하고, 생성된 공개키를 서버의 authorized_keys에 넣고, 마지막으로 실제 접속을 확인해요. 이 순서만 지켜도 대부분의 배포 환경에서 문제없이 키 인증을 구성할 수 있어요.
- 생성:
ssh-keygen -t ed25519 -C "메모" - 기본 저장 위치: 사용자 홈 디렉터리 아래
.ssh - 공개키 배포:
ssh-copy-id또는authorized_keys직접 편집 - 권한 정리: 개인키는 소유자만 읽을 수 있게 제한
- 검증:
ssh -i 개인키경로 사용자@호스트로 접속 테스트
여기서 가장 중요한 원칙은 역할 구분이에요. 공개키는 서버에 등록해서 배포해도 되지만, 개인키는 절대 외부로 나가면 안 돼요. 배포 스크립트나 저장소에 개인키가 들어가는 사고가 가장 흔한 실수예요.
키 종류와 옵션 비교
먼저 키 종류를 비교해 볼게요. 새로 만드는 키라면 ed25519를 기본으로 생각하고, 상대 시스템이 지원하지 않을 때만 다른 종류를 검토하는 흐름이 일반적이에요.
| 키 종류 | 특징 | 이런 경우에 적합 |
|---|---|---|
| ed25519 | 키 길이가 짧고 최근 OpenSSH에서 널리 지원돼요 | 신규 서버 접속, 배포용 키 |
| rsa | 오래된 시스템과의 호환 범위가 넓어요 | 레거시 장비, 오래된 라이브러리 연동 |
| ecdsa | 타원곡선 기반이며 일부 환경에서 사용돼요 | ed25519를 지원하지 않는 상대 시스템 |
| dsa | 현재는 권장되지 않아요 | 신규 사용은 피하는 편이 좋아요 |
다음은 자주 쓰는 옵션이에요. 옵션 이름만 익혀 두면 스크립트에서도 그대로 활용할 수 있어요.
| 옵션 | 의미 | 사용 예 |
|---|---|---|
-t | 키 종류를 지정해요 | -t ed25519 |
-b | 키의 비트 수를 지정해요 | RSA처럼 길이를 조정할 때 |
-C | 키 끝에 붙는 주석을 추가해요 | -C "deploy-key" |
-f | 저장할 파일 경로를 지정해요 | -f ~/.ssh/deploy_key |
-N | 암호를 프롬프트 없이 전달해요 | 자동화 스크립트에서 사용 |
-p | 기존 키의 암호를 변경해요 | -p -f ~/.ssh/id_ed25519 |
-N은 편하지만 암호를 명령 기록이나 스크립트 파일에 남길 수 있다는 점을 기억해야 해요. 자동화에 꼭 필요할 때만 쓰고, 가능하면 별도 키와 제한된 권한을 함께 두는 편이 안전해요.
단계별로 키 만드는 방법
키 종류를 정하고 명령 실행
새 키를 만든다고 가정하고 ed25519로 시작해 볼게요. 주석은 나중에 어떤 키인지 구분하는 데 쓰이므로 노트북 이름이나 용도를 적어 두면 좋아요.
ssh-keygen -t ed25519 -C "work-laptop"
여러 대상을 관리한다면 처음부터 파일명을 구분하는 편이 편해요. 예를 들어 배포용은 deploy_key, 개인 작업용은 id_ed25519_work처럼 역할이 드러나게 만들 수 있어요.
저장 경로와 암호 입력
명령을 실행하면 저장 경로를 묻는 프롬프트가 나와요. 그냥 Enter를 누르면 기본 경로에 저장되고, 직접 입력하면 지정한 경로에 만들어져요.
이어서 암호를 두 번 입력하게 돼요. 암호를 비워 둘 수도 있지만, 개인키 파일이 유출됐을 때를 생각하면 설정하는 쪽이 안전해요. 암호를 설정하면 접속할 때마다 입력해야 하므로, 반복 접속이 많은 환경에서는 ssh-agent에 등록해 두고 사용해요.
권한 확인
생성 직후에는 파일 권한을 확인해요. 개인키는 소유자만 읽고 쓸 수 있어야 하고, 공개키는 다른 사용자가 읽어도 문제없어요.
- 개인키:
chmod 600 ~/.ssh/deploy_key - 공개키:
chmod 644 ~/.ssh/deploy_key.pub - 디렉터리:
chmod 700 ~/.ssh
권한이 느슨하면 SSH 클라이언트가 개인키 사용을 거부하는 경우가 있어요. 접속이 갑자기 안 된다면 키 내용보다 권한과 소유자를 먼저 확인하는 편이 빠를 때가 많아요.
공개키를 서버에 등록
공개키를 서버에 올리는 가장 간단한 방법은 ssh-copy-id예요. 아직 비밀번호 인증이 열려 있는 서버라면 이 명령으로 공개키를 바로 등록할 수 있어요.
ssh-copy-id -i ~/.ssh/deploy_key.pub 사용자@호스트
ssh-copy-id를 쓸 수 없는 환경이라면 공개키 내용을 직접 붙여 넣어요. 서버에 접속한 뒤 ~/.ssh/authorized_keys 파일을 열고 공개키 한 줄을 추가하면 돼요. 이때 파일과 디렉터리 권한, 소유자가 접속 사용자로 맞는지도 함께 확인해요.
접속 테스트와 설정 정리
등록이 끝났으면 개인키를 지정해 접속해 봐요.
ssh -i ~/.ssh/deploy_key 사용자@호스트
자주 접속하는 서버라면 ~/.ssh/config에 Host 항목을 만들어 두는 편이 편해요. HostName, User, IdentityFile을 적어 두면 이후에는 ssh 별칭 형태로 접속할 수 있어요. 배포 스크립트에서도 같은 설정을 재사용할 수 있어 관리가 쉬워져요.
상황별 선택 기준
같은 ssh-keygen이라도 상황에 따라 설정이 달라져요.
- 신규 서버 접속: ed25519로 만들고 암호를 설정한 뒤
ssh-agent를 함께 사용해요. - 배포 자동화: 서버별로 전용 키를 만들고,
authorized_keys에서 실행 가능한 명령이나 접속 출발지를 제한해요. - 여러 서버 관리: 서버마다 키를 새로 만들기보다
~/.ssh/config와ssh-agent로 키를 구분해 운용해요. - 키 교체: 새 키를 먼저 등록하고 접속을 확인한 다음 기존 키를 제거하는 순서로 진행해요.
- 외주 인력이나 임시 접근: 목적이 드러나는 주석을 달고, 작업이 끝나면 해당 줄을 바로 삭제해요.
자동화용 키는 사람이 쓰는 키와 분리하는 것이 핵심이에요. 한 키가 여러 서버와 여러 파이프라인에 걸쳐 있으면, 유출 시 영향 범위를 가늠하기 어려워지고 교체도 복잡해져요.
주의할 점
키 관리에서 사고는 대부분 생성 단계가 아니라 보관과 배포 단계에서 생겨요.
- 개인키는 저장소에 커밋하지 않아요.
.gitignore에.ssh관련 경로와 키 파일명을 미리 넣어 두는 편이 좋아요. - 공개키만 서버에 등록해요.
.pub가 붙은 파일이 공개키이고, 붙지 않은 파일이 개인키예요. - 암호 없는 키는 자동화에만 쓰고, 서버 쪽에서 권한을 좁혀 두어요.
known_hosts에 저장된 호스트 키가 바뀌면 경고가 나와요. 서버 교체가 예정된 작업이라면 미리 안내하고, 경고를 습관적으로 무시하지 않아요.- 서버를 폐기하거나 사용자를 정리할 때
authorized_keys에 남은 키도 함께 정리해요. - 개인키는 안전한 곳에 백업하되, 백업본에도 암호를 설정해 두어요.
운영 중인 서버라면 키를 새로 만드는 일보다 기존 키를 정리하는 일이 더 자주 생겨요. 접속 계정별로 어떤 키가 등록되어 있는지 주기적으로 확인하는 습관이 도움이 돼요.
자주 묻는 질문
ssh 키는 어디에 저장되나요?
기본 경로는 사용자 홈 디렉터리 아래 .ssh이고, -f 옵션으로 다른 경로를 지정할 수 있어요. 경로를 따로 지정하지 않으면 키 종류에 따라 기본 파일명이 제안돼요. 여러 키를 사용한다면 파일명만 봐도 용도를 알 수 있게 만들어 두는 편이 관리하기 쉬워요.
암호는 꼭 설정해야 하나요?
필수는 아니지만 설정을 권장해요. 개인키 파일이 유출되더라도 암호를 모르면 바로 사용할 수 없기 때문이에요. 자동화용 키라면 암호를 두지 않는 대신 서버에서 실행 명령과 접속 출발지를 제한하는 방식으로 위험을 줄여요.
기존 키가 있는데 새로 만들면 덮어써지나요?
같은 경로를 입력하면 덮어쓸지 묻는 프롬프트가 나오고, 여기서 잘못 응답하면 기존 키가 사라질 수 있어요. 새 키는 다른 파일명으로 만들고, 서버 등록과 접속 확인이 끝난 뒤에 기존 키를 정리하는 순서가 안전해요.
공개키와 개인키를 바꿔 등록하면 어떻게 되나요?
인증이 되지 않아요. 서버에는 항상 .pub로 끝나는 공개키 내용을 등록하고, 접속할 때는 개인키를 사용해야 해요. 파일이 헷갈린다면 ssh-keygen -y -f 개인키경로로 공개키 내용을 다시 출력해 확인할 수 있어요.
출처
- OpenSSH 매뉴얼: https://www.openssh.com/manual.html
- ssh-keygen 매뉴얼 페이지: https://man.openbsd.org/ssh-keygen
- GitHub 공식 문서, SSH 키 생성 및 ssh-agent 등록: https://docs.github.com/en/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent
관련 운영 글도 함께 보면 좋아요. SSH 접속이 안 될 때 확인하는 순서, authorized_keys 권한과 소유자 점검, 배포 서버에서 ssh-agent 활용하기, 서버 접속 계정 정리 체크리스트를 함께 읽으면 키 생성 이후의 운영 흐름까지 이어서 정리할 수 있어요.