SSH 보안 운영: 호스트 키 검증·사용자 키·접근 기록 관리

1장 개념과 보호 목표#

SSH는 원격 로그인과 명령 실행, 파일 전송 등에 보호된 채널을 제공하는 프로토콜입니다. 클라이언트가 서버를 확인하는 호스트 키 검증과 서버가 사용자를 확인하는 인증을 모두 올바르게 설정해야 합니다.

2장 원리와 구분#

호스트 키가 바뀌었다는 경고는 서버 재설치일 수도 있지만 중간자 공격 가능성도 있으므로 신뢰할 수 있는 경로로 지문을 확인해야 합니다. known_hosts 검증을 끄면 암호화 연결이라도 잘못된 상대에게 접속할 수 있습니다. 공개키 인증의 개인키는 서버에 배포하지 않고 안전하게 보관합니다.

퇴사자 키를 authorized_keys에서 제거해도 다른 계정·자동화 작업·점프 호스트에 같은 키가 남아 있을 수 있습니다. 키 지문과 배포 위치를 목록으로 관리하면 회수를 검증하기 쉽습니다. 포트 포워딩과 파일 전송은 셸 로그인 제한과 별도로 허용 범위를 확인해야 합니다.

3장 비교와 판단 기준#

계층	주요 역할	확인 항목
전송	서버 인증·키 설정·암호화	호스트 키 검증
사용자 인증	접속 주체 확인	키·인증 정책·회수
연결	여러 논리 채널	명령·포트 전달·파일 전송 권한

4장 SSH 연결에는 서버와 사용자의 두 확인이 있다#

클라이언트는 호스트 키로 서버를 확인하고 서버는 정해진 인증 방법으로 사용자를 확인합니다. 사용자 공개키 인증이 켜져 있어도 서버의 호스트 검증을 꺼 두면 잘못된 상대에 접속할 수 있습니다. 두 키의 목적과 저장 위치를 구분합니다.

flowchart LR
 C["클라이언트"] --> H["서버 호스트 키 확인"]
 H --> U["사용자 인증"]
 U --> P["계정·명령·경로 권한"]
 P --> S["허용된 세션"]

5장 처음 본 호스트 키를 신뢰하는 방법#

첫 접속에서 받은 키를 저장하는 방식은 이후 변경 탐지에 도움이 되지만 최초 키가 정당한지 확인하는 문제는 남습니다. 신뢰하는 관리 경로로 지문을 확인하거나 조직의 키 배포 정책을 사용합니다. 경고창에 나온 값이라는 사실만으로 신뢰가 생기지 않습니다.

호스트 주소·이름·재설치·키 교체의 기록을 연결합니다. 자동화에는 검증한 호스트 키를 배포하고 무조건 검증을 끄는 설정이 남지 않게 합니다.

6장 호스트 키 변경 경고를 처리하는 순서#

서버 재설치·정상 키 교체·주소 재사용인지와 예상하지 않은 경로 변경인지 조사합니다. 검증된 관리 경로의 새 지문과 비교한 뒤 저장 정보를 갱신합니다. 편의를 위해 이전 항목을 지우고 새 키를 무조건 승인하면 경고의 의미가 사라집니다.

경고 발견 → 변경 원인 확인
→ 신뢰한 경로의 지문 대조
→ 승인한 변경 반영
→ 실제 접속과 기록 검증

7장 사용자 키는 생성·등록·회수를 관리한다#

개인키는 사용자나 자동화의 비밀이고 공개키는 허용 계정에 등록됩니다. 개인키 파일의 암호화·권한·기기·백업을 보호하고 키 소유자와 등록 대상 서버를 남깁니다. 하나의 키를 여러 사람이 공유하면 조사와 회수 범위가 불명확해질 수 있습니다.

개인키가 노출되면 소스에서 삭제하는 일만으로 끝내지 않습니다. 등록된 공개키의 회수, 관련 서버와 사용 기록, 자동화의 대체 자격증명을 함께 처리합니다.

8장 authorized_keys의 등록 범위#

어느 계정에 어떤 공개키를 허용했는지와 적용되는 옵션·제한을 확인합니다. 관리자 계정에 많은 키를 누적하면 최소 권한과 책임 추적이 어려워질 수 있습니다. 사용하지 않는 키와 임시 접속을 정기 검토합니다.

실제 구현의 명령·포워딩·출발지 제한 등을 검토하고 시험합니다. 설정 파일에 제한을 적었다는 사실만으로 모든 세션 경로에서 동일하게 적용된다고 보지 않습니다.

9장 배포 자동화는 전용 계정을 사용한다#

배포에 필요한 명령·디렉터리·서비스만 허용하고 개인 관리자의 광범위한 권한을 그대로 CI에 넣지 않습니다. 비밀은 소스·로그·산출물에 남지 않게 보관합니다. 실패 때 지원 담당자가 키를 복사받는 임시 절차도 보호 대상입니다.

flowchart LR
 CI["배포 작업"] --> K["제한된 전용 자격증명"]
 K --> A["전용 배포 계정"]
 A --> C["허용 명령과 대상 경로"]
 C --> L["실행·결과·감사기록"]

10장 에이전트 포워딩의 권한 경계#

포워딩을 통해 원격 환경에서 인증기의 서명 기능에 접근할 수 있는 경로가 생길 수 있습니다. 개인키 파일을 직접 복사하지 않았다는 사실만으로 안전성을 단정하지 않습니다. 신뢰하지 않는 호스트로의 전달과 필요하지 않은 사용을 제한합니다.

