ssh 통신의 세부 원리

ssh 는 Secure Shell 의 줄임말로 원격 호스트에 접속하기 위해 사용되는 프로토콜이고 

기본적으로는 22번 포트를 사용하고, ssh 를 기반으로 파일복사 등도 가능합니다.

 

* putty 같은 터미널 프로그램 뿐만 아니라 winscp 같은 프로그램을 이용하면

  ssh 기반으로 파일 전송을 쉽게 활용할 수 있습니다.

 

1995년에 ssh 가 개발되기 전까지 기존 원격 접속은 ‘텔넷(Telnet)’ 방식을 사용했는데,

암호화를 제공하지 않기 때문에 보안상 취약하다는 단점이 있었습니다.

 

실제로 WireShark같은 패킷 분석 프로그램을 이용해서 내 컴퓨터에서 주고받는 패킷을 살펴보면 

telnet 통신 중 전달되는 ID, 비밀번호, 파일 내용 등의 데이터를 쉽게 엿볼 수 있지만

ssh 암호화 기법을 사용하기 때문에, 통신이 노출된다고 하더라도 이해할 수 없는 암호화된 문자로 보입니다.

 

ssh 가 암호화된 통신을 제공하는 핵심 원리는 

public key(공개키), private key(개인키) 를 활용하여

대칭키, 비대칭키를 혼합한 암호화 방식의 구현입니다.

 

<대칭키 방식>
동일한 키 값으로 암호화, 복호화가 가능한 방식

[원문] * [키값 A로 암호화] = [암호문]
[암호문] * [키값 A로 복호화] = [원문]


<비대칭키 방식>
암호화에 사용되는 키와 복호화에 사용되는 키가 서로 다른 방식

[원문] * [키값 A로 암호화] = [암호문]
[암호문] * [키값 B로 복호화] = [원문]

비대칭키 방식 암호화에서 공개키는 암호화를 할 때만 사용할 수 있고,
복호화 때는 키페어를 이루는 개인키로만 복호화가 가능합니다.

* 디피헬만 알고리즘, RSA 알고리즘 은
소인수분해, 이산수학 기반의 대표적인 비대칭키 알고리즘 입니다.

 

ssh 통신을 위한 서버 인증은 아래 단계로 진행이 됩니다.

1. 키페어 생성

ssh 통신을 위해선는 각자(서버와 클라이언트)가 공개키, 개인키를 세트로 생성하고 가지고 있어야 합니다.
각자의 공개키, 개인키 세트를 키페어(key pair) 라고 부르고 
보통 공개키의 경우 .pub 개인키의 경우 .pem 의 파일 형식을 따릅니다.
* AWS 등을 다루다보면 ssh 접속을 위해 내 컴퓨터에 pem 인증서를 관리하게 되는데 그게 바로 개인키 입니다.

2. 서버 -> 클라이언트로 공개키 전달

서버가 클라이언트로 서버공개키를 전달하면
클라이언트는 서버의 공개키로 데이터를 암호화하면 됩니다.

복호화를 위한 서버개인키는 서버에만 저장되어 있기 때문에
클라이언트가 서버공개키로 암호화한 정보를 보내도 서버는 복호화가 가능합니다.

클라이언트가 서버에 ssh 로 처음 접속하게 되면
finger printer(지문)를 등록하겠냐는 메세지를 볼 수 있는데 이때 yes 를 선택하고 접속을 진행하는것이
사실은 서버의 공개키를 클라이언트에 등록하는 과정입니다.
* 보통 클라이언트 내 .ssh/known_hosts 파일에 저장합니다.

3. 클라이언트에서 난수 생성
이것은 데이터 교환전 상호 인증을 위한 난수값 생성입니다.
세션키의 개념은 아닙니다.

3-1. 클라이언트는 추후 서버와 난수값 비교를 위해 난수 해쉬값 생성 후 보관

4. 클라이언트에서는 생성된 난수값을 이미 전달받은 서버 공개키로 암호화

5. 4의 결과물을 서버에 전달

6. 서버는 4의 결과물을 서버 개인키로 복호화

7. 서버는 클라이언트에서 생성한 난수값을 확인

8. 서버는 확인한 난수값을 약속한 해쉬방식으로 해쉬값 생성

9. 서버의 해쉬값과 3-1의 클라이언트 해쉬값을 비교

10. 클라이언트는 서버가 정상 서버임을 확인하였음. (서버 인증 완료)

 

서버 인증을 통해 클라이언트는 서버의 공개키를 획득하였습니다.

