ssh 키 생성 총정리: ssh-keygen부터 배포까지

ssh 키 생성은 터미널에서 ssh-keygen을 실행해 공개 키와 개인 키 쌍을 만드는 작업이에요. 서버 접속과 배포 자동화에서는 공개 키만 대상 서버나 Git 호스팅에 등록하고, 개인 키는 내 작업 환경에 안전하게 보관해요. 이 글은 Linux 서버 운영과 배포를 하는 백엔드 개발자가 바로 따라 할 수 있도록 생성 절차와 선택 기준을 정리해요.

한눈에 보기

ssh 키 생성의 핵심은 ssh-keygen으로 키 쌍을 만들고, 공개 키만 서버나 Git 호스팅에 등록하는 것이에요. 개인 키는 절대 외부에 공유하지 않고, 파일 권한과 보관 위치를 함께 점검해야 해요.

• 키 쌍 생성: ssh-keygen -t ed25519 -C "용도나 이메일"
• 공개 키 확인: cat ~/.ssh/id_ed25519.pub
• 서버 등록: ssh-copy-id 사용자@서버 또는 ~/.ssh/authorized_keys에 공개 키 추가
• 접속 확인: ssh 사용자@서버
• 배포 자동화: 개인 키를 저장소에 커밋하지 않고 비밀 관리 도구나 ssh-agent를 사용해요
• 권한 점검: ~/.ssh와 개인 키 파일의 접근 권한을 소유자 중심으로 제한해요

비교 표

키 종류는 접속 대상과 조직 표준에 따라 선택해요. 새로 만드는 개발용 키라면 Ed25519를 먼저 검토하고, 오래된 장비나 기존 시스템과 맞춰야 한다면 RSA를 검토하는 흐름이 일반적이에요.

표의 내용은 알고리즘 선택을 돕기 위한 일반적인 기준이에요. 실제 운영 환경에서는 접속 대상 서버와 배포 도구가 지원하는 키 종류를 먼저 확인해요.

단계별 방법

기존 키와 디렉터리 확인

먼저 ~/.ssh 디렉터리에 기존 키가 있는지 확인해요. 기존 키를 덮어쓰면 이전에 등록해 둔 서버 접속과 자동화가 끊길 수 있어요.

ls -al ~/.ssh

기존 키가 보이면 파일 이름과 용도를 확인해요. 새 키가 필요하다면 기존 파일을 덮어쓰지 말고 별도 이름으로 만들어요.

키 쌍 만들기

Ed25519 키를 만들 때는 아래처럼 실행해요. -C에는 키를 구분할 수 있는 설명을 넣어요.

ssh-keygen -t ed25519 -C "devbull deploy"

기존 시스템과의 호환성 때문에 RSA가 필요하면 아래처럼 실행해요. 키 길이를 조정해야 할 때는 -b 옵션을 함께 검토해요.

ssh-keygen -t rsa -C "devbull deploy"

명령을 실행하면 저장 경로와 암호문을 묻는 프롬프트가 나와요. 기본 경로를 쓰려면 Enter를 누르고, 암호문은 보안 정책에 맞게 설정해요. 암호문을 비워 둘 수 있지만, 개인 키 파일이 유출될 때를 대비하려면 설정하는 편이 좋아요.

공개 키 확인

생성된 공개 키는 .pub 확장자가 붙은 파일이에요. 아래 명령으로 내용을 확인할 수 있어요.

cat ~/.ssh/id_ed25519.pub

출력된 내용은 ssh-ed25519 같은 키 유형으로 시작하고, 마지막에는 -C로 넣은 설명이 붙어요. 이 공개 키 내용을 서버나 Git 호스팅에 등록해요.

서버에 공개 키 등록

서버에 공개 키를 등록하는 가장 간단한 방법은 ssh-copy-id를 사용하는 것이에요. 대상 서버에 SSH 접속이 가능한 상태에서 아래처럼 실행해요.

ssh-copy-id 사용자@서버

ssh-copy-id를 사용할 수 없거나 직접 등록해야 한다면 공개 키 내용을 서버 계정의 ~/.ssh/authorized_keys에 추가해요. 이때 기존 authorized_keys 내용을 지우지 않도록 주의해요.

접속 테스트

공개 키를 등록한 뒤에는 새 세션에서 접속을 확인해요.

ssh 사용자@서버

Git 호스팅에 등록한 경우에는 호스팅 서비스가 안내하는 테스트 명령으로 인증을 확인해요. 예를 들어 GitHub에서는 ssh -T git@github.com으로 접속 테스트를 할 수 있어요.

상황별 선택

개발 노트북에서 서버 접속

