ssh 키 생성 윈도우 한눈에 보기

윈도우에서 ssh 키를 만들 때는 별도 프로그램을 설치하기보다 윈도우에 포함된 OpenSSH 클라이언트의 ssh-keygen을 쓰는 편이 가장 간단해요. PowerShell을 열고 ssh-keygen을 실행해 키 쌍을 만든 뒤, 공개키를 서버나 Git 호스팅 계정에 등록하면 바로 키 기반 접속을 쓸 수 있어요. 이 글은 설치 확인부터 키 생성, 공개키 등록, 권한 점검, 상황별 선택 기준까지 순서대로 정리해요.

한눈에 보기

전체 흐름은 길지 않아요. OpenSSH 클라이언트가 있는지 확인하고, 키를 만들 위치와 암호를 정하고, 공개키를 상대 서버에 등록하면 끝이에요. 여기서 갈리는 지점은 "어떤 알고리즘으로 만들 것인가"와 "개인키를 어떤 권한으로 보관할 것인가" 정도예요.

윈도우의 OpenSSH 클라이언트는 선택적 기능 형태로 제공되며, 없으면 설정 앱이나 PowerShell로 추가할 수 있어요.
키는 보통 사용자 홈 폴더 아래 .ssh 디렉터리에 만들어요.
서버나 Git 호스팅에는 .pub 확장자가 붙은 공개키만 올리고, 확장자가 없는 개인키는 로컬에만 둬요.
암호(passphrase)를 걸었다면 ssh-agent 서비스에 키를 등록해 두면 매번 입력하지 않아도 돼요.

가장 중요한 원칙은 하나예요. 공개키는 배포해도 되지만 개인키는 절대 복사하거나 전송하지 않아요. 개인키가 유출되면 그 키로 접속할 수 있는 모든 서버가 함께 위험해지기 때문이에요.

ssh-keygen과 키 파일 구조

ssh-keygen은 OpenSSH에 함께 들어 있는 키 생성 도구예요. 리눅스에서 쓰던 것과 같은 도구가 윈도우용 OpenSSH에도 포함되어 있어서, 명령과 옵션을 그대로 익혀 두면 두 환경에서 동일하게 쓸 수 있어요. 생성되는 파일의 역할은 다음과 같아요.

항목	역할	윈도우에서의 위치 예시
개인키	접속 시 자신을 증명하는 파일이에요. 외부에 노출하지 않아요.	C:\Users\사용자이름.ssh\id_ed25519
공개키	서버의 authorized_keys나 Git 호스팅 계정에 등록해요.	C:\Users\사용자이름.ssh\id_ed25519.pub
known_hosts	접속한 서버의 호스트 키 지문을 기록해요.	C:\Users\사용자이름.ssh\known_hosts
config	호스트별 접속 옵션과 별칭을 미리 정해 둘 수 있어요.	C:\Users\사용자이름.ssh\config

키 이름을 따로 지정하지 않으면 알고리즘에 따라 기본 파일명이 붙어요. 파일명만 보고도 어떤 용도의 키인지 구분되도록 이름을 직접 정하는 편이 관리하기 좋아요. 예를 들어 업무용 서버와 개인 저장소용 키를 나눠 두면 나중에 하나를 폐기할 때 영향 범위가 좁아져요.

단계별로 ssh 키 생성하기

OpenSSH 클라이언트 확인과 설치

먼저 PowerShell을 열고 설치 여부를 확인해요. ssh -V를 실행했을 때 버전 정보가 출력되면 이미 준비된 상태예요. 명령을 찾을 수 없다는 메시지가 나오면 선택적 기능을 추가해야 해요.

PowerShell에서 기능 상태를 확인하는 명령은 다음과 같아요.

Get-WindowsCapability -Online | Where-Object Name -like 'OpenSSH*'

설치가 필요하다면 관리자 권한 PowerShell에서 설치 명령을 실행하거나, 설정 앱의 앱 → 선택적 기능 화면에서 OpenSSH 클라이언트를 추가하면 돼요. 설치 후에는 PowerShell 창을 새로 열어야 명령이 인식되는 경우가 많아요.

ssh-keygen으로 키 만들기

키를 만들 때는 알고리즘과 설명(주석)을 함께 지정해요. 요즘은 ed25519를 많이 쓰지만, 조직에서 정한 표준이 있다면 그 기준을 따르는 편이 안전해요. 키 길이는 도구가 제안하는 기본값을 그대로 두는 편이 무난해요.

