ssh 키 생성 및 등록 정리: 서버 접속 준비 가이드

ssh 키 생성 및 등록은 ssh-keygen으로 키 쌍을 만들고, 공개키만 서버의 authorized_keys에 넣는 두 단계로 끝나요. 비밀키는 내 작업 환경에만 남기고 서버나 저장소로는 절대 복사하지 않는다는 점이 핵심이에요. 아래 순서를 그대로 따라 하면 암호 입력 없이 접속하는 것까지 확인할 수 있어요.

한눈에 보기

ssh 접속용 키는 공개키와 비밀키가 한 쌍으로 만들어져요. 서버는 내가 보낸 공개키를 보고 "이 요청은 비밀키를 가진 사람이 보냈다"는 것을 확인하는 구조예요. 그래서 서버에 올라가는 것은 항상 .pub 확장자가 붙은 공개키이고, 확장자가 없는 파일은 내 쪽에만 있어야 해요.

전체 흐름은 다음과 같아요.

• 키 쌍 생성: ssh-keygen -t ed25519 -C "용도 메모"
• 공개키 확인: cat ~/.ssh/id_ed25519.pub
• 서버 등록: ssh-copy-id user@host 또는 authorized_keys에 직접 추가
• 권한 정리: ~/.ssh는 700, authorized_keys는 600
• 접속 확인: ssh -i ~/.ssh/id_ed25519 user@host

명령 이름이 비슷해서 헷갈리기 쉬운데, ssh-keygen은 키를 만들 때, ssh-copy-id는 공개키를 옮길 때, ssh는 결과를 확인할 때 쓴다고 구분해 두면 정리가 돼요.

키 종류와 용도 비교

새로 만드는 키라면 ed25519를 먼저 고려하는 것이 일반적이에요. 다만 상대 서버나 장비가 오래된 경우에는 RSA를 써야 하는 상황도 있어요. 어느 쪽이든 공개키를 등록하는 절차 자체는 같아요.

키 종류를 바꿔도 서버 쪽 설정 파일에 손댈 일은 거의 없어요. 클라이언트에서 어떤 알고리즘으로 키를 만들지만 다를 뿐이고, 등록과 검증은 같은 경로를 지나요.

단계별 방법

1) 키 쌍 생성하기

가장 단순한 형태는 알고리즘과 메모를 지정하는 명령이에요. -C에 넣는 값은 주석이라서 나중에 어떤 키인지 구분하는 데만 쓰여요. 서버 이름이나 용도를 적어 두면 관리가 편해져요.

ssh-keygen -t ed25519 -C "deploy@was"

실행하면 저장 경로를 묻고, 이어서 passphrase를 입력받아요. 경로를 그대로 두면 홈 디렉터리 아래 .ssh 폴더에 비밀키와 공개키가 함께 만들어져요. 기존 파일과 이름이 겹치면 덮어쓸지 물어보니, 반드시 내용을 확인한 뒤에 답해야 해요.

여러 서버를 상대한다면 -f로 파일 이름을 직접 지정해 두는 편이 안전해요. 예를 들어 ssh-keygen -t ed25519 -f ~/.ssh/id_deploy_was -C "deploy"처럼 용도별로 나눠 두면, 한 키가 노출됐을 때 교체 범위를 좁힐 수 있어요.

2) 공개키 확인하기

등록할 파일은 .pub가 붙은 쪽이에요. 내용을 열어 보면 ssh-ed25519 같은 알고리즘 이름, 긴 문자열, 그리고 끝에 주석이 한 줄로 이어져 있어요.

cat ~/.ssh/id_ed25519.pub

지문만 빠르게 확인하고 싶다면 ssh-keygen -lf ~/.ssh/id_ed25519.pub를 써요. 지문은 서버에 등록된 키와 내 키가 같은지 대조할 때 유용해요. 파일을 복사해 붙여넣을 때는 줄바꿈이 섞이지 않도록 한 줄 그대로 옮기는 것이 중요해요.

3) 서버에 공개키 등록하기

비밀번호 로그인이 아직 열려 있다면 ssh-copy-id가 가장 간단해요. 접속 정보를 그대로 넘기면 공개키를 읽어 서버의 authorized_keys에 추가해 주고, 디렉터리와 파일 권한도 알아서 맞춰 줘요.

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host

자동화 환경이나 권한이 제한된 계정에서는 직접 추가하는 편이 명확해요. 서버에 접속한 뒤 .ssh 디렉터리를 만들고 권한을 좁힌 다음, 공개키 한 줄을 덧붙이면 돼요.

mkdir -p ~/.ssh chmod 700 ~/.ssh echo "ssh-ed25519 AAAA... deploy@was" >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys

Git 호스팅 서비스를 쓴다면 웹 화면의 SSH 키 설정 항목에 같은 공개키를 붙여넣으면 돼요. 계정에 등록하는 키와 저장소 단위로 등록하는 배포용 키는 권한 범위가 다르므로, 배포 자동화에는 저장소 단위 키를 쓰는 편이 안전해요.

4) 권한 정리하기

키 인증은 파일 권한에 민감해요. 권한이 느슨하면 서버가 키를 무시하고 비밀번호 인증으로 되돌아가는 경우가 흔해요. 홈 디렉터리까지 다른 사용자가 쓸 수 있으면 그것도 문제가 될 수 있어요.

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