개인 개발 환경에서는 용도별로 키를 나누는 편이 관리하기 쉬워요. 회사 서버, 개인 서버, Git 호스팅용 키를 같은 파일로 계속 쓰기보다 용도를 구분해 두면 나중에 교체하기도 쉬워요.

배포 자동화와 CI

배포 자동화에서는 개인 키를 저장소에 커밋하지 않아요. CI/CD 도구의 비밀 관리 기능에 개인 키를 저장하고, 배포 대상 서버에는 해당 공개 키만 등록해요. 암호문이 있는 키를 자동화에서 쓸 때는 ssh-agent나 도구가 제공하는 비밀 주입 방식을 함께 검토해요.

여러 서버를 운영할 때

여러 서버에 같은 공개 키를 등록하면 접속은 편하지만, 키 하나가 유출될 때 영향 범위가 넓어져요. 운영 서버와 개발 서버의 키를 나누고, 서버별로 접근 권한을 점검하는 편이 안전해요.

Windows와 WSL

Windows에서도 OpenSSH 클라이언트가 설치되어 있으면 ssh-keygen을 같은 방식으로 사용할 수 있어요. WSL을 쓴다면 Linux 환경과 Windows 환경의 ~/.ssh 경로가 다를 수 있으므로, 실제로 배포 명령을 실행하는 환경의 키를 확인해요.

주의할 점

• 개인 키는 절대 공유하지 않아요. 공개 키만 서버와 Git 호스팅에 등록해요.
• ~/.ssh 디렉터리와 개인 키 파일의 권한을 소유자 중심으로 제한해요. 권한이 느슨하면 SSH 접속이 거부될 수 있어요.
• authorized_keys에는 필요한 공개 키만 남기고, 퇴사자나 폐기한 자동화의 키는 정리해요.
• 암호문을 설정한 키는 ssh-agent에 등록해 두면 반복 입력을 줄일 수 있어요.
• 서버를 교체하거나 IP가 바뀌면 known_hosts의 이전 항목 때문에 경고가 나올 수 있어요. 이때는 호스트 키가 실제로 바뀐 것인지 먼저 확인해요.
• 배포 자동화에 쓰는 키는 주기적으로 교체하고, 키가 노출되었다고 판단되면 즉시 폐기해요.

자주 묻는 질문

ssh 키 생성 후 공개 키는 어디에 등록하나요?

서버에 접속할 때는 대상 계정의 ~/.ssh/authorized_keys에 공개 키를 추가해요. GitHub나 GitLab 같은 호스팅 서비스는 웹 설정의 SSH 키 메뉴에 .pub 파일 내용을 붙여 넣으면 돼요. 개인 키는 등록하지 않아요.

기존 키가 있는데 새로 만들어도 되나요?

기존 키를 덮어쓰면 이전 키로 접속하던 서버와 자동화가 끊길 수 있어요. 새 파일 이름을 지정해 별도 키를 만들고, 필요한 서버에만 새 공개 키를 등록하는 편이 안전해요. 기존 키를 교체할 때는 새 키 접속을 확인한 뒤 이전 키를 정리해요.

암호문은 꼭 설정해야 하나요?

개인 키 파일이 유출될 때를 대비하려면 암호문을 설정하는 편이 좋아요. 다만 배포 자동화에서는 암호문 입력이 어려울 수 있어 ssh-agent나 비밀 관리 도구를 함께 써요. 암호문을 쓰지 않을 때는 파일 권한과 보관 위치를 더 엄격하게 관리해요.

Ed25519와 RSA 중 무엇을 고르면 되나요?

새로 만드는 키이고 접속 대상이 Ed25519를 지원하면 Ed25519를 우선 검토해요. 오래된 장비나 특정 조직 표준 때문에 RSA가 필요하면 RSA를 선택해요. 어느 쪽이든 공개 키만 등록하고 개인 키는 안전하게 보관하는 원칙은 같아요.

권한 오류가 나면 어떻게 확인하나요?

서버의 홈 디렉터리와 ~/.ssh, authorized_keys 권한을 차례로 확인해요. ~/.ssh는 소유자만 접근하도록 하고, authorized_keys도 다른 사용자가 수정하지 못하게 해요. 클라이언트 쪽 개인 키 권한이 느슨해도 접속이 거부될 수 있어요.

출처

• OpenSSH Manual
• OpenBSD ssh-keygen Manual
• GitHub Docs: Generating a new SSH key and adding it to the ssh-agent
• GitLab Docs: Use SSH keys to communicate with GitLab

관련 운영 글: 서버 배포 전 SSH 접속과 권한 점검 체크리스트도 함께 확인해 보세요. 배포 파이프라인에서 키를 다룰 때 점검할 항목을 정리해 두었어요.