매번 비밀번호 입력하는 게 귀찮지 않으셨나요?
GitHub에 코드를 푸시할 때마다 아이디와 비밀번호를 입력하고, 원격 서버에 접속할 때마다 또 비밀번호를 치고. 하루에도 수십 번 반복되는 이 과정이 당연하다고 생각하셨을 수 있습니다. 하지만 SSH 키 인증을 한 번만 설정해 두면, 이 모든 번거로움이 사라지면서 동시에 보안까지 훨씬 강화됩니다.
SSH 키 인증은 공개키 암호학이라는 수학적 원리에 기반합니다. 쉽게 말해, 자물쇠(공개키)와 열쇠(개인키)를 한 쌍으로 만들어서, 자물쇠는 접속하려는 서버에 걸어두고 열쇠는 내 컴퓨터에만 보관하는 방식입니다. 비밀번호처럼 네트워크를 통해 전송되지 않으니 중간에 가로채일 위험이 원천적으로 차단됩니다.
이 글에서는 SSH 키를 처음 만드는 것부터 GitHub 연결, 원격 서버 접속, 여러 키 관리, 그리고 실무에서 반드시 알아야 할 보안 팁까지 한 번에 정리합니다. 운영체제별(Windows·macOS·Linux) 명령어를 모두 포함했으니, 지금 바로 따라 해 보세요.
SSH 키의 작동 원리를 30초 만에 이해하기
SSH 키 인증의 핵심은 비대칭 암호화입니다. 일반적인 비밀번호 인증과 근본적으로 다른 점을 먼저 짚어보겠습니다.
비밀번호 인증 vs SSH 키 인증
비밀번호 인증은 내가 알고 있는 문자열을 서버에 보내서 맞는지 확인하는 방식입니다. 이 과정에서 비밀번호가 네트워크를 타고 이동하기 때문에, 아무리 암호화된 채널이라 해도 무차별 대입 공격(brute-force)이나 피싱에 취약합니다. 반면 SSH 키 인증에서는 개인키가 절대로 내 컴퓨터를 떠나지 않습니다.
실제 인증 과정은 이렇게 진행됩니다. 서버가 임의의 데이터(챌린지)를 보내면, 내 컴퓨터가 개인키로 그 데이터에 서명합니다. 서버는 미리 등록된 공개키로 서명을 검증합니다. 서명이 유효하면 접속이 허용됩니다. 개인키 자체는 전혀 전송되지 않으므로, 설령 네트워크가 완전히 노출되더라도 키를 탈취할 수 없습니다.
키 알고리즘의 선택
2026년 현재 권장되는 알고리즘은 Ed25519입니다. RSA보다 키 길이가 짧으면서도 보안 강도는 더 높고, 서명 생성과 검증 속도도 빠릅니다. 구형 시스템과의 호환성이 필요한 특수한 경우가 아니라면 Ed25519를 사용하세요.
- Ed25519: 키 길이 256비트, 속도 빠름, 2026년 표준 권장
- ECDSA: 키 길이 256/384/521비트, Ed25519보다 구현 복잡성이 높음
- RSA: 최소 4096비트 권장, 레거시 호환용으로만 사용
SSH 키 생성하기 – OS별 실전 명령어
SSH 키 생성은 어떤 운영체제에서든 터미널 명령어 한 줄이면 됩니다. 각 OS별로 따라 해 보겠습니다.
Windows (Windows 10/11)
Windows 10 이후부터는 OpenSSH 클라이언트가 기본 내장되어 있습니다. PowerShell이나 Windows Terminal을 열고 다음 명령어를 입력하세요.
ssh-keygen -t ed25519 -C "[email protected]"
실행하면 키를 저장할 경로를 묻습니다. 기본값인 C:\Users\사용자명\.ssh\id_ed25519를 그대로 사용하려면 Enter를 누르세요. 이어서 패스프레이즈(passphrase)를 설정할지 묻는데, 이 부분이 중요합니다.
패스프레이즈는 반드시 설정하세요. 패스프레이즈는 개인키 파일 자체를 한 번 더 암호화하는 비밀번호입니다. 만약 누군가 내 컴퓨터에 접근해서 개인키 파일을 복사해 가더라도, 패스프레이즈 없이는 사용할 수 없습니다. 8자 이상의 기억하기 쉬운 문장을 추천합니다.
생성이 완료되면 두 개의 파일이 만들어집니다.
id_ed25519: 개인키 (절대 외부에 공유 금지)id_ed25519.pub: 공개키 (서버나 GitHub에 등록하는 용도)
WSL2를 사용 중이라면 WSL 터미널 안에서도 동일한 명령어로 별도의 키 쌍을 생성할 수 있습니다. Windows 측 키와 WSL 측 키는 별개이므로, 용도에 맞게 관리하세요.
macOS
macOS는 터미널 앱을 열고 동일한 명령어를 실행합니다.
ssh-keygen -t ed25519 -C "[email protected]"
키는 ~/.ssh/id_ed25519에 저장됩니다. macOS의 장점은 키체인(Keychain) 연동입니다. 패스프레이즈를 키체인에 저장해 두면, 매번 입력하지 않아도 자동으로 인증됩니다. 다음 명령어로 키체인에 추가하세요.
ssh-add --apple-use-keychain ~/.ssh/id_ed25519
그리고 ~/.ssh/config 파일에 다음 설정을 추가하면, 재부팅 후에도 키체인 연동이 유지됩니다.
Host *
AddKeysToAgent yes
UseKeychain yes
IdentityFile ~/.ssh/id_ed25519
Linux (Ubuntu/Debian 계열)
대부분의 리눅스 배포판에는 OpenSSH가 기본 설치되어 있습니다. 터미널에서 바로 실행하세요.
ssh-keygen -t ed25519 -C "[email protected]"
키가 생성되면 ssh-agent를 시작하고 키를 추가합니다.
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
셸 시작 시 자동으로 ssh-agent가 실행되도록 ~/.bashrc 또는 ~/.zshrc에 위 eval 명령을 추가해 두면 편리합니다.
GitHub에 SSH 키 등록하고 연결하기
SSH 키를 생성했으면, 가장 먼저 해볼 것이 GitHub 연결입니다. HTTPS 방식으로 매번 토큰을 입력하던 불편함이 완전히 사라집니다.
1단계: 공개키 복사
먼저 공개키 내용을 클립보드에 복사합니다.
- Windows:
type %USERPROFILE%\.ssh\id_ed25519.pub | clip(PowerShell:Get-Content ~\.ssh\id_ed25519.pub | Set-Clipboard) - macOS:
pbcopy < ~/.ssh/id_ed25519.pub - Linux:
xclip -sel clip < ~/.ssh/id_ed25519.pub또는cat ~/.ssh/id_ed25519.pub후 수동 복사
2단계: GitHub에 등록
GitHub 웹사이트에 로그인한 뒤, 우측 상단 프로필 아이콘을 클릭하고 Settings → SSH and GPG keys → New SSH key를 선택합니다. Title에는 이 키를 식별할 수 있는 이름(예: “내 노트북 2026”)을 적고, Key 필드에 방금 복사한 공개키를 붙여넣습니다. Key type은 Authentication key로 두고 Add SSH key를 클릭하면 끝입니다.
3단계: 연결 테스트
터미널에서 다음 명령어로 연결을 테스트합니다.
ssh -T [email protected]
처음 접속하면 GitHub 서버의 지문(fingerprint)을 신뢰할 것인지 묻습니다. yes를 입력하세요. 이후 “Hi 사용자명! You’ve been authenticated” 메시지가 나오면 성공입니다.
4단계: 기존 저장소를 SSH 방식으로 전환
이미 HTTPS로 클론한 저장소가 있다면, 리모트 URL을 SSH 방식으로 변경해야 합니다.
git remote set-url origin [email protected]:사용자명/저장소명.git
이제부터 git push, git pull 할 때 비밀번호 없이 자동으로 SSH 키 인증이 적용됩니다. 새 저장소를 클론할 때도 SSH URL을 사용하면 됩니다.
git clone [email protected]:사용자명/저장소명.git
원격 서버(VPS·NAS·홈서버)에 SSH 키로 접속하기
SSH 키 인증의 진가는 원격 서버 접속에서 발휘됩니다. 특히 홈서버나 NAS를 운영하고 계신다면, 비밀번호 인증을 완전히 비활성화하고 키 인증만 남겨두는 것이 보안 모범 사례입니다.
공개키를 서버에 등록하기
가장 간편한 방법은 ssh-copy-id 명령어입니다.
ssh-copy-id -i ~/.ssh/id_ed25519.pub 사용자@서버주소
이 명령어를 실행하면 서버의 ~/.ssh/authorized_keys 파일에 공개키가 자동으로 추가됩니다. Windows에서는 ssh-copy-id가 기본 제공되지 않으므로, 다음과 같이 수동으로 등록합니다.
type %USERPROFILE%\.ssh\id_ed25519.pub | ssh 사용자@서버주소 "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
등록 후 비밀번호 없이 접속이 되는지 확인하세요.
ssh 사용자@서버주소
서버 측 보안 강화: 비밀번호 인증 비활성화
SSH 키 인증이 정상 동작하는 것을 확인했다면, 서버의 비밀번호 인증을 끄는 것을 강력히 권장합니다. 서버에 접속한 뒤 SSH 설정 파일을 편집합니다.
sudo nano /etc/ssh/sshd_config
다음 항목들을 찾아서 변경합니다.
PasswordAuthentication no: 비밀번호 인증 비활성화PubkeyAuthentication yes: 공개키 인증 활성화 (기본값이 yes이지만 명시적으로)PermitRootLogin prohibit-password: root 계정은 키 인증만 허용
설정을 저장한 뒤 SSH 서비스를 재시작합니다.
sudo systemctl restart sshd
주의: 비밀번호 인증을 끄기 전에, SSH 키로 접속이 되는 것을 반드시 먼저 확인하세요. 그렇지 않으면 서버에 접속할 방법이 없어집니다. 혹시 모를 상황에 대비해 서버의 물리적 콘솔 접근 방법(모니터·키보드 직접 연결 또는 클라우드 VPS의 웹 콘솔)을 미리 확인해 두세요.
Synology NAS에서 SSH 키 인증 설정
Synology NAS를 사용하고 계신다면 약간의 추가 설정이 필요합니다. DSM 제어판에서 터미널 및 SNMP 메뉴를 열고 SSH 서비스를 활성화합니다. 이후 SSH로 NAS에 접속한 뒤 다음 작업을 수행합니다.
- 홈 디렉터리 권한 확인:
chmod 755 ~ - .ssh 디렉터리 생성 및 권한 설정:
mkdir -p ~/.ssh && chmod 700 ~/.ssh - authorized_keys 파일 생성:
touch ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys - 공개키 내용을 authorized_keys에 붙여넣기
Synology DSM의 SSH 데몬은 홈 디렉터리와 .ssh 디렉터리의 권한에 매우 엄격합니다. 위 권한 설정을 정확히 맞추지 않으면 키 인증이 동작하지 않으니 주의하세요.
SSH Config 파일로 접속을 간편하게 관리하기
서버가 여러 대이거나, 포트 번호가 기본(22)이 아니거나, 사용자 계정이 서버마다 다를 때 매번 긴 명령어를 입력하는 것은 비효율적입니다. ~/.ssh/config 파일을 활용하면 별칭 하나로 간편하게 접속할 수 있습니다.
config 파일 작성 예시
~/.ssh/config 파일을 생성하고(없다면) 다음과 같이 작성합니다.
# 홈서버 NAS
Host nas
HostName 192.168.1.100
User admin
Port 2222
IdentityFile ~/.ssh/id_ed25519
# 클라우드 VPS
Host vps
HostName my-server.example.com
User deploy
IdentityFile ~/.ssh/id_ed25519_vps
# GitHub (기본 설정)
Host github.com
IdentityFile ~/.ssh/id_ed25519
AddKeysToAgent yes
이제 ssh nas 또는 ssh vps만 입력하면, 해당 호스트·포트·사용자·키가 자동으로 적용됩니다. scp나 rsync에서도 이 별칭을 그대로 사용할 수 있어서, 백업 스크립트를 작성할 때 특히 유용합니다.
여러 GitHub 계정 사용하기
개인 계정과 회사 계정 등 GitHub 계정이 여러 개인 경우, 각 계정별로 다른 SSH 키를 사용해야 합니다. config 파일에서 호스트 별칭으로 구분합니다.
Host github-personal
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_personal
Host github-work
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_work
저장소를 클론할 때 호스트 부분을 별칭으로 바꿔서 사용합니다.
git clone git@github-personal:개인계정/저장소.git
git clone git@github-work:회사계정/저장소.git
SSH 키 관리 실전 팁과 보안 체크리스트
SSH 키를 생성하고 등록하는 것은 시작일 뿐입니다. 안전하게 오래 사용하려면 관리 습관도 중요합니다. 실무에서 검증된 모범 사례들을 정리했습니다.
ssh-agent로 패스프레이즈 입력 횟수 줄이기
패스프레이즈를 설정하면 보안은 높아지지만, 접속할 때마다 입력하는 것이 번거로울 수 있습니다. ssh-agent는 메모리에 복호화된 키를 캐시해 두어, 세션 동안 한 번만 패스프레이즈를 입력하면 되게 해줍니다.
- macOS: 키체인 연동으로 부팅 후에도 자동 로드 (앞서 설명한 설정 적용 시)
- Linux:
ssh-add ~/.ssh/id_ed25519실행 후 세션 동안 유지. GNOME·KDE 등 데스크톱 환경에서는 자체 키링이 ssh-agent 역할을 합니다. - Windows: OpenSSH Authentication Agent 서비스를 자동 시작으로 설정하면 편리합니다.
Set-Service ssh-agent -StartupType Automatic(PowerShell 관리자 권한)
키 보안 체크리스트
다음 항목들을 주기적으로 점검하세요.
- 개인키 파일 권한: 반드시 600(소유자만 읽기/쓰기)이어야 합니다.
chmod 600 ~/.ssh/id_ed25519 - .ssh 디렉터리 권한: 700(소유자만 접근)이어야 합니다.
chmod 700 ~/.ssh - 개인키 백업: 암호화된 USB나 비밀번호 관리자(Bitwarden, 1Password 등)에 안전하게 보관. 이메일이나 클라우드 드라이브에 평문으로 올리지 마세요.
- 사용하지 않는 키 폐기: 더 이상 쓰지 않는 기기의 공개키는 서버의 authorized_keys와 GitHub에서 즉시 삭제하세요.
- 키 회전: 1~2년 주기로 새 키를 생성하고 이전 키를 교체하는 것이 좋습니다.
FIDO2/보안 키와 연동하기
보안을 한 단계 더 높이고 싶다면 YubiKey 같은 하드웨어 보안 키를 활용할 수 있습니다. OpenSSH 8.2 이후부터 FIDO2 표준을 지원하므로, 하드웨어 키에 SSH 개인키를 바인딩할 수 있습니다.
ssh-keygen -t ed25519-sk -C "[email protected]"
-sk 접미사가 붙은 키 타입을 사용하면, SSH 접속 시 물리적으로 보안 키를 터치해야만 인증이 완료됩니다. 개인키 파일이 유출되더라도 하드웨어 키 없이는 사용 불가능하므로, 가장 강력한 인증 방식이라 할 수 있습니다.
자주 겪는 문제와 해결법
SSH 키 설정 과정에서 흔히 마주치는 문제들과 해결 방법을 정리했습니다.
- “Permission denied (publickey)” 오류: 가장 흔한 원인은 파일 권한입니다. 개인키(600), .ssh 디렉터리(700), 홈 디렉터리(755 이하)의 권한을 확인하세요. 서버의 authorized_keys에 공개키가 정확히 등록되었는지도 점검합니다.
- ssh-agent에 키가 추가되지 않음:
ssh-add -l로 현재 등록된 키 목록을 확인하세요. 비어 있다면ssh-add ~/.ssh/id_ed25519로 수동 추가합니다. - GitHub에서 “Permission denied” 발생:
ssh -vT [email protected]으로 디버깅합니다.-v옵션은 어떤 키를 시도했는지, 어디서 실패했는지 상세 로그를 보여줍니다. - WSL에서 Windows 키를 사용하고 싶을 때: WSL 내부에서 Windows 경로의 키를 직접 참조하면 권한 문제가 생깁니다. 키를 WSL 홈 디렉터리로 복사하고 권한을 재설정하는 것이 깔끔합니다.
- Synology NAS에서 키 인증이 안 될 때:
/etc/ssh/sshd_config에서PubkeyAuthentication yes와AuthorizedKeysFile .ssh/authorized_keys가 설정되어 있는지 확인하세요. DSM 업데이트 후 초기화되는 경우가 있습니다.
실전 활용 시나리오: SSH 키로 이런 것까지 가능합니다
SSH 키 인증은 단순 접속 외에도 다양한 자동화와 보안 시나리오에 활용됩니다.
자동 백업 스크립트
SSH 키가 설정되어 있으면 cron이나 Task Scheduler로 무인 백업을 자동화할 수 있습니다. rsync와 SSH를 조합하면 증분 백업이 간단해집니다.
rsync -avz -e "ssh -i ~/.ssh/id_ed25519" ~/documents/ nas:/volume1/backup/documents/
이 명령을 cron에 등록하면 매일 자동으로 문서를 NAS에 백업합니다. 비밀번호 입력이 필요 없으므로 완전 자동화가 가능합니다.
Git 서명(Signing)에 SSH 키 활용
Git 2.34 이후부터 GPG 대신 SSH 키로 커밋에 서명할 수 있습니다. 별도의 GPG 키를 관리할 필요 없이 이미 가지고 있는 SSH 키를 재활용하는 셈입니다.
git config --global gpg.format ssh
git config --global user.signingkey ~/.ssh/id_ed25519.pub
git config --global commit.gpgsign true
이렇게 설정하면 모든 커밋에 자동으로 서명이 추가되어, GitHub에서 “Verified” 배지가 표시됩니다. 내가 작성한 커밋이 위변조되지 않았음을 증명하는 셈입니다.
SSH 포트 포워딩으로 안전한 터널 만들기
원격 서버의 내부 서비스(데이터베이스, 관리자 페이지 등)에 안전하게 접근할 때 SSH 터널이 유용합니다.
ssh -L 3307:localhost:3306 vps
이 명령은 로컬 3307 포트를 원격 서버의 MySQL(3306)에 연결합니다. 이제 localhost:3307로 접속하면 VPN 없이도 원격 데이터베이스를 안전하게 사용할 수 있습니다. SSH 키 인증이 되어 있으면 터널 생성도 비밀번호 없이 즉시 가능합니다.
CI/CD 파이프라인에서의 활용
GitHub Actions나 GitLab CI에서 배포 서버에 접속할 때도 SSH 키가 핵심입니다. 개인키를 CI 시크릿으로 등록하고, 파이프라인에서 ssh-agent에 로드한 뒤 배포 명령을 실행하는 패턴이 표준입니다. 이때 배포 전용 키를 별도로 생성하고, 해당 키에는 최소 권한만 부여하는 것이 보안 모범 사례입니다.
마무리: 한 번 설정으로 매일의 편의와 보안을 동시에
SSH 키 인증은 설정에 10분, 효과는 영구적입니다. 매일 반복하던 비밀번호 입력이 사라지고, 동시에 무차별 대입 공격이나 비밀번호 유출 위험에서 벗어나게 됩니다. 특히 홈서버, NAS, VPS를 운영하는 분들에게는 비밀번호 인증을 끄고 키 인증만 남기는 것이 사실상 필수입니다.
오늘 소개한 내용을 정리하면 이렇습니다.
- Ed25519 알고리즘으로 키를 생성하고, 반드시 패스프레이즈를 설정합니다.
- GitHub에 공개키를 등록하면 비밀번호 없이 push/pull이 가능합니다.
- 원격 서버에 공개키를 등록한 뒤, 서버 측 비밀번호 인증을 비활성화합니다.
- SSH config 파일로 여러 서버를 별칭으로 관리하면 편리합니다.
- 정기적인 키 회전과 사용하지 않는 키 폐기를 습관화합니다.
지금 바로 터미널을 열고 ssh-keygen -t ed25519를 실행해 보세요. 10분 뒤면 비밀번호 없는 세상이 열립니다.
이미지는 Leonardo AI 로 생성되었습니다.
이미지는 Claude AI 로 생성되었습니다.