SSH 의 Flowchart

SSH 클라이언트가 서버에 접속(ssh user@host) 할 때의 “표준적인 동작 순서”를 정리함.

• SSH2 기준(RFC로 2006년 표준화)임
• SSH1 (1995년 초 설계된 Protocol Version 1)은 deprecated 상태로 보안상 사용을 하면 안됨.

---

0. TCP 연결

1. 클라이언트 → 서버 TCP connect(host:22) : 포트는 서버 설정에 따라 변경될 수 있음.
2. 아직은 SSH 레벨 암호화 전 (그냥 TCP)

---

1. 프로토콜 버전 문자열 교환

3. 서로 이런 문자열을 주고받음
   • 예: SSH-2.0-OpenSSH_9.x
4. “우리는 SSH2로 대화한다”를 확인하는 단계

어떤 protocol version으로
대화할지 맞추는 단계.

---

2. 알고리즘 협상: SSH_MSG_KEXINIT

KEYINT : Key Exchange Initialization - 키 교환을 위한 알고리즘 협상 시작.

5. 클라이언트가 “내가 지원하는 목록” 전송
6. 서버도 “내가 지원하는 목록” 전송

보통 다음 묶음들을 협상함:

• 키 교환(KEX): (EC)DH 계열
• 서버 호스트키 알고리즘: ed25519 / ecdsa / rsa 등
• 대칭 암호: AES-CTR/GCM, ChaCha20-Poly1305 등
• 무결성(MAC, Message Authentication Code): HMAC 또는 AEAD에 포함 (데이터가 전송중 바뀌지 않았고, 송신자 인증을 같이 수행)
• 압축: none/zlib 등

---

3. 키 교환(KEX) + 서버 인증(Host Key)

7. (EC)DH로 공유 비밀값 K를 “각자 계산” (K 자체를 보내진 않음)
   • 서로 교환하는 건 공개값(A, B) 같은 것들
   • 이를 교환하고 나면 같은 K를 계산할 수 있음.
   • 이 시점에서
     • K를 통한 대칭키 암호를 통한 안전한 채널 생성이 가능해짐.
     • 하지만, 아직 상대방이 신뢰할 수 있는 누구인지 모르는 상태.
8. 서버는 다음을 전송:
   • 자기 호스트 공개키
   • 자기 호스트 비밀키로 키교환관련 데이터의 해쉬값에 서명
     • 데이터는 클라이언트/서버 버전, KEXINIT, DH 공개값, 공유 비밀 K 등 포함
     • 이 데이터와 해쉬값의 관계는 키와 fingerprint와의 관계와 유사.
   • 이 둘을 보내어 내가 진짜 그 서버다”를 증명 요청
   • 서명을 서버공개키로 검증하면, 대응하는 비밀키를 가진 대상임이 확인되는 것임.
9. 클라이언트는 서버 호스트 공개키를 검증
   • 보낸 서버 호스트 공개키로부터 fingerprint 계산하고
   • 이를 ~/.ssh/known_hosts에 있는 fingerprint 와 비교하여 서버의 신원을 확인.
     • 바뀌었으면 경고 및 중단(중간자 공격 의심)
     • 최초 접속인 경우 사용자에게 해당 호스트키를 신뢰할지 여부를 질의: (TOFU: Trust On First Use).
   • 서버 호스트키 신원이 확인된 후, 해당 서버 호스트 공개키를 사용하여 서버가 보낸 서명(signature) 을 검증
     • 서버가 보낸 서명이
     • 해당 서버 호스트 공개키에 대응하는 비밀키로 생성된 것이며,
     • 클라이언트가 키 교환 과정에서 사용된 값들(A,B, K 등) 로부터 독립적으로 계산한 해시값(exchange hash H) 에 대해 생성된 것인지 확인
     • 서버와 클라이언트는 공개적으로 교환된 값(A, B)과 각자의 비밀값으로부터 계산된 공유 비밀 K를 이용해 동일한 해시값 H를 독립적으로 계산할 수 있다.

ECDH(Elliptic Curve Diffie–Hellman) 는
타원곡선(Elliptic Curve) 위에서 수행되는 Diffie–Hellman 키 합의 방식 알고리즘.

---

4. 세션 키 파생 + 암호화 전환

10. 양쪽이 공유 비밀 K와 교환 메시지 해시 H등으로부터

• 대칭 세션 키, (필요 시) MAC 키, IV 등을 KDF로 파생

11. NEWKEYS 메시지를 주고받고
12. 이 순간부터 모든 SSH 패킷이 암호화/무결성 보호됨

참고: KDN은 Key Derivation Function의 약어.

---

5. 사용자 인증 (User Authentication)

13. 이제 “사용자”가 누구인지 인증하는 단계 (서버는 이미 3)에서 인증됨)
    1. 클라이언트가 ssh-userauth 서비스 요청
    2. 서버가 허용 인증 방식 안내(예: publickey, password, keyboard-interactive)

A. 공개키 인증(현재 가장 널리 사용됨)

• 클라이언트가 “이 public key로 시도해도 됨?” 요청
• 서버가 authorized_keys 등을 보고 가능 여부 응답
• 가능하면 서버가 서명 검증용 데이터를 주고,
• 클라이언트가 대응하는 private key 로 서명해서 전송
• 서버가 public key로 검증 : 성공/실패 결정

(키에 passphrase 가 걸려 있으면 이때 로컬에서 입력/에이전트 사용)

B. 비밀번호 인증(옵션)

• 암호화된 연결(tansport connection) 안에서 비밀번호를 보냄.
• 보안/정책상 오늘날에는 거의 쓰이지 않음.

---

6. 연결(세션) 서비스 시작: 채널(Channel) 생성

19. 인증 성공 후 ssh-connection 단계로 진입
20. 하나의 SSH 연결 안에서 channel 을 연다.

여기서 channel은 그 위에서 동작하는 논리적 서비스 단위

대표적인 channel 의 종류는 다음과 같음:

• interactive shell (터미널 접속)
• exec (원격 명령 1회 실행)
• subsystem: sftp (SFTP)
• port forwarding (local/remote/dynamic)

---

7. 데이터 전송 (암호화된 패킷 흐름)

21. 키 입력/출력, 파일, 포워딩 트래픽 등이

• 모두 SSH 패킷 단위로 캡슐화
• 대칭키로 암호화(+무결성/AEAD)

 

---

8. 일정시간 지나면 다시 대칭세션키 교환(Re-key) (장시간 연결 시)

22. 일정 시간/전송량이 지나면 자동으로 다시 KEX 수행
23. 새 세션 키로 교체(보안성 향상)

---

9. 종료

24. 채널 close → 연결 close
25. 세션 키는 폐기

---

전체 과정:

1. TCP 연결
2. 버전 교환
3. 알고리즘 협상
4. (EC)DH 키교환 + 서버호스트키검증
5. 연결 암호화 ON (연 암호화는 대칭키방식)
6. 사용자 인증
7. 채널 열기(쉘/SFTP/포워딩)
8. 통신
9. (필요시) 다시 키교환
10. 종료

---

같이보면 좋은 자료들

2025.08.05 - [utils] - ssh (Secure SHell) 사용 방법

ssh (Secure SHell) 사용 방법

2023.12.27 - [utils/git and github] - [ssh-keygen] ssh 관련 private key와 public key 생성하기.

[ssh-keygen] ssh 관련 private key와 public key 생성하기.

https://ds31x.github.io/wiki/gpg/gpg_term/

GPG 관련 용어