SSH 키 인증, 도대체 어떻게 동작하는 걸까?
SSH 키 설정과 흐름에 대해서 잘모른다면,,,
🔑 공개키와 개인키, 뭐가 다른 거야?
SSH 키 인증의 핵심은 두 개의 키가 한 쌍이라는 것입니다.
| 키 종류 | 위치 | 역할 |
|---|---|---|
| 개인키 (Private Key) | 내 컴퓨터 (클라이언트) | 절대 외부 노출 금지. 서명 생성용 |
| 공개키 (Public Key) | 서버 | ~/.ssh/authorized_keys에 등록. 서명 검증용 |
이 둘의 관계를 도장에 비유하면 이렇습니다.
개인키 = 도장 (나만 가진 것, 서명 생성)
공개키 = 인감 견본 (누구나 볼 수 있음, 서명 검증)
도장으로 찍은 인감은 도장 없이는 똑같이 만들 수 없어요.
공개키(인감 견본)를 아무리 가져가도, 개인키(도장) 없이는 서명을 위조할 수 없습니다.
그래서 공개키는 이름처럼 공개해도 괜찮은 키입니다.
🔐 인증 흐름: 단계별로 살펴보기
SSH 키 인증은 아래 6단계로 이루어집니다.
A (클라이언트) B (서버)
─────────────────────────────────────────────────────
1. SSH 연결 요청 ──────────────────────────────────▶
2. ◀────────── Challenge (랜덤 데이터) 전송
3. 개인키로 Challenge에 서명 (Signature 생성)
4. Signature 전송 ─────────────────────────────────▶
5. 공개키로 Signature 검증
6. ◀────────── 인증 성공 / 실패 응답
하나씩 풀어볼게요.
1단계 — 연결 요청
클라이언트 A가 서버 B에게 이렇게 말하는 거예요.
"나 공개키 인증 방식으로 접속할게, 내 공개키는 이거야"
공개키를 먼저 제시해서 "나 등록된 사람이야"라고 알리는 것입니다.
2단계 — Challenge 전송
서버가 authorized_keys에서 해당 공개키를 확인한 뒤 묻습니다.
"진짜 개인키 가진 사람 맞아? 이거 풀어봐"
그러면서 랜덤 데이터(Challenge) 를 클라이언트로 전송합니다.
매 접속마다 다른 랜덤값을 보내기 때문에, 이전에 탈취한 데이터를 재사용하는 공격을 원천 차단합니다.
3단계 — Signature 생성 (클라이언트 로컬에서만 발생)
여기가 핵심입니다. 클라이언트가 개인키로 서명(Signature) 을 만듭니다.
Challenge (평문)
↓
[해시 함수 적용] → 고정 길이 해시값 생성 (SHA-256 등)
↓
[개인키로 서명 연산]
↓
Signature ← "내가 개인키 소유자"라는 수학적 증명값
중요한 포인트: 개인키는 이 과정 내내 클라이언트 밖으로 나가지 않습니다.
"내가 개인키를 가지고 있다"는 증명만 전송하는 것이에요.
4단계 — Signature 전송
만들어진 Signature를 서버로 전송합니다.
비밀번호 인증과 달리, 민감한 정보 자체는 한 번도 네트워크를 타지 않아요.
5단계 — 서버가 검증
서버가 받은 Signature를 공개키로 복호화해서 검증합니다.
Signature (암호문)
↓
[공개키로 복호화]
↓
복원된 해시값 == Challenge를 직접 해싱한 값?
↓
일치 → 인증 성공
불일치 → 인증 실패
서버 입장에서 이렇게 결론 냅니다.
"Signature를 공개키로 복호화했더니 맞네"
"이 Signature는 대응하는 개인키로만 만들 수 있어"
"즉 상대방은 개인키 소유자 = 신뢰된 사람"
6단계 — 인증 결과
- 검증 성공 → 세션 시작, 접속 완료
- 검증 실패 → 연결 거부
❓ 공개키를 누군가에게 탈취당하면?
결론부터 말하면 — 아무 문제 없습니다.
| 탈취자의 시도 | 결과 |
|---|---|
| 공개키로 서버에 접속 | ❌ 불가 — 서명 생성은 개인키만 가능 |
| 공개키로 Signature 위조 | ❌ 불가 — 수학적으로 역산 불가능 |
| 공개키로 개인키 추출 | ❌ 불가 — 수백~수천 년 연산 필요 |
공개키는 원래 공개해도 되는 키입니다. GitHub 프로필에 올리거나 팀원에게 공유하는 게 일반적인 운용 방식이에요.
⚠️ 진짜 위험한 건 개인키 탈취
공개키 탈취 → 위험도 없음 ✅
개인키 탈취 → 즉시 조치 필요 🚨
개인키가 탈취되면:
- 탈취자가 내 개인키로 Signature를 만들 수 있고
- 서버는 정상 인증으로 판단해버립니다
이런 상황이 생기면 즉시 서버의 authorized_keys에서 해당 공개키를 삭제해야 해요.
개인키를 보호하는 가장 기본적인 방법:
# 개인키 파일 권한을 본인만 읽을 수 있게 설정
chmod 600 ~/.ssh/id_ed25519
권한이 너무 열려 있으면 SSH 데몬이 보안 위협으로 간주해서 인증 자체를 거부하기도 합니다.
🤔 SSH 키 설정하면 비밀번호로는 못 들어가나요?
결론부터 말하면 — 기본적으로 둘 다 됩니다.
SSH 키를 설정해도 비밀번호 인증은 기본적으로 살아있어요.
기본 상태:
비밀번호 인증 ✅ 가능
키 인증 ✅ 가능 ← 둘 다 열려있음
비밀번호 인증을 끄려면?
서버의 /etc/ssh/sshd_config 파일에서 설정할 수 있어요.
# 비밀번호 인증 비활성화
PasswordAuthentication no
# 키 인증만 허용
PubkeyAuthentication yes
# 설정 적용
sudo systemctl restart sshd
실무에서는 어떻게 하나?
| 상황 | 권장 설정 |
|---|---|
| 개인 서버, 외부 접근 가능 | 비밀번호 인증 끄기 권장 |
| 팀 서버, 여러 명 접속 | 비밀번호 인증 끄기 + 키만 허용 |
| 내부망, 보안 요구 낮음 | 둘 다 허용해도 무방 |
보안상 비밀번호 인증은 꺼두는 게 표준 관행입니다.
비밀번호는 브루트포스(무차별 대입) 공격에 취약하거든요.
⚠️ 주의: 비밀번호 인증을 끄기 전에 반드시 키 인증이 정상 동작하는지 먼저 확인하세요.
끄고 나서 키도 안 되면 서버에서 완전히 잠길 수 있습니다.
📝 한 줄 요약
서버가 낸 문제(Challenge)를 개인키로 서명해서 답하고, 서버는 공개키로 그 답이 맞는지 확인한다.
개인키는 단 한 번도 네트워크를 통해 전송되지 않는다.
마치며
SSH 키 인증은 처음엔 복잡해 보이지만, 결국 핵심은 하나예요.
- 개인키 = 나만 가진 도장 (서명 생성)
- 공개키 = 누구에게나 줘도 되는 인감 견본 (서명 검증)
- Signature = 도장으로 찍은 인감 (개인키 소유의 수학적 증명)
이 세 가지만 기억하면 SSH 인증의 90%는 이해한 겁니다. 🎉