형원블로그

본 문서는 SSH 키 생성 및 공개키 인증 설정 방법을 정리한 실무형 매뉴얼입니다. 서버를 운영하거나 GitHub, GitLab, 배포 서버, 백업 서버 등에 접속할 때 매번 비밀번호를 입력하는 방식 대신 SSH 키 기반 인증을 사용하면 보안성과 편의성을 함께 높일 수 있습니다.

SSH 키 인증은 로컬 서버 또는 개인 PC에 개인키(private key)를 보관하고, 접속 대상 서버에는 공개키(public key)를 등록하는 방식입니다. 서버는 공개키를 통해 접속 요청을 검증하지만, 개인키 자체는 서버로 전송되지 않습니다. 따라서 비밀번호 인증보다 자동화와 보안 관리에 유리합니다.

1. SSH 키 인증 구조 이해하기

SSH 키는 항상 한 쌍으로 생성됩니다. 하나는 개인키이고, 다른 하나는 공개키입니다. 이름 그대로 개인키는 절대 외부에 노출되면 안 되고, 공개키는 접속을 허용할 서버에 등록하는 용도로 사용합니다.

개인키: 접속을 시도하는 클라이언트 쪽에 보관합니다. 예: ~/.ssh/id_ed25519, ~/.ssh/manuz_ed25519
공개키: 접속 대상 서버의 ~/.ssh/authorized_keys 파일에 등록합니다. 예: ~/.ssh/id_ed25519.pub

핵심은 개인키는 접속하는 쪽에만 있어야 한다는 점입니다. 원격 서버에 개인키를 복사하는 방식은 특별한 목적이 없는 한 피해야 합니다. 특히 운영 서버에 여러 서버 접속용 개인키를 모아두면, 해당 서버가 침해되었을 때 다른 서버까지 연쇄적으로 노출될 수 있습니다.

2. RSA와 Ed25519 중 어떤 키를 사용할까?

SSH 키를 만들 때는 여러 알고리즘을 선택할 수 있습니다. 과거에는 RSA 키를 많이 사용했지만, 최근에는 Ed25519 키를 우선 사용하는 것이 일반적입니다.

Ed25519: 키 길이가 짧고 성능이 좋으며 보안성도 충분합니다. 최신 서버와 클라이언트 환경에서는 우선 권장됩니다.
RSA 4096: 오래된 시스템과의 호환성이 좋습니다. 구형 서버, 장비, 일부 오래된 솔루션과 연동해야 할 때 사용할 수 있습니다.

신규 서버와 일반적인 Linux 서버 접속 용도라면 Ed25519를 먼저 사용하고, 호환성 문제가 있을 때 RSA 4096 키를 추가로 생성하는 방식이 좋습니다.

3. SSH 키 생성하기

먼저 Ed25519 키를 생성합니다. -C 옵션에는 키를 식별하기 위한 코멘트를 넣습니다. 보통 사용자명, 프로젝트명, 서버명, 이메일 등을 넣습니다.

ssh-keygen -t ed25519 -C manuz -f ~/.ssh/manuz_ed25519

RSA 키가 필요한 경우에는 아래와 같이 4096 bit로 생성합니다.

ssh-keygen -t rsa -b 4096 -C manuz -f ~/.ssh/manuz_rsa

옵션의 의미는 다음과 같습니다.

-t: 생성할 키 타입입니다. 예: ed25519, rsa
-b: 키의 비트 수입니다. RSA에서 주로 사용하며, 일반적으로 4096을 사용합니다.
-C: 키에 붙일 코멘트입니다. 대문자 옵션이므로 -c와 혼동하지 않아야 합니다.
-f: 생성할 키 파일 경로입니다. 여러 키를 관리할 때는 기본 파일명보다 목적이 드러나는 이름을 사용하는 것이 좋습니다.

4. 키 저장 위치와 파일명

-f 옵션을 지정하지 않으면 아래와 같이 기본 저장 위치를 묻습니다.

Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa):

기본값으로 생성하면 RSA는 ~/.ssh/id_rsa, Ed25519는 ~/.ssh/id_ed25519 형태로 저장됩니다. 단일 키만 사용할 경우 기본 파일명도 괜찮지만, 실무에서는 프로젝트나 서버별로 키를 분리하는 경우가 많기 때문에 다음처럼 이름을 명확히 주는 것이 관리에 유리합니다.