소유자도 함께 확인하는 것이 좋아요. chown -R user:user ~/.ssh처럼 현재 계정으로 맞춰 두면 권한 문제로 시간을 쓰는 일이 줄어요. SELinux가 켜진 배포판이라면 파일을 새로 만들었을 때 컨텍스트가 어긋날 수 있으니, 필요하면 restorecon -R ~/.ssh로 되돌려요.

5) 접속 테스트와 ssh-agent

등록이 끝났다면 실제로 접속해 봐요. ssh -i ~/.ssh/id_ed25519 user@host로 확인하고, 문제가 있으면 -v를 붙여 어느 단계에서 멈추는지 봐요. 서버 로그는 /var/log/auth.log나 배포판에 따라 그에 대응하는 로그에서 확인할 수 있어요.

passphrase를 걸어 두었다면 매번 입력하지 않도록 agent에 등록해요. 세션마다 eval "$(ssh-agent -s)"를 실행하고 ssh-add ~/.ssh/id_ed25519로 키를 올리면 돼요. 자주 쓰는 서버는 ~/.ssh/config에 Host 항목으로 정리해 두면 명령이 짧아져요.

상황별 선택

서버 한 대에 접속하는 정도라면 키 하나로 충분해요. 반면 배포 대상이 늘어나면 키를 용도별로 나누는 편이 관리에 유리해요.

• 개인 개발 서버: 계정당 키 하나를 만들고 ssh-copy-id로 등록해요.
• 배포 자동화: 배포 전용 키를 따로 만들고, 서버에서는 해당 키에 필요한 명령만 허용하는 방식으로 범위를 좁혀요.
• 여러 서버 운영: ~/.ssh/config에 Host 별칭과 IdentityFile을 적어 두고 골라 써요.
• 점프 호스트 경유: ProxyJump 항목으로 중간 서버를 지정하면 접속 절차가 단순해져요.
• 키 교체: 새 키를 먼저 등록해 접속을 확인한 뒤 기존 키를 제거하는 순서로 진행해요.

중요한 것은 "하나의 키를 모든 곳에 재사용하지 않는다"는 원칙이에요. 키를 나눠 두면 폐기와 교체가 훨씬 수월해져요.

주의할 점

비밀키 파일은 절대 외부로 나가면 안 돼요. 저장소에 커밋되거나 메신저로 공유된 키는 즉시 폐기하고 새로 만드는 것이 맞아요. .pub가 붙지 않은 파일을 붙여넣는 실수도 흔한데, 등록 후 접속이 안 되면 가장 먼저 이 부분을 확인해요.

서버 설정도 함께 봐야 해요. sshd_config에서 공개키 인증이 켜져 있는지, AuthorizedKeysFile 경로가 기본값과 다른지 확인해요. 설정을 바꿨다면 문법 검사를 거쳐 서비스를 다시 읽히는 순서를 지켜야 접속이 끊기는 상황을 피할 수 있어요.

호스트 키 경고도 그냥 넘기지 않는 편이 좋아요. 서버를 재설치했다면 지문이 바뀌는 것이 정상이지만, 그렇지 않은데 경고가 뜬다면 접속을 멈추고 확인해야 해요. known_hosts에서 해당 항목만 정리하는 것이 안전해요.

passphrase는 생략하지 않는 쪽을 권해요. 로컬 환경이 노출됐을 때 비밀키 파일만으로 접속이 가능해지는 것을 막아 주기 때문이에요. 불편하면 agent에 등록하는 방식으로 해결하면 돼요.

자주 묻는 질문

ssh 키는 어디에 저장되나요?

기본 경로는 사용자 홈 디렉터리 아래 .ssh 폴더예요. ssh-keygen 실행 시 경로를 따로 지정하지 않으면 비밀키와 공개키가 이곳에 함께 만들어져요. 경로를 바꿨다면 접속할 때 -i 옵션이나 ~/.ssh/config의 IdentityFile로 알려 줘야 해요.

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

기존 키를 쓰는 서버가 하나라도 있다면 덮어쓰지 않는 편이 안전해요. 덮어쓰는 순간 그 키로 접속하던 모든 대상에서 인증이 실패할 수 있어요. 새 키를 다른 이름으로 만들고, 등록과 확인이 끝난 뒤 기존 키를 정리하는 순서를 권해요.

서버에서 접속이 거부될 때 무엇을 확인해야 하나요?

먼저 서버의 authorized_keys에 공개키가 한 줄로 제대로 들어갔는지 봐요. 다음으로 .ssh와 authorized_keys의 권한과 소유자를 확인해요. 여기까지 정상인데도 안 되면 sshd_config의 공개키 인증 설정과 서버 로그를 함께 확인해요.

passphrase를 꼭 걸어야 하나요?

필수는 아니지만 걸어 두는 편이 안전해요. 비밀키 파일이 유출되더라도 passphrase 없이는 사용할 수 없기 때문이에요. 입력이 번거롭다면 ssh-agent에 한 번만 등록해서 세션 동안 재사용하면 돼요.

출처

• ssh-keygen(1) 매뉴얼 — OpenBSD
• sshd(8) 매뉴얼 — OpenBSD
• GitHub Docs — Generating a new SSH key and adding it to the ssh-agent

키를 등록한 뒤에도 접속이 자주 끊기거나 인증 방식이 예상과 다르게 동작한다면 서버 쪽 설정을 함께 봐야 해요. sshd_config 설정과 접속 정책 점검 정리 글에서 공개키 인증 활성화, 접속 계정 제한, 로그 확인 방법을 이어서 다루고 있으니 함께 읽어 보시길 권해요.