ssh 키 생성하기 정리: ssh-keygen부터 서버 등록까지

ssh 키 생성하기는 ssh-keygen 명령으로 끝나는 단순한 작업이지만, 어떤 알고리즘을 고르고 공개키를 어디에 두느냐에 따라 이후 운영 편의성이 크게 달라집니다. 결론부터 말씀드리면 새로 만드는 키는 ed25519로 생성하고, 개인키는 passphrase로 보호한 뒤 ssh-agent에 등록하며, 서버에는 공개키만 authorized_keys로 배포하는 구성이 가장 무난합니다. 이 글은 그 흐름을 명령 단위로 정리하고, 배포 자동화나 다중 계정처럼 상황이 달라질 때 무엇을 바꿔야 하는지까지 함께 다룹니다.

한눈에 보기

ssh 키 인증은 "개인키는 내 쪽에, 공개키는 서버에"라는 규칙 위에서 동작합니다. 접속을 시도하면 서버가 공개키로 만든 문제를 보내고, 클라이언트가 개인키로 서명해 응답하는 방식으로 신원이 확인됩니다. 그래서 서버에는 절대 개인키를 두지 않고 공개키만 등록합니다.

아래 표는 실제 작업 순서와 각 단계에서 확인할 명령을 정리한 것입니다. 처음 키를 만드는 경우에도 이 순서를 그대로 따라가면 헤매지 않습니다.

작업	명령	확인할 점
기존 키 확인	`ls -l ~/.ssh`	같은 이름의 키가 있으면 덮어쓰지 않도록 파일명을 따로 지정합니다
키 쌍 생성	`ssh-keygen -t ed25519 -C "메모"`	저장 경로와 passphrase를 대화형으로 묻습니다
권한 정리	`chmod 600 ~/.ssh/id_ed25519`	개인키는 소유자만 읽을 수 있어야 합니다
공개키 배포	`ssh-copy-id 사용자@호스트`	수동으로 붙여 넣어도 결과는 같습니다
에이전트 등록	`ssh-add ~/.ssh/id_ed25519`	세션이 바뀌면 다시 등록해야 합니다
접속 검증	`ssh -v 사용자@호스트`	어떤 키를 제시했는지 로그에서 확인합니다

키 알고리즘 비교 표

ssh-keygen은 여러 알고리즘을 지원하며, 이 선택이 이후 호환성과 운영 부담을 좌우합니다. 새로 만드는 키라면 ed25519를 먼저 고려하시고, 상대 시스템이 이를 지원하지 않을 때 RSA로 내려가는 순서가 안전합니다.

항목	ed25519	RSA	ECDSA
키 길이	짧음	김	중간
서명 처리	빠름	상대적으로 느림	빠름
구현 성숙도	최신 OpenSSH 계열에서 기본	오래 검증됨	곡선 파라미터에 의존
호환성	최근 OpenSSH와 주요 Git 호스팅	매우 넓음	대체로 넓음
권장 상황	새로 만드는 기본 키	오래된 장비·레거시 연동	ed25519를 쓸 수 없는 환경

DSA는 새로 만들 이유가 없는 알고리즘이므로 선택지에서 제외하시면 됩니다. RSA는 오래된 장비나 라이브러리와 연동할 때 여전히 필요하지만, 안전한 강도를 확보하려면 키 길이를 넉넉히 잡아야 하므로 생성 시간과 파일 크기가 늘어납니다. 최근 OpenSSH 릴리스에서는 ed25519가 기본 알고리즘이 되었으므로, 별도 옵션 없이 생성해도 무난한 경우가 많습니다.

단계별로 ssh 키 생성하기

기존 키가 있는지 먼저 확인합니다

~/.ssh 디렉터리에 이미 id_ed25519나 id_rsa가 있는지 확인합니다. 기존 키를 덮어쓰면 그 키를 등록해 둔 서버와 저장소에서 모두 접근이 끊기므로, 새로 만드는 경우에는 -f 옵션으로 파일명을 분리하는 편이 안전합니다.

ls -l ~/.ssh

키 쌍을 생성합니다

가장 일반적인 생성 명령은 다음과 같습니다. -t는 알고리즘, -C는 키 끝에 붙는 주석으로 보통 사용자와 호스트를 적어 두면 나중에 키를 구분하기 쉽습니다.

