리눅스-RHEL OpenSSH 개념 & 원리

목차

OpenSSH란?
  - 소개
  - 기존 원격 접속 도구의 문제
  - SSH의 필요성과 OpenSSH의 역할
SSH 접속
  - 공개키 기반 인증 – 사전 작업과 인증 원리
    - 사전 작업
    - 인증 원리
  - SSH 접속시 동작 순서

※ OpenSSH란?

소개

OpenSSH는 원격 시스템에 안전하게 접속하기 위해 사용하는 SSH(Secure Shell) 프로토콜을 구현한 대표적인 오픈소스 도구임.
OpenBSD 프로젝트에서 개발되었으며, BSD 라이선스를 기반으로 자유롭게 배포되고 있음.

---

기존 원격 접속 도구의 문제

초기에는 telnet, rsh, rcp 같은 원격 접속 도구들이 주로 사용되었음.
하지만 이들 도구는 **암호화 없이 평문(plain text)**으로 데이터를 전송했기 때문에 **패킷 스니핑(packet sniffing)**과 같은 공격에 매우 취약했음.
즉, 네트워크 상에서 아이디, 비밀번호, 명령어 등이 그대로 노출될 수 있었음.

---

SSH의 필요성과 OpenSSH의 역할

이러한 보안 문제를 해결하기 위해 등장한 것이 **SSH(Secure Shell)**임.
SSH는 네트워크 통신을 암호화하여 데이터 보호는 물론, 사용자 인증 과정도 안전하게 처리할 수 있음.

OpenSSH는 이 SSH 프로토콜을 오픈소스로 구현한 프로젝트로, 현재 대부분의 리눅스/유닉스 시스템에서 기본 설치됨.
서버 관리자는 sshd(서버 데몬)와 ssh(클라이언트 프로그램)를 이용해 보안 접속 환경을 구성함.

또한 OpenSSH는 scp, sftp 등의 보안 파일 전송 도구도 함께 제공하여, 단순한 접속뿐 아니라 안전한 파일 전송까지 지원함.

 

※ SSH 접속 

공개키 기반 인증 – 사전 작업과 인증 원리

사전 작업: 키 교환을 통한 신뢰 설정

공개키 기반 인증을 사용하기 위해서는 클라이언트와 서버가 서로의 공개키를 교환하는 사전 작업이 필요함.
이 작업을 통해 서로 신뢰할 수 있는 상대인지 확인하고, 이후의 인증 과정이 보안적으로 이루어질 수 있게 함.

• 클라이언트 → 서버:
  사용자의 공개키를 서버에 등록함 → ~/.ssh/authorized_keys 파일에 추가
  ssh-copy-id 명령을 사용하거나 수동으로 등록할 수 있음
• 서버 → 클라이언트:
  서버는 접속 시도 시 자신의 **호스트 공개키(host public key)**를 클라이언트에게 제공함
  클라이언트는 이를 ~/.ssh/known_hosts에 저장하여 다음 접속부터 서버의 신뢰 여부를 검증함

이러한 키 교환 과정을 통해 MITM(중간자 공격) 방지와 사용자 인증 기반의 접속 제어가 가능해짐.

인증 원리: 비대칭 키 서명 검증

공개키 인증 방식은 비대칭키 암호화를 기반으로 동작함.
즉, 공개키와 개인키라는 서로 다른 두 개의 키 쌍을 이용하여 인증을 수행함.

• 클라이언트는 자신의 개인키로 서명(signature)을 생성하고,
• 서버는 사전에 등록된 클라이언트의 공개키로 서명을 검증함.

 

SSH 접속시 동작 순서

클라이언트에서 ssh user@ServerDomainUrl

1. 클라이언트 → 서버 접속 시도

• TCP 22번 포트로 SSH 연결 시도
• 클라이언트는 서버의 **호스트키(공개키)**를 받음
  → 클라이언트 로컬의 ~/.ssh/known_hosts에 등록된 키와 비교
  → 일치하면 계속 진행, 처음 접속하는 서버라면 공개키 저장, 이미 접속한 서버라면 다르면 경고 또는 차단됨

 

처음 접속하는 서버라면

• ~/.ssh/known_hosts에 해당 서버 호스트키가 없음
• SSH는 경고 메시지 출력:
• 사용자가 yes 입력 시 서버의 호스트키를 known_hosts에 추가 후 접속 진행

[KaysQuo@Client ~] ssh KaysQuo@ServerDomainUrl

The authenticity of host 'server' can't be established.
ECDSA key fingerprint is SHA256:xxxxx
Are you sure you want to continue connecting (yes/no)?

 

이미 접속한 서버라면:

 

• known_hosts에 저장된 키와 서버가 보낸 호스트키를 비교
• 일치하면 정상 진행
• 불일치하면 경고 (MITM 공격 가능성 경고)

[KaysQuo@Client ~] ssh KaysQuo@server:/home/KaysQuop

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

 

2. 서버가 인증 방식 요청

• 서버는 클라이언트에게 어떤 인증 방식을 지원하는지 알림
  (예: publickey, password, keyboard-interactive 등)

3. 클라이언트가 자신의 공개키 중 하나를 서버에 제시

   서버가 사용자 계정에 등록된 키들 중에 클라이언트가 해당 개인키를 갖고 있는지 증명하라고 요청함

사전 신뢰를 위한 키교환 했을때의 키를 가지고 있는지에 대한 여부 확인

• 서버는 이 공개키가 ~/.ssh/authorized_keys에 등록되어 있는지 확인함

4. 서버가 challenge (인증용 데이터) 생성

• 서버가 임의의 데이터를 만들고, 그 데이터를 클라이언트에게 서명해서 보내라고 요청함

5. 클라이언트가 자신의 개인키로 서명 생성 후 서버에 보냄

• 클라이언트는 로컬의 개인키(~/.ssh/id_rsa 등)를 사용해 challenge에 서명함

6. 서버가 등록된 공개키로 서명 검증

• 서명이 유효하면 클라이언트는 인증 성공
• 그렇지 않으면 인증 실패

즉, 개인키를 가진 사용자만 인증을 통과할 수 있음. 공개키만으로는 인증 불가.