Terminus 모바일 앱에서 여러 대의 라즈베리 파이 서버에 SSH 키 인증으로 접속하는 방법에 대한 궁금증에서 시작하여, SSH 키 인증의 근본적인 작동 원리를 탐구했습니다. 평소에는 비밀번호로 접속했지만, 보안과 편의성을 위해 키 기반 인증으로 전환하면서 발생한 의문들을 하나씩 풀어가는 과정이었습니다.

같은 클라이언트가 여러 서버에 SSH 키 인증으로 접속하기: SSH 키 인증의 흐름 파헤치기

학습 주제

오늘 공부한 주제: SSH 키 인증 방식의 클라이언트-서버 간 통신 흐름 및 다중 서버 접속 시 공개키 관리
대화 제목: 같은 클라이언트가 여러 서버에 키 인증 방식으로 ssh 접속하려면 - SSH 키 인증의 흐름
학습 날짜: 2026년 2월 7일

질문과 탐구

처음에는 "Terminus에서 라즈베리 파이 3대에 각각 SSH 접속할 때, 같은 SSH 키 하나로 3대 모두 접속해도 괜찮은가?"라는 단순한 질문에서 출발했습니다. 단순히 '된다, 안 된다'를 넘어, 왜 그렇게 동작하는지, 그리고 그 작동 방식의 핵심에는 무엇이 있는지 궁금했습니다.

주요 질문들:
- Terminus에서 여러 대의 서버에 접속할 때, 단 하나의 SSH 키 쌍으로 충분한가?
- SSH 키 인증 과정에서 '공개키 주입'은 정확히 어떤 의미이며, 왜 필요한가?
- 공개키는 접속 시에 알려주는 것이 아니라 왜 미리 서버에 등록해야 하는가?
- SSH 키 인증의 실제 작동 메커니즘은 무엇인가? (해독 vs. 서명/검증)

핵심 학습 내용

SSH 키 인증 방식의 핵심을 다음과 같이 정리할 수 있었습니다.

키 재사용의 실용성:
- Terminus와 같은 클라이언트에서 하나의 SSH 키 쌍(개인키 + 공개키)을 생성하여, 그 공개키를 접속하려는 여러 서버(여기서는 라즈베리 파이 3대)의 ~/.ssh/authorized_keys 파일에 모두 등록하면, 동일한 키로 모든 서버에 접속할 수 있습니다.
- 기술적으로는 문제가 없으며, 집에서 개인적으로 사용하는 환경에서는 키 하나를 재사용하는 것이 충분히 실용적인 선택입니다. 다만, 더 높은 보안을 위해서는 서버별로 다른 키를 사용하는 것이 최선책입니다.
'공개키 주입'의 정확한 의미:
- 스마트폰(예: Terminus 앱)이나 PC에서 SSH 키 쌍을 생성하고, 그 중 개인키는 절대 외부로 노출하지 않고 클라이언트에 안전하게 보관합니다.
- **공개키의 내용(문자열)**만 복사하여 접속하려는 각 서버의 ~/.ssh/authorized_keys 파일에 붙여 넣는 것을 '공개키 주입'이라고 합니다.
- 이를 통해 클라이언트의 개인키와 서버에 등록된 공개키가 쌍을 이루어 비밀번호 없이 안전하게 접속할 수 있게 됩니다.
공개키 사전 등록의 필요성:
- SSH 인증은 단순히 통신 내용을 암호화하는 것이 아니라, **"어떤 클라이언트가 접속하는지 신원을 확인"**하는 것이 주된 목적입니다.
- 서버는 미리 **"어떤 공개키를 가진 클라이언트만 허용할 것인지"**에 대한 화이트리스트를 authorized_keys 파일에 만들어 두어야 합니다.
- 접속 시, 서버는 클라이언트가 제시하는 증명(서명)이 이 화이트리스트에 등록된 공개키와 일치하는지를 검증합니다. 즉, 공개키는 접속 시마다 보내는 정보가 아니라, 미리 승인 목록에 등록해두는 용도입니다.
SSH 키 인증의 실제 흐름 (핵심: 서명과 검증):
- 이전에는 '해독'이라는 개념으로 이해하려 했으나, 실제로는 **'서명(Signature)'과 '검증(Verification)'**의 과정입니다.
- **서버(파이)**는 매번 새로운 난수 r (챌린지)을 생성하여 클라이언트에게 보냅니다.
- **클라이언트(폰)**는 받은 난수 r에 대해 자신의 **개인키(sk)**로 서명하여 sig 값을 만듭니다. 이때 개인키는 절대 외부로 나가지 않습니다.
- 서버는 클라이언트로부터 받은 sig와 자신이 가진 **공개키(pk)**를 사용하여, sig가 실제로 r에 대한 올바른 서명인지 검증합니다.
- 검증이 성공하면, 서버는 클라이언트가 해당 공개키에 대응하는 개인키를 가지고 있음을 증명한 것으로 판단하고 로그인을 허용합니다.
```
# SSH 키 인증 흐름
## 0. 사전 준비 (1회)
- 클라이언트: 개인키(sk), 공개키(pk) 생성
- 서버: 클라이언트의 공개키(pk)를 `~/.ssh/authorized_keys`에 저장

## 1. 서버 → 클라이언트
- 서버: 난수 'r' 생성 (챌린지)
- 서버: 'r'을 클라이언트에게 전송

## 2. 클라이언트
- 클라이언트: 'r'에 대해 개인키(sk)로 서명하여 'sig' 생성
- 클라이언트: 'sig'를 서버에게 전송

## 3. 서버
- 서버: 공개키(pk)로 'sig'가 'r'에 대한 올바른 서명인지 검증
- Verify(pk, r, sig) → true (인증 성공) / false (인증 실패)
```
'서명'과 '검증'의 정확한 의미:
- 서명: 메시지에 대해 개인키로만 만들 수 있는 위조 불가능한 수학적 증명값을 생성하는 것입니다. 이는 "이 메시지는 내가 만들었다"는 증거가 됩니다.
- 검증: 공개키를 이용하여, 생성된 서명이 정말 해당 공개키에 대응하는 개인키로 만들어진 것인지 확인하는 과정입니다. 이는 "그 증명이 진짜인지 확인"하는 행위입니다.
- 여기서 해시 함수의 역할은 메시지의 무결성을 확인하는 것이며, 서명은 해시 값에 개인키로 특수한 수학 연산을 가한 결과입니다. 검증은 공개키로 이 연산이 올바르게 수행되었는지 확인하는 판별 과정이지, 해시를 역으로 복원하는 과정이 아닙니다.