ssh-keygen -t ed25519 -C "업무용 노트북"

실행하면 저장 경로를 묻는 프롬프트가 나와요. 그대로 Enter를 누르면 .ssh 폴더에 기본 이름으로 저장되고, 다른 이름을 쓰고 싶다면 경로를 직접 입력해요. 이어서 암호를 두 번 묻는데, 비워 두면 암호 없는 키가 만들어져요. 자동 배포처럼 사람이 개입하지 않는 작업이 아니라면 암호를 설정하는 편이 좋아요.

완료되면 개인키와 공개키가 한 쌍으로 생성돼요. 공개키 파일은 텍스트라서 열어 보면 ssh-ed25519로 시작하는 한 줄과 끝에 붙은 주석을 확인할 수 있어요. 이 주석은 여러 키를 관리할 때 어느 키인지 구분하는 표시 역할을 해요.

공개키를 서버와 Git 호스팅에 등록하기

공개키 내용을 확인하는 명령은 다음과 같아요.

Get-Content $env:USERPROFILE.ssh\id_ed25519.pub

출력된 한 줄을 복사해서 리눅스 서버의 ~/.ssh/authorized_keys 파일 끝에 추가하면 돼요. 서버에 아직 비밀번호 접속이 가능하다면 파이프로 바로 전달할 수도 있어요.

Get-Content $env:USERPROFILE.ssh\id_ed25519.pub | ssh 사용자@서버주소 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

Git 호스팅을 쓴다면 해당 서비스의 계정 설정 화면에서 SSH 키 등록 메뉴를 찾아 같은 내용을 붙여 넣으면 돼요. GitHub의 경우 설정의 SSH and GPG keys 항목에서 새 키를 추가하는 방식이에요.

접속 테스트와 ssh-agent 등록

등록이 끝났다면 비밀번호 없이 접속되는지 확인해요. Git 호스팅은 ssh -T git@호스트 형태로 인증 결과를 확인할 수 있고, 일반 서버는 ssh 사용자@서버주소로 접속해 보면 돼요. 접속이 되지 않는다면 ssh -v로 상세 로그를 보면서 어느 단계에서 멈추는지 확인하는 편이 빠르게 원인을 좁힐 수 있어요.

암호를 설정한 키라면 ssh-agent에 등록해 두는 것이 편해요. 윈도우에서는 ssh-agent가 서비스로 동작하기 때문에, 서비스 상태를 확인하고 자동 시작으로 바꾼 뒤 키를 추가해요.

Get-Service ssh-agent Set-Service -Name ssh-agent -StartupType Automatic Start-Service ssh-agent ssh-add $env:USERPROFILE.ssh\id_ed25519

이 과정을 거치면 같은 세션 안에서 암호를 반복해서 입력하지 않아도 돼요.

상황별 선택 기준

같은 ssh 키라도 쓰는 목적에 따라 준비 방식이 조금씩 달라져요. 아래 표는 자주 만나는 상황과 무난한 선택지를 정리한 것이에요.

상황	권장 방법	메모
리눅스 서버에 처음 접속	PowerShell에서 ssh-keygen 실행	추가 도구 설치 없이 진행할 수 있어요
이미 PuTTY를 쓰는 팀	PuTTYgen으로 생성하거나 기존 키를 변환	PuTTY 전용 형식은 OpenSSH 키와 호환되지 않아요
배포 자동화에 키를 사용	용도별 키를 따로 만들고 서버 쪽 권한을 제한	사람이 쓰는 키와 자동화 키를 섞지 않는 편이 안전해요
관리하는 서버가 많음	`.ssh/config`에 호스트 별칭과 키 파일 지정	접속 명령이 짧아지고 키 혼동이 줄어요
여러 사람이 같은 계정을 씀	계정을 분리하고 각자 키를 등록	키 하나를 공유하면 누가 접속했는지 알 수 없어요

선택 기준에서 가장 자주 흔들리는 부분이 자동화용 키예요. 배포 스크립트는 암호를 입력할 수 없으니 암호 없는 키를 쓰게 되는데, 이때는 해당 키에 허용되는 명령을 서버 쪽에서 제한하거나 전용 계정을 따로 두는 방식으로 위험을 줄여요.

주의할 점

키 생성 자체보다 생성한 뒤의 관리가 더 중요해요. 아래 항목은 실제 운영에서 자주 문제가 되는 지점들이에요.