~/.ssh/company_github_ed25519
~/.ssh/project_deploy_ed25519
~/.ssh/customer_server_rsa
~/.ssh/manuz_ed25519

키가 생성되면 개인키와 공개키가 함께 만들어집니다.

ls -al ~/.ssh

-rw------- 1 user user  411 Jul  3 10:20 manuz_ed25519
-rw-r--r-- 1 user user  100 Jul  3 10:20 manuz_ed25519.pub

여기서 .pub가 붙은 파일이 공개키입니다. 공개키는 서버에 등록해도 되지만, .pub가 없는 개인키 파일은 절대 공유하면 안 됩니다.

5. Passphrase 설정 여부

키 생성 중에는 passphrase 입력을 요구합니다.

Enter passphrase (empty for no passphrase):
Enter same passphrase again:

passphrase는 개인키 파일을 한 번 더 보호하는 암호입니다. 개인키 파일이 외부로 유출되더라도 passphrase를 모르면 바로 사용할 수 없게 해줍니다.

개인 PC에서 직접 접속하는 용도: passphrase를 설정하는 것이 좋습니다.
자동 배포, 백업, CI/CD 용도: 무인 실행이 필요하므로 passphrase 없이 생성하는 경우가 많습니다. 대신 권한과 사용 범위를 강하게 제한해야 합니다.

비밀번호 없이 자동 접속이 필요하다는 이유만으로 모든 키를 passphrase 없이 만들면 위험합니다. 자동화용 키는 해당 작업에 필요한 서버와 계정에만 접근 가능하도록 제한하고, 가능하면 일반 사용자 계정으로만 접속하게 구성하는 것이 좋습니다.

6. 공개키 확인하기

생성된 공개키는 cat 명령으로 확인할 수 있습니다.

cat ~/.ssh/manuz_ed25519.pub

출력은 대략 아래와 같은 형태입니다.

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx manuz

RSA 공개키라면 다음과 같은 형태입니다.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx manuz

이 공개키 전체 문자열을 접속 대상 서버의 authorized_keys 파일에 등록합니다. 줄바꿈이 중간에 들어가면 인증이 실패할 수 있으므로 한 줄 전체를 그대로 복사해야 합니다.

7. 원격 서버에 공개키 등록하기

접속 대상 서버의 사용자 계정 홈 디렉터리에 .ssh 디렉터리와 authorized_keys 파일을 생성합니다. 예를 들어 원격 서버의 deploy 계정으로 접속하려면, 원격 서버에서 deploy 사용자 기준으로 아래 작업을 수행해야 합니다.

mkdir -p ~/.ssh
touch ~/.ssh/authorized_keys
chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

이후 authorized_keys 파일을 열어 공개키를 붙여넣습니다.

vi ~/.ssh/authorized_keys

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx manuz

권한 설정은 매우 중요합니다. ~/.ssh 디렉터리나 authorized_keys 파일 권한이 너무 열려 있으면 SSH 서버가 보안상 해당 파일을 무시할 수 있습니다.

8. ssh-copy-id로 공개키 등록하기

비밀번호 접속이 가능한 상태라면 ssh-copy-id 명령을 사용해 공개키를 쉽게 등록할 수 있습니다.

ssh-copy-id -i ~/.ssh/manuz_ed25519.pub deploy@SERVER_IP

이 명령은 원격 서버의 ~/.ssh/authorized_keys 파일에 공개키를 자동으로 추가합니다. 다만 서버 보안 정책상 비밀번호 로그인이 막혀 있거나, 특정 포트만 허용된 경우에는 수동 등록이 필요할 수 있습니다.

SSH 포트가 22번이 아닌 경우에는 다음과 같이 포트를 지정합니다.

ssh-copy-id -i ~/.ssh/manuz_ed25519.pub -p 2222 deploy@SERVER_IP

9. 생성한 키로 SSH 접속하기

기본 키 파일명이 아닌 경우에는 -i 옵션으로 개인키 경로를 지정해서 접속합니다.