이해한 내용

이번 대화를 통해 SSH 키 인증이 단순히 키 파일을 주고받는 것이 아니라, 개인키와 공개키의 비대칭 암호화 원리를 기반으로 한 '챌린지-응답' 방식의 신원 증명 메커니즘임을 명확히 이해하게 되었습니다.

새로 알게 된 것: SSH 인증의 핵심이 '해독'이 아닌 '서명과 검증'이라는 점, 그리고 공개키는 서버에 미리 등록하여 '허용 목록' 역할을 한다는 점을 새롭게 알게 되었습니다.
이전 지식과의 연결: 공개키 암호학에 대한 기본적인 이해는 있었지만, 그것이 실제 인증 시스템에서 어떻게 '신원 증명'이라는 형태로 구현되는지에 대한 구체적인 그림이 그려졌습니다. 이는 TLS, JWT 서명 등 다른 보안 기술에서도 유사한 패턴으로 적용될 수 있겠다는 확신을 주었습니다.
개념 정리:
- 개인키(sk): 나만이 가진 비밀 열쇠. 절대 외부에 노출되면 안 되며, 서명 생성에 사용됩니다.
- 공개키(pk): 누구나 가질 수 있는 열쇠. 서버에 등록되어 인증의 대상이 되며, 서명 검증에 사용됩니다.
- 서명(sig): 개인키로 메시지(난수 r)에 대해 생성된 수학적 증명값.
- 검증: 공개키로 서명이 메시지에 대한 올바른 증명인지 확인하는 과정.

실전 적용

이번 학습 내용을 바탕으로 다음과 같은 실전 적용을 계획하고 있습니다.

이 지식을 어디에 적용할 수 있을지:
- 개인 서버(라즈베리 파이, 개인 VPS 등)에 SSH 키 기반 접속 설정 강화.
- GitHub, GitLab 등 Git 호스팅 서비스의 SSH 키 관리.
- Kubernetes 등 클라우드 환경에서의 인증 메커니즘 이해.
- JWT(JSON Web Token)와 같은 보안 토큰의 서명/검증 원리 이해.
실습 계획:
- 다른 라즈베리 파이나 AWS EC2 인스턴스에 동일한 SSH 키로 접속을 시도해보고, authorized_keys 설정이 올바르게 동작하는지 확인.
- 개인 PC에 여러 개의 SSH 키 쌍을 생성하고, 각 키를 다른 서버에 등록하여 개별적으로 접속해보는 실습.
응용 아이디어:
- 단순 접속을 넘어, SSH 터널링이나 포트 포워딩 시 키 인증의 역할을 이해하고 활용.
- 보안 감사 시, SSH 키 관리 정책의 중요성을 인식하고 적절한 관리 방안 마련.

추가 학습 계획

이번 학습을 통해 SSH 키 인증의 기본 원리를 탄탄히 다졌지만, 더 깊이 탐구하고 싶은 부분들이 생겼습니다.

더 깊이 공부하고 싶은 부분:
- SSH 프로토콜의 상세한 단계별 동작 (키 교환, 인증 방식 등)
- 다양한 SSH 암호화 알고리즘 (RSA, ECDSA 등)의 차이점 및 보안성
- SSH 키 생성 시 권장되는 옵션 및 보안 설정
- Agent Forwarding의 작동 원리 및 보안 고려사항
관련 자료 찾기:
- SSH 공식 문서 (OpenSSH)
- RFC 문서 (e.g., RFC 4251, RFC 4253)
- 공개키 암호학 관련 서적 및 온라인 강의
다음 학습 주제: SSH Agent Forwarding 또는 TLS 클라이언트 인증 방식에 대해 공부해볼 예정입니다.

참고 자료

ChatGPT 대화 전체 내용
SSH 프로토콜 관련 RFC 문서