pem 파일을 이용한 SSH 접속 제어

회사 서버에 보안이슈가 있었다.
aws ec2환경에 ssh 원격 접속하기 위해서는 pem파일(개인키)이 필요한데,
회사 공용 PEM 파일 한개를 공통적으로 사용해 한개의 pem이 탈취당한다면 모든 서버접속이 가능해지는 위험이 있었다.

pem을 탈취당하거나 회사의 pem 파일을 가지고있던 직원이 퇴사한다면 어떻게 회사 보안을 유연하게 대처할건가?

해당 문제를 해결하기 위해 개개인의 개인키/공개키 를 발행해 현직자의 공개키를 서버의 authorized_keys 에 담아 접근이 가능하도록 조치(개인의 퇴사나 pem 탈취 인지시 authorized_keys의 공개키를 삭제/수정)를 취했고, master pem 은 임원,팀장만 관리할 수 있도록 조치를 취했다.

조치를 취한 후.. 어떻게 공개키와 비공개키가 매칭이 되는지 ssh에 대해 정리하였다.

---

---

pem 파일이란?

PEM은 Privacy Enhanced Mail의 약자.

PEM은 보안 웹 사이트를 인증하는데 사용되는 인증서를 Base64 인코딩 된 파일이다.

각자의 공개키, 개인키 세트를 키페어(key pair) 라고 부르고
통 공개키의 경우 .pub 개인키의 경우 .pem 의 파일 형식을 따른다.
AWS를 다루다보면 ssh 접속을 위해 내 컴퓨터에 pem 인증서를 관리하게 되는데 그게 바로 개인키다!

• 개인키 생성 명령어 (mac 명령어)

1. ssh-keygen -t rsa -b 2048 -f ~/.ssh/원하는pem 이름
2. 엔터
3. 엔터
   개인키 생성 끝~

• 개인키를 기반으로 공개키를 생성하는 명령어 (mac 명령어)
  openssl rsa -pubout -in 개인키명.pem -out 공개키명.pem

SSH란? , SSH의 장점

SSH(보안 셸, Secure Shell)는 네트워크를 통해 안전하게 통신하기 위한 프로토콜 및 암호화 기술을 제공하는 프로토콜. SSH는 원격 접속 및 데이터 전송을 보호하고 보안을 유지하기 위해 널리 사용된다.

1. 보안 통신: SSH는 민감한 데이터를 전송하는 데 사용되며, 데이터를 안전하게 보호하기 위한 암호화 기술을 제공합니다. 데이터는 암호화되어 전송되므로 중간에 누군가가 데이터를 가로채도 내용을 이해할 수 없다.

2. 원격 접속: SSH는 원격 시스템에 안전하게 로그인하고 명령을 실행할 수 있도록 해주는 도구다.
   원격 시스템에 SSH 서버가 설치되어 있어야 하며, SSH 클라이언트를 사용하여 원격 시스템에 연결하고 명령을 실행 가능.

3. 키 기반 인증: SSH는 사용자 인증을 위해 공개 키 및 개인 키를 사용. 비밀번호 없이 로그인할 수 있으며, 키는 보안적으로 더 강력.

4. 포트 전달: SSH는 포트 포워딩을 통해 로컬 및 원격 시스템 간에 데이터를 안전하게 전달할 수 있다. 이것은 보안된 방법으로 원격 서비스에 액세스하거나 로컬 시스템의 서비스를 원격으로 사용할 수 있는 기능을 제공.

5 .다양한 운영 체제 지원: SSH는 다양한 운영 체제에서 사용 가능하며, Windows, Linux, macOS 등을 포함한 거의 모든 주요 플랫폼에서 지원된다.

6. 유용한 보안 기능: SSH는 호스트 키 검증, 암호화 알고리즘 선택, IP 주소 제한, 세션 관리 등의 보안 기능이 존재.

7. SSH는 네트워크 보안을 강화하고 원격 접속 및 데이터 전송을 안전하게 만드는 데 핵심적인 역할을 한다. 이로써 민감한 정보를 안전하게 관리하고 다른 시스템에 연결할 수 있다.

---

ssh 통신을 위한 서버/클라이언트 내부 상호 인증 구현 단계 정리

클라이언트가 서버쪽으로 이상없음을 확인
1. 키페어 생성
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. 서버는 클라이언트가 정상 클라이언트임을 확인하였음. (사용자 인증 완료)

*서버와 클라이언트의 공개키, 개인키는 연결때마다 새로 생성되는게 아니라,
클라이언트의 known_hosts 나 서버의 authorized_keys 에 등록된 상대방 공개키는
실제 키가 갱신되기 전까지 유효하다.

ssh 통신 참고 링크

---

정리

ssh 가 암호화된 통신을 제공하는 핵심 원리는 public key(공개키), private key(개인키) 를 활용하여
대칭키, 비대칭키를 혼합한 암호화 방식의 구현.

SSH 접속은 해당 개인 키를 사용하여 인증, 개인 키를 사용하여 서버에 접속하면 해당 키에 대한 공개 키가 서버의 ~/.ssh/authorized_keys 파일에 등록되어 있는지 확인해야 한다.
개인 키와 서버에 등록된 공개 키가 일치해야만 접속이 성공.

개인 키와 서버에 등록된 공개 키가 일치하는지 확인하는 작업은 주로 SSH 클라이언트와 SSH 서버 사이에서 자동(ssh 통신을 위한 서버/클라이언트 내부 상호 인증 구현 단계 정리 부분을 다시 보자)으로 처리된다.
SSH 클라이언트는 개인 키를 사용하여 서버에 연결을 시도하면, 서버는 해당 개인 키에 대한 대응하는 공개 키를 찾아서 비교하게되는데, 이 과정은 SSH 프로토콜 자체의 일부다.

따라서 개인 키로 인증이 완료되면 SSH 세션이 서버로 연결되고 해당 키의 권한과 서버 설정에 따라 로그인이 승인된다.

만약 개인 키와 서버에 등록된 공개 키가 일치하지 않는다면, SSH 연결은 실패하고 "Permission denied"와 같은 오류 메시지가 표시된다.

따라서 SSH 연결이 성공하면, 이는 개인 키와 서버에 등록된 공개 키가 정확하게 일치함을 의미한다.
만약 접속에 문제가 있다면 개인 키와 공개 키가 서로 일치하지 않거나, 서버 측에서 개인 키를 인증하도록 제대로 구성되지 않았을 가능성이 있다.