지원 기능·세션·원격 호스트의 위험을 확인하고 필요한 작업만 허용합니다. 관리 기기와 점프 호스트의 접근·로그·권한도 보호해야 합니다.

11장 점프 호스트와 대상 서버의 검증#

점프 호스트를 경유해도 대상 서버의 호스트 검증이 필요합니다. 중간 서버 인증과 최종 대상의 인증을 구분합니다. 중간 관리 계정의 권한과 대상 서버의 권한도 각각 필요한 범위로 제한합니다.

접속의 사용자·기기·경유 경로·대상과 관리 행위를 연결해 조사할 수 있게 합니다. 점프 호스트에 로그인한 기록만으로 실제 대상에서 수행한 모든 작업을 알 수 있는 것은 아닙니다.

12장 포워딩·파일 전달·관리자 전환#

불필요한 포트 포워딩이나 대화형 쉘을 허용하면 제한한 네트워크·업무 경로를 우회할 수 있습니다. 파일 전달·관리자 전환·작업 실행의 필요를 분리해 정하고 실제 설정을 시험합니다. 포트를 바꿨다는 이유로 노출 관리가 끝났다고 보지 않습니다.

작업	확인할 최소 범위
배포	필요한 명령·경로·서비스
운영 점검	필요한 자산·읽기·제한된 변경
긴급 관리	승인·수명·기록·사후 검토
파일 전달	대상 경로·쓰기·접근 정책

13장 키 회수와 장애 복구를 시험한다#

퇴사 키·노출 키·만료된 임시 접속을 회수한 뒤 새 접속이 거부되는지 확인합니다. 기존 세션의 처리와 다른 서버·설정 사본도 조사합니다. 키 교체 실패로 관리자 전체가 잠기지 않도록 제한된 복구 절차를 갖춥니다.

정상 접속 외에 호스트 키 불일치·비허용 키·비허용 명령·불필요한 포워딩·자동화 실패를 시험하면 인증과 최소 권한을 실제 운영으로 연결할 수 있습니다.

14장 적용 사례와 운영 방법#

자동화 계정은 필요한 명령과 대상만 허용하고 퇴사·키 유출 시 즉시 회수할 수 있게 관리합니다. SSH agent forwarding은 중간 호스트가 사용자의 인증 능력을 악용할 수 있는 위험을 검토해야 합니다. 점프 호스트와 중앙 로그를 활용하면 접근 경로와 변경 이력을 관리하기 쉽습니다.

15장 호스트 키는 서버, 사용자 키는 접속자를 확인한다#

SSH의 호스트 키는 접속한 서버가 기대한 상대인지 확인하는 데 사용합니다. 사용자 공개키 인증은 서버가 접속자의 개인키 보유를 확인하는 절차입니다. 두 키의 목적을 혼동하면 known_hosts 경고를 무시하거나 모든 자동화에 하나의 사용자 키를 공유하는 운영이 생길 수 있습니다.

호스트 키가 바뀌면 서버 재설치·키 교체·주소 재사용인지 확인하고 신뢰하는 별도 경로로 지문을 검증합니다. 첫 접속의 신뢰 설정도 중요합니다. 무조건 호스트 검증을 끄는 자동화는 중간자나 잘못된 서버로 접속하는 위험을 남깁니다.

16장 배포 자동화 키의 범위를 최소화하기#

배포 작업에는 개인 관리자 계정의 키보다 전용 계정과 필요한 명령·경로만 허용하는 구성을 검토합니다. 불필요한 포워딩·대화형 쉘·관리자 전환을 제한하고 해당 구현의 설정으로 실제 제한이 적용되는지 시험합니다. 개인키는 저장·로그·CI 산출물에 노출되지 않게 관리합니다.

사고 조사에는 중앙 인증 기록뿐 아니라 대상 서버에서 수행된 행위가 필요합니다. 키 소유자·기기·등록일·회수일을 연결하고 퇴사나 업무 종료 후 authorized_keys와 자동화 저장소의 사본을 정리합니다. 공유 키는 누가 사용했는지 추적을 어렵게 합니다.

에이전트 포워딩은 개인키 파일을 복사하지 않더라도 원격 환경에서 서명 기능이 이용될 수 있는 경로를 만듭니다. 꼭 필요한 범위에만 허용하고 점프 호스트를 쓰는 경우에도 각 서버의 호스트 키와 계정 권한을 검증합니다.

17장 적용 전 확인할 사항#

호스트 키 지문 확인과 변경 승인 절차를 둔다
사용자·자동화 키의 소유자와 만료를 관리한다
접근 범위·에이전트 전달·로그를 점검한다

18장 자주 묻는 질문#

공개키 인증이면 개인키에 암호를 설정하지 않아도 되나요?#

자동화 등 용도에 따라 운영 방식이 달라지지만 유출 시 영향을 고려해야 합니다. 안전한 비밀 저장소와 제한된 권한, 키 회수를 함께 설계해야 합니다.

SSH 키에 비밀번호를 걸면 유출되어도 안전한가요?#

추가 보호가 되지만 비밀번호 강도·암호화 형식과 노출 상황에 따라 위험이 남습니다. 노출 키는 회수·교체하고 사용 흔적을 조사해야 합니다.

호스트 키 경고는 서버 장애를 해결하려면 지워도 되나요?#

변경 원인을 먼저 확인해야 합니다. 신뢰할 수 있는 관리 경로의 지문과 비교한 뒤 검증된 변경만 반영합니다.