이제 반대로 서버가 클라이언트 쪽으로 이상없음을 확인(사용자 인증) 을 할 차례입니다.

 

기본적으로 서버 인증과 원리는 같고, 서로의 역할만 바뀌게 됩니다.

1. 클라이언트 키페어 생성

2. 클라이언트 -> 서버로 공개키 전달
서버는 전달받은 클라이언트 공개키를 .ssh/authorized_keys 파일에 저장합니다.

* 공개키를 기반으로 암호화를 하면, 복호화에는 개인키가 필요합니다
  공개키가 공개되었다고 암호화가 풀리는 것은 아닙니다.
  오히려 공개된 공개키를 통해 이 암호문의 작성자를 확인하는데 도움이 됩니다
  (디지털 서명, 부인방지)

3. 서버에서 난수 생성
3-1. 서버는 추후 클라이언트와 난수값 비교를 위해 난수 해쉬값 생성 후 보관

4. 서버에서는 생성된 난수값을 이미 전달받은 클라이언트 공개키로 암호화

5. 4의 결과물을 클라이언트에 전달

6. 클라이언트는 4의 결과물을 클라이언트 개인키로 복호화

7. 클라이언트는 서버에서 생성한 난수값을 확인

8. 클라이언트는 확인한 난수값을 약속한 해쉬방식으로 해쉬값 생성

9. 클라이언트의 해쉬값과 3-1의 서버 해쉬값을 비교

10. 서버는 클라이언트가 정상 클라이언트임을 확인하였음. (사용자 인증 완료)

 

여기까지가 ssh 통신을 위한 상호 인증 단계입니다.

 

서버 인증을 진행하면서 서버 공개키를 서로 공유하였고,

사용자 인증을 진행하면서 클라이언트 공개키를 서로 공유하였습니다.

그리고 서로가 통신을 맺기로 약속한 상대방이라는 것도 확인하였습니다.

 

이제 클라이언트는 서버 공개키로 데이터를 암호화 시켜서 보내면 서버는 복호화가 가능하고,

반대로 서버는 클라이언트 공개키로 데이터를 암호화 시켜서 보내면 클라이언트는 복호화가 가능합니다.

 

하지만 실제 데이터 암호화 및 통신은 대칭키 방식을 이용해서 이루어집니다.

 

상호 인증 이후에는 서버, 클라이언트 구분 없이 어느 한쪽에서 세션키를 생성하고
이를 기존대로 비대칭키 방식으로 공유합니다.

세션키는 공유가 완료되면, 대칭키로서 작동하고 

양쪽에서는 앞으로 모든 데이터를 동일한 키로 암호화, 복호화해가며 통신하게 됩니다.

 

실제적인 데이터 암호화 통신에 세션키를 이용하는 이유는

비대칭키 방식은 대칭키 방식에 비해 자원을 많이 소모하고 속도가 느리기 때문입니다..

ssh 서비스를 제공하는 서버는 수많은 사용자와 통신을 해야하는데

모든 통신에 대해 비대칭키 방식으로 암복호화를 해가며 통신하기에는 무리가 있겠죠?

 

그리고 보안을 위해서 연결이 종료되고 새로운 연결이 수립될때마다

세션키는 새로 생성하게 됩니다.

 

* 서버와 클라이언트의 공개키, 개인키는 연결때마다 새로 생성되는게 아닙니다.

  클라이언트의 known_hosts 나 서버의 authorized_keys 에 등록된 상대방 공개키는

  실제 키가 갱신되기 전까지 유효합니다.

 

[참고] chatGPT가 설명하는 RSA 키 구현 원리

 

 

[참고자료]

 

https://medium.com/@labcloud/ssh-%EC%95%94%ED%98%B8%ED%99%94-%EC%9B%90%EB%A6%AC-%EB%B0%8F-aws-ssh-%EC%A0%91%EC%86%8D-%EC%8B%A4%EC%8A%B5-33a08fa76596

SSH 암호화 원리 및 AWS SSH 접속 실습

 

https://library.gabia.com/contents/infrahosting/9002/

가비아 라이브러리

 

 

 

https://velog.io/@lehdqlsl/SSH-%EA%B3%B5%EA%B0%9C%ED%82%A4-%EC%95%94%ED%98%B8%ED%99%94-%EB%B0%A9%EC%8B%9D-%EC%A0%91%EC%86%8D-%EC%9B%90%EB%A6%AC-i7rrv4de

SSH 공개키 암호화 방식 접속 원리

 

https://pilyeooong.tistory.com/entry/SSH%EB%9E%80

SSH란 ?