ssh-keygen -t ed25519 -C "dev@ops-bastion"

실행하면 저장 경로를 묻고, 이어서 passphrase를 입력받습니다.

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/dev/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):

경로를 그대로 승인하면 개인키 id_ed25519와 공개키 id_ed25519.pub가 한 쌍으로 만들어집니다. 확장자가 붙은 쪽이 공개키이고, 이것만 서버로 보내면 됩니다.

passphrase를 설정합니다

passphrase는 개인키 파일 자체를 암호로 감싸는 장치입니다. 파일이 유출되더라도 곧바로 사용할 수 없게 만드는 최소한의 안전장치이므로, 사람이 직접 쓰는 키에는 설정하시는 것을 권합니다. 자동화용 키처럼 무인 실행이 필요한 경우에는 빈 passphrase를 쓰고 파일 권한과 네트워크 접근 제어로 보완하는 방식을 택하기도 합니다.

권한을 정리합니다

OpenSSH는 개인키 파일이 다른 사용자에게 열려 있으면 접속을 거부합니다. 디렉터리와 파일 권한을 함께 정리해 두면 이후 권한 문제로 시간을 쓰지 않습니다.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519
chmod 644 ~/.ssh/id_ed25519.pub

서버 쪽에서는 홈 디렉터리와 authorized_keys 권한도 함께 확인해야 합니다. StrictModes가 켜져 있으면 홈 디렉터리가 다른 사용자에게 쓰기 가능한 상태일 때 공개키 인증이 거부됩니다.

지문을 확인합니다

키를 서버나 저장소에 등록하기 전에 지문을 확인해 두면, 나중에 화면에 표시되는 값과 대조하기 좋습니다.

ssh-keygen -lf ~/.ssh/id_ed25519.pub

공개키 등록과 ssh-agent 설정

ssh-copy-id로 간단히 등록합니다

원격 서버에 아직 접속 수단이 남아 있다면 ssh-copy-id가 가장 빠릅니다. 공개키를 읽어 서버의 authorized_keys에 추가하고 권한까지 맞춰 줍니다.

ssh-copy-id -i ~/.ssh/id_ed25519.pub 사용자@호스트

수동으로 등록합니다

배포 스크립트나 최초 구성 단계에서는 공개키 내용을 직접 붙여 넣는 방식이 더 명확할 때가 있습니다. 공개키는 한 줄짜리 텍스트이므로, 그대로 authorized_keys 끝에 추가하면 됩니다.

cat ~/.ssh/id_ed25519.pub | ssh 사용자@호스트 'mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys'

ssh-agent에 개인키를 등록합니다

passphrase를 설정했다면 접속할 때마다 입력해야 하는데, ssh-agent를 쓰면 세션 동안 입력을 한 번으로 줄일 수 있습니다.

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l

macOS에서는 키체인 연동 옵션을 함께 쓰는 경우가 많고, 원격 개발 환경에서는 에이전트 포워딩을 쓰기도 합니다. 다만 에이전트 포워딩은 접속한 서버에서 내 키를 사용할 수 있게 하는 기능이므로, 신뢰할 수 있는 서버에만 켜는 것이 안전합니다.

접속을 검증합니다

설정이 끝났다면 실제 접속으로 확인합니다. -v를 붙이면 어떤 키를 제시했고 인증이 어떻게 진행됐는지 로그로 확인할 수 있습니다.

ssh -v 사용자@호스트

상황별 선택: 배포 자동화, 다중 계정, 컨테이너

상황에 따라 키를 나누는 기준이 달라집니다. 아래 내용은 같은 공개키를 계속 재사용할지, 용도별로 분리할지 판단할 때 참고하시면 됩니다.

상황	권장 구성	이유
CI·배포 자동화	저장소별 deploy key, 읽기 전용 권한	유출 시 영향 범위를 해당 저장소로 좁힐 수 있습니다
개인 계정과 운영 계정 혼용	`~/.ssh/config`에 Host별 키 지정	계정마다 다른 키를 자동으로 선택합니다
여러 서버 접속	같은 공개키 재사용 + 지문 목록 관리	배포는 편하지만 교체 계획은 필요합니다
컨테이너·임시 환경	호스트 키 검증 정책을 명시	검증을 끄는 옵션은 범위를 한정해 사용합니다

~/.ssh/config에 Host 블록을 두면 계정별 키를 명확히 분리할 수 있습니다.

Host ops-bastion
    HostName 10.0.0.10
    User deploy
    IdentityFile ~/.ssh/id_ed25519_ops
    IdentitiesOnly yes

IdentitiesOnly yes를 지정하면 에이전트에 올라간 다른 키를 함께 제시하지 않으므로, 인증 시도 횟수 제한이 있는 서버에서 특히 유용합니다.

주의할 점

개인키는 절대 서버나 저장소에 올리지 않습니다. 공개키와 개인키는 파일명이 비슷해서 실수로 커밋하기 쉬우므로, 저장소에 .ssh 관련 파일이 포함되지 않도록 확인하는 습관이 필요합니다.

passphrase를 명령행 인자로 넘기는 방식은 셸 히스토리와 프로세스 목록에 남을 수 있습니다. 자동화에서 passphrase를 다뤄야 한다면 시크릿 저장소에서 읽어 표준 입력으로 전달하는 편이 안전합니다.

서버의 호스트 키가 바뀌면 접속 시 경고가 뜹니다. 서버를 재설치한 뒤라면 ssh-keygen -R 호스트로 이전 기록을 지우고 다시 받으면 되지만, 이유를 확인하지 않고 경고를 무시하는 습관은 중간자 공격을 놓치는 원인이 됩니다.

키는 한 번 만들고 끝이 아니라 교체 대상입니다. 담당자별로 키를 분리하고, 퇴사나 역할 변경 시 해당 공개키를 authorized_keys에서 제거하며, 지문 목록을 문서로 관리해 두면 교체 시점에 혼란이 줄어듭니다.

자주 묻는 질문

ssh 키 생성하기에서 passphrase는 꼭 설정해야 하나요?

사람이 직접 사용하는 키라면 설정하시는 것을 권합니다. 개인키 파일이 유출됐을 때 passphrase가 없으면 곧바로 악용될 수 있기 때문입니다. 무인 배포처럼 자동 입력이 필요한 경우에는 빈 passphrase를 쓰고 파일 권한과 접근 제어로 보완하는 방식을 선택합니다.

기존 키를 덮어써도 되나요?

덮어쓰면 그 키를 등록해 둔 서버와 저장소에서 모두 인증이 실패합니다. 새 키가 필요하다면 -f 옵션으로 다른 파일명을 지정하고, 새 공개키를 등록한 뒤 기존 키를 제거하는 순서로 진행하시면 됩니다.

Permission denied (publickey)가 뜨면 무엇을 확인해야 하나요?

서버의 authorized_keys에 공개키가 정확히 들어 있는지, 홈 디렉터리와 .ssh 권한이 적절한지 먼저 확인합니다. 그다음 ssh -v로 클라이언트가 어떤 키를 제시했는지 보고, ~/.ssh/config의 IdentityFile 지정이 의도한 키를 가리키는지 점검하시면 원인을 좁힐 수 있습니다.

같은 키를 여러 서버에 사용해도 괜찮나요?

편의성은 좋지만 키 하나가 유출되면 영향 범위가 넓어집니다. 개인 개발 환경과 운영 환경 정도는 분리하고, 배포 자동화에는 저장소별 키를 두는 식으로 용도에 따라 나누는 편이 관리하기 쉽습니다.

ed25519를 지원하지 않는 서버에는 어떻게 해야 하나요?

해당 서버가 지원하는 알고리즘으로 키를 따로 만들어 등록하시면 됩니다. 이때는 RSA를 선택하고 키 길이를 넉넉히 지정하며, 해당 키는 레거시 연동 전용으로 표시해 두면 나중에 교체 대상으로 관리하기 좋습니다.

출처

OpenSSH ssh-keygen 매뉴얼: https://man.openbsd.org/ssh-keygen
OpenSSH 공식 매뉴얼 목록: https://www.openssh.com/manual.html
GitHub Docs, 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 접속 설정과 ~/.ssh/config 활용법, systemd로 서비스를 올리고 재시작하는 절차, 무중단 배포 구성을 다룬 운영 글도 함께 읽어 보시면 좋습니다.