공개키와 개인키를 혼동하지 않아요. 등록해야 하는 것은 .pub 파일의 내용이고, 개인키는 로컬을 벗어나면 안 돼요.
.ssh 폴더와 개인키 파일의 권한을 좁혀요. 윈도우에서는 폴더 속성의 보안 설정에서 상속을 해제하고 현재 사용자에게만 권한을 주는 방식으로 정리할 수 있어요. 권한이 넓으면 OpenSSH가 키 사용을 거부하기도 해요.
키마다 용도를 적어 두어요. 주석에 기기 이름과 목적을 남기면 나중에 폐기할 대상을 찾기 쉬워요.
서버에 등록한 공개키는 정기적으로 점검해요. 더 이상 쓰지 않는 키가 authorized_keys에 남아 있으면 관리되지 않는 접속 경로가 되는 셈이에요.
지문을 확인해요. 공개키를 전달하는 과정에서 지문을 대조하면 엉뚱한 키가 등록되는 일을 줄일 수 있어요.

권한 문제는 특히 헷갈리기 쉬워요. 리눅스 서버에서 키 인증이 되지 않을 때는 서버 쪽 홈 디렉터리와 .ssh 디렉터리, authorized_keys 파일의 권한을 함께 확인해야 해요. 클라이언트 문제라고 단정하고 윈도우 쪽만 들여다보면 원인을 놓치기 쉬워요.

자주 묻는 질문

윈도우에서 ssh-keygen을 찾을 수 없다고 나오면 어떻게 하나요?

OpenSSH 클라이언트가 설치되지 않았거나 PATH에 잡히지 않은 상태예요. 관리자 권한 PowerShell에서 OpenSSH 클라이언트 기능을 추가한 뒤 새 창에서 다시 확인해 보세요. 설치 후에도 인식되지 않는다면 C:\Windows\System32\OpenSSH 경로에 실행 파일이 있는지 확인하면 돼요.

키를 만들 때 암호는 꼭 넣어야 하나요?

필수는 아니지만 사람이 직접 쓰는 키라면 설정하는 편이 안전해요. 암호가 없으면 개인키 파일을 얻은 사람이 곧바로 접속할 수 있기 때문이에요. 대신 ssh-agent에 등록해 두면 평소 입력 부담은 크게 줄어들어요.

같은 키를 여러 서버에 써도 되나요?

기술적으로는 가능하지만 권장하지 않아요. 키 하나가 유출되면 그 키를 등록한 모든 서버가 동시에 영향을 받기 때문이에요. 서버 그룹이나 용도 단위로 키를 나누고, 폐기할 때는 해당 키만 교체하는 방식이 관리하기 쉬워요.

PuTTY에서 쓰던 키를 그대로 쓸 수 있나요?

형식이 다르기 때문에 그대로는 쓸 수 없어요. PuTTYgen에서 OpenSSH 형식으로 내보내거나, 반대로 OpenSSH 키를 PuTTY 형식으로 변환해야 해요. 팀에서 도구를 섞어 쓴다면 어떤 형식을 표준으로 둘지 먼저 정하는 편이 좋아요.

출처

마이크로소프트 러닝, OpenSSH 키 관리: https://learn.microsoft.com/ko-kr/windows-server/administration/openssh/openssh_keymanagement
마이크로소프트 러닝, OpenSSH 시작하기: https://learn.microsoft.com/ko-kr/windows-server/administration/openssh/openssh_install_firstuse
OpenBSD 매뉴얼, ssh-keygen: https://man.openbsd.org/ssh-keygen
GitHub 문서, SSH 키 생성과 ssh-agent 등록: https://docs.github.com/ko/authentication/connecting-to-github-with-ssh/generating-a-new-ssh-key-and-adding-it-to-the-ssh-agent

키를 만들고 등록하는 일은 한 번 익히면 반복 작업이 되기 때문에, 처음에 권한과 파일 이름 규칙을 정해 두는 것이 오래 갑니다. 접속이 갑자기 막혔을 때 확인할 항목은 [Linux 명령어] ssh 접속 오류 점검 순서에서, 여러 서버의 키를 정리하는 방법은 [서버 운영] 배포용 계정과 키 분리 가이드에서 이어서 볼 수 있어요. 두 글 모두 이 글과 같은 기준으로 작성되어 있어 함께 읽으면 흐름이 자연스럽게 이어집니다.