SSH 접속할 때마다 비밀번호를 입력하다가 자동화 스크립트가 막히거나, 보안 정책상 비밀번호 인증을 꺼야 하는 상황이 생깁니다. 키 기반 인증으로 전환하면 이 두 가지를 한 번에 해결할 수 있는데, 처음 설정할 때 공개키 등록 위치나 권한 설정에서 한 번씩 막히는 경우가 많습니다. 이 글에서 Windows ssh-keygen 사용법부터 Linux 서버 등록까지 전 과정을 순서대로 정리합니다.
Windows 10 이상에서는 OpenSSH가 기본 내장되어 있어 별도 설치 없이 ssh-keygen을 바로 사용할 수 있습니다. 생성된 공개키를 Linux 서버의 ~/.ssh/authorized_keys에 등록하면 비밀번호 없이 키 인증으로 접속이 가능해집니다. 권한 설정(chmod 700 / 600)이 틀리면 키 인증이 작동하지 않으니 반드시 확인해야 합니다.
사전 확인 — OpenSSH 설치 여부
Windows 10 버전 1809 이상, Windows 11이라면 OpenSSH 클라이언트가 기본 포함되어 있습니다. 먼저 설치 여부부터 확인합니다.
PowerShell을 관리자 권한으로 열고 아래 명령어를 입력합니다.
Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'
State가 Installed로 표시되면 바로 사용 가능합니다. NotInstalled 상태라면 아래 명령어로 설치합니다.
Add-WindowsCapability -Online -Name OpenSSH.Client~~~~0.0.1.0
설치 후 PowerShell 또는 CMD에서 ssh -V를 입력해 버전이 출력되면 준비 완료입니다. 실무에서 보면, 기업 환경에서 그룹 정책으로 OpenSSH 설치가 막혀 있는 경우가 간혹 있습니다. 그럴 땐 IT 관리자에게 확인하거나 PuTTYgen을 대안으로 쓸 수 있습니다.
ssh-keygen으로 키 쌍 생성
PowerShell 또는 CMD 아무 곳에서나 아래 명령어를 입력합니다.
ssh-keygen -t ed25519 -C "your_email@example.com"
알고리즘을 ed25519로 지정하는 이유가 있습니다. 과거에는 RSA 4096이 표준이었는데, ed25519는 키 길이가 짧으면서도 보안 강도가 높고 서명 속도가 빠릅니다. 레거시 시스템 호환이 필요한 경우에만 RSA를 씁니다.
레거시 환경이라면 아래를 사용합니다.
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"
명령어 실행 후 순서대로 입력값을 받습니다.
- 저장 경로 — 기본값은
C:\Users\계정명\.ssh\id_ed25519입니다. 그냥 Enter를 누르면 기본 경로에 저장됩니다. 여러 서버에 다른 키를 쓸 경우에만 이름을 바꿉니다. - 패스프레이즈(Passphrase) — 키 파일 자체에 걸 비밀번호입니다. 비워두면 키 파일만 있으면 바로 접속됩니다. 보안이 중요한 환경이라면 설정하는 게 맞고, 자동화 스크립트에 쓸 거라면 비워두는 경우가 많습니다.
생성이 완료되면 두 개의 파일이 만들어집니다.
| 파일명 | 역할 | 공유 여부 |
|---|---|---|
| id_ed25519 | 개인키 (Private Key) | 절대 외부 공유 금지 |
| id_ed25519.pub | 공개키 (Public Key) | 서버에 등록하는 파일 |
이건 직접 겪어보면 체감되는데, 처음 하는 분들이 가장 많이 헷갈리는 부분이 바로 여기입니다. .pub 파일만 서버에 올립니다. 개인키는 로컬에만 있어야 합니다.
공개키를 Linux 서버에 등록
방법은 두 가지입니다. 상황에 맞게 선택하면 됩니다.
방법 1 — ssh-copy-id 사용 (Linux/Mac 권장, Windows에서도 가능)
Windows OpenSSH에는 ssh-copy-id가 기본 포함되어 있지 않습니다. Git Bash가 설치되어 있다면 Git Bash에서 아래 명령어를 사용할 수 있습니다.
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@서버IP
이 명령어가 자동으로 서버의 ~/.ssh/authorized_keys에 공개키를 추가하고 권한도 맞춰줍니다. 한 줄로 끝나는 가장 빠른 방법입니다.
방법 2 — 수동 등록 (PowerShell/CMD에서 직접)
Git Bash가 없거나 방법 1이 안 되는 환경에서는 아래 순서로 수동 등록합니다.
Step 1. Windows에서 공개키 내용 확인
type C:\Users\계정명\.ssh\id_ed25519.pub
출력된 내용 전체를 복사합니다. ssh-ed25519 AAAA...로 시작하는 한 줄 전체입니다.
Step 2. Linux 서버에 비밀번호로 접속
ssh user@서버IP
Step 3. authorized_keys에 공개키 추가
mkdir -p ~/.ssh echo "복사한_공개키_전체내용" >> ~/.ssh/authorized_keys
또는 PowerShell에서 원격 명령으로 한 번에 처리하는 방법도 있습니다.
type $env:USERPROFILE\.ssh\id_ed25519.pub | ssh user@서버IP "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
많이들 여기서 막히더라고요 — echo 입력할 때 공개키 중간에 줄바꿈이 들어가는 경우입니다. authorized_keys는 키 하나가 반드시 한 줄이어야 작동합니다. 붙여넣기 전에 줄바꿈 없이 한 줄인지 꼭 확인하세요.
권한 설정 및 SSH 데몬 확인
이 부분이 핵심입니다. 공개키를 올려도 권한이 틀리면 SSH 데몬이 키 인증을 거부합니다. 에러 메시지 없이 그냥 비밀번호를 계속 요청하는 경우의 80% 이상이 권한 문제입니다.
Linux 서버에서 아래 명령어로 권한을 맞춥니다.
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys
소유자도 확인합니다.
ls -la ~/.ssh/
.ssh 디렉토리와 authorized_keys 파일의 소유자가 현재 로그인한 계정과 일치해야 합니다. root로 복사했다가 소유자가 root로 남아있는 경우가 가끔 있습니다.
chown -R user:user ~/.ssh
sshd_config 설정도 확인합니다.
sudo grep -E "PubkeyAuthentication|AuthorizedKeysFile" /etc/ssh/sshd_config
아래 두 줄이 활성화되어 있어야 합니다.
PubkeyAuthentication yes AuthorizedKeysFile .ssh/authorized_keys
값이 no이거나 주석 처리되어 있다면 수정 후 SSH 데몬을 재시작합니다.
sudo systemctl restart sshd
인증 방식 비교 — 비밀번호 vs 키 기반
| 항목 | 비밀번호 인증 | 키 기반 인증 |
|---|---|---|
| 보안 강도 | 브루트포스 공격에 취약 | 개인키 없이는 접속 불가 |
| 자동화 스크립트 | 비밀번호 하드코딩 필요 | 키 파일로 무인 접속 가능 |
| 접속 편의성 | 매번 입력 필요 | 패스프레이즈 없으면 바로 접속 |
| 분실 시 대응 | 비밀번호 재설정 | authorized_keys에서 해당 키 삭제 |
| 다중 서버 관리 | 서버마다 비밀번호 관리 필요 | 키 하나로 여러 서버 등록 가능 |
| 감사(Audit) 추적 | 계정 단위 | 키 단위로 세분화 가능 |
실전 팁: 키 등록 후에도 비밀번호 인증을 완전히 끄고 싶다면 /etc/ssh/sshd_config에서
PasswordAuthentication no로 변경합니다. 단, 키 인증이 정상 작동하는 것을 먼저 확인한 뒤에 변경해야 합니다. 순서가 바뀌면 서버에 접속 자체가 불가능해집니다.
흔한 오해와 트러블슈팅
“키를 등록했는데 아직도 비밀번호를 묻는다”
체크 순서는 이렇습니다. 권한(chmod 700 / 600) → sshd_config PubkeyAuthentication yes → authorized_keys 파일에 키가 실제로 한 줄로 들어가 있는지 → 소유자 일치 여부. 실무에서 보면 authorized_keys 파일 안에 줄바꿈이 들어가서 키가 두 줄로 깨져 있는 경우가 제일 많습니다.
“공개키와 개인키 둘 다 서버에 올려야 하는 것 아닌가?”
아닙니다. 서버에는 .pub 파일(공개키)만 등록합니다. 개인키는 로컬 머신에만 존재해야 하며, 서버로 복사하는 순간 키 기반 인증의 보안 전제가 무너집니다.
“여러 PC에서 같은 서버에 접속하려면 키를 공유해야 하나?”
권장하지 않습니다. PC마다 별도 키를 생성하고 각각의 공개키를 서버 authorized_keys에 줄 단위로 추가하는 게 맞습니다. 그래야 특정 PC를 폐기할 때 해당 키 줄만 삭제하면 됩니다.
SSH 접속 시 -v 옵션으로 디버깅하기
키 인증이 어디서 실패하는지 확인할 때 아래 명령어가 유용합니다.
ssh -v user@서버IP
출력 로그에서 Offering public key → Server accepts key 흐름이 보이면 정상입니다. Permission denied (publickey)가 나오면 권한이나 authorized_keys 내용을 다시 확인합니다.
지금 당장 할 것 하나: PowerShell에서 ssh-keygen -t ed25519 실행 → 기본 경로로 저장 → .pub 파일 내용 확인까지만 먼저 해보세요. 여기까지 2분이면 됩니다.
키 등록 후 비밀번호 인증을 완전히 비활성화했을 때 예상치 못한 이슈가 생긴 경험이 있다면 댓글로 공유해주세요. 어떤 상황에서 어떻게 해결했는지 구체적으로 남겨주시면 다른 분들에게도 도움이 됩니다.
여러 서버에 각각 다른 키를 관리하고 있다면 ~/.ssh/config 파일을 어떻게 구성하고 있는지도 궁금합니다.
다음으로 읽으면 좋은 글:
~/.ssh/config 설정 방법 — 서버별 키, 포트, 유저 관리 한 파일로 정리하기
SSH 보안 강화 설정 — PasswordAuthentication 비활성화, 포트 변경, Fail2ban 적용
본 포스팅은 정보 전달 목적이며, 실제 적용 시 발생하는 책임은 사용자에게 있습니다.