ssh -i ~/.ssh/manuz_ed25519 deploy@SERVER_IP

SSH 포트가 다른 경우에는 -p 옵션을 함께 사용합니다.

ssh -i ~/.ssh/manuz_ed25519 -p 2222 deploy@SERVER_IP

접속이 정상적으로 되면 이후부터는 비밀번호 대신 개인키 인증을 통해 서버에 접속할 수 있습니다.

10. SSH config 파일로 접속 정보 관리하기

서버가 많아지면 매번 ssh -i 옵션과 포트를 입력하기 번거롭습니다. 이때는 로컬 PC의 ~/.ssh/config 파일을 사용하면 됩니다.

vi ~/.ssh/config

Host my-server
    HostName SERVER_IP
    User deploy
    Port 2222
    IdentityFile ~/.ssh/manuz_ed25519
    IdentitiesOnly yes

이제 아래처럼 간단히 접속할 수 있습니다.

ssh my-server

IdentitiesOnly yes는 지정한 키만 사용하도록 하는 옵션입니다. 여러 SSH 키를 사용하는 환경에서는 이 옵션을 넣어두는 것이 좋습니다. 그렇지 않으면 SSH 클라이언트가 여러 키를 순서대로 시도하다가 서버의 인증 시도 제한에 걸릴 수 있습니다.

11. ssh-agent에 키 등록하기

passphrase가 있는 키를 사용할 때 매번 암호를 입력하지 않으려면 ssh-agent에 키를 등록할 수 있습니다.

ssh-add ~/.ssh/manuz_ed25519

등록된 키 목록은 아래 명령으로 확인합니다.

ssh-add -l

특정 키를 제거하려면 다음과 같이 실행합니다.

ssh-add -d ~/.ssh/manuz_ed25519

등록된 모든 키를 제거하려면 아래 명령을 사용합니다.

ssh-add -D

ssh-agent는 개인 PC에서 여러 서버에 자주 접속할 때 유용합니다. 다만 공용 PC나 다른 사람이 접근 가능한 환경에서는 agent에 키를 장시간 유지하지 않는 것이 좋습니다.

12. 개인키 파일 권한 설정

개인키 파일 권한이 너무 넓게 설정되어 있으면 SSH 클라이언트가 키 사용을 거부할 수 있습니다. 일반적으로 개인키는 소유자만 읽고 쓸 수 있도록 600 권한을 설정합니다.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/manuz_ed25519
chmod 644 ~/.ssh/manuz_ed25519.pub
chmod 600 ~/.ssh/config

원격 서버의 authorized_keys도 동일하게 권한을 엄격하게 유지해야 합니다.

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys

13. 서버 보안을 위한 sshd 설정

공개키 인증이 정상적으로 동작한다면 서버의 SSH 보안 설정을 강화할 수 있습니다. 설정 파일은 일반적으로 /etc/ssh/sshd_config입니다.

vi /etc/ssh/sshd_config

대표적으로 검토할 설정은 다음과 같습니다.

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin no
AuthorizedKeysFile .ssh/authorized_keys

PubkeyAuthentication yes: 공개키 인증을 허용합니다.
PasswordAuthentication no: 비밀번호 로그인을 비활성화합니다. 공개키 접속이 확실히 되는 것을 확인한 뒤 적용해야 합니다.
PermitRootLogin no: root 계정 직접 접속을 차단합니다. 일반 사용자로 접속한 뒤 필요한 경우 sudo를 사용하는 방식이 안전합니다.

설정을 변경한 뒤에는 sshd 설정 문법을 확인합니다.

sshd -t

문제가 없다면 서비스를 재시작합니다.

systemctl restart sshd

중요한 점은 현재 접속 중인 SSH 세션을 끊지 않은 상태에서 새 터미널로 접속 테스트를 먼저 해야 한다는 것입니다. 설정을 잘못 적용하면 서버에 다시 접속하지 못할 수 있습니다.

14. authorized_keys에 옵션 추가하기

자동 배포나 백업용 키는 접속 범위를 제한하는 것이 좋습니다. authorized_keys 파일에서는 공개키 앞에 여러 옵션을 붙일 수 있습니다.

from="203.0.113.10",no-agent-forwarding,no-X11-forwarding,no-port-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBxxxxxxxx manuz

위 설정은 특정 IP에서만 접속을 허용하고, agent forwarding, X11 forwarding, port forwarding을 비활성화합니다. CI/CD 서버나 백업 서버처럼 접속 출발지가 고정되어 있는 경우 유용합니다.

특정 명령만 실행되도록 제한할 수도 있습니다.

command="/usr/local/bin/deploy.sh",no-agent-forwarding,no-X11-forwarding,no-port-forwarding ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIBxxxxxxxx deploy-key

이 방식은 배포 전용 키, 백업 전용 키처럼 용도가 명확한 키를 만들 때 보안상 유리합니다. 단, 설정이 잘못되면 정상 접속이 막힐 수 있으므로 운영 적용 전 테스트 서버에서 먼저 검증하는 것이 좋습니다.

15. 키 관리 노하우

개인키는 절대 공유하지 않습니다. 다른 사람이나 서버에 전달해야 하는 것은 공개키입니다.
용도별로 키를 분리합니다. 개인 접속용, GitHub용, 배포용, 백업용 키를 하나로 쓰지 않는 것이 좋습니다.
퇴사자 또는 외주 작업자 키는 즉시 제거합니다. authorized_keys에서 해당 공개키를 삭제하면 됩니다.
root 직접 접속은 피합니다. 일반 계정으로 접속한 뒤 sudo를 사용하는 구조가 안전합니다.
자동화 키는 권한을 최소화합니다. 배포용 계정은 배포 디렉터리와 필요한 명령에만 접근할 수 있게 구성합니다.
키 파일명에 용도를 남깁니다. 시간이 지나도 어떤 키인지 알 수 있도록 project_deploy_ed25519처럼 이름을 정합니다.

16. 접속이 안 될 때 확인할 항목

공개키를 등록했는데도 접속이 되지 않는 경우에는 아래 항목을 순서대로 확인합니다.

공개키가 한 줄로 정확히 들어갔는지 확인: 중간 줄바꿈이나 누락이 있으면 실패합니다.
원격 서버의 사용자 계정이 맞는지 확인: root에 등록한 키로 deploy 계정에 접속할 수 없습니다.
권한 확인: ~/.ssh는 700, authorized_keys는 600이 적절합니다.
개인키 지정 여부 확인: 기본 키가 아니라면 -i 옵션이나 ~/.ssh/config 설정이 필요합니다.
sshd 설정 확인: PubkeyAuthentication yes가 설정되어 있는지 확인합니다.

디버깅이 필요하면 -v 옵션을 붙여 접속 과정을 확인할 수 있습니다.

ssh -v -i ~/.ssh/manuz_ed25519 deploy@SERVER_IP

더 자세한 로그가 필요하면 -vvv까지 사용할 수 있습니다.

ssh -vvv -i ~/.ssh/manuz_ed25519 deploy@SERVER_IP

17. 마무리

SSH 키 인증은 서버 운영에서 가장 기본적이면서도 중요한 보안 설정입니다. 비밀번호 인증만 사용하는 서버는 무차별 대입 공격에 노출되기 쉽고, 자동 배포나 백업 같은 운영 자동화에도 적합하지 않습니다.

실무에서는 Ed25519 키를 기본으로 사용하고, 필요한 경우 RSA 4096 키를 추가로 생성하는 방식을 권장합니다. 또한 개인키는 절대 공유하지 않고, 공개키만 원격 서버에 등록해야 합니다. 자동화용 키는 용도별로 분리하고, IP 제한이나 명령 제한을 함께 적용하면 보안성을 더 높일 수 있습니다.

SSH 키는 한 번 만들어두면 오래 사용하는 경우가 많기 때문에, 처음부터 파일명, 권한, 계정, 접속 범위를 체계적으로 관리하는 것이 중요합니다. 작은 서버라도 키 관리 원칙을 잡아두면 이후 서버가 늘어나거나 배포 자동화가 추가될 때 훨씬 안정적으로 운영할 수 있습니다.

SSH 키 생성 및 공개키 인증 설정 방법 - 서버 보안을 위한 실무 가이드

Usefull Links

Question?