글을 작성하게 된 계기

EC2 서버에 접속할 때, 왜 SSH Host Key 경고 가 발생하는지 궁금해서 이유를 찾아보게 되었고, 알게 된 내용을 정리하기 위해 글을 작성하게 되었습니다.

1. SSH Host Key와 경고

EC2 서버에 처음 접속하면 다음과 같은 SSH Host Key 경고가 발생합니다. 이는 왜 발생할까요?

  
[ec2-user@ip-10-0-1-249 ~]$ ssh ec2-user@10.0.20.218
Connection to 3.38.47.39 closed by remote host.
Connection to 3.38.47.39 closed.
$ ssh ec2-user@3.38.47.39
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:2x63s3m8p1mXFp8zN7Ti8arRAFJoVZPv3ndC7/7yNHQ.
Please contact your system administrator.
Add correct host key in /Users/mac/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /Users/mac/.ssh/known_hosts:26
Host key for 3.38.47.39 has changed and you have requested strict checking.
Host key verification failed.

노출된 서버 IP는 이전 프로젝트에 사용했던 EC2 IP로 현재는 사용하지 않고 있습니다.

SSH Host Key는 서버가 자신을 증명하는 고유한 지문(Fingerprint) 인데요, EC2 인스턴스를 새로 생성하면, 내부적으로 새로운 SSH 서버가 설치되며 새로운 Host Key가 자동으로 생성 됩니다.

Host keys are key pairs, typically using the RSA, DSA, or ECDSA algorithms. Public host keys are stored on and/or distributed to SSH clients, and private keys are stored on SSH servers.

Host Key는 /etc/ssh/ssh_host_* 경로에 저장되며, 각 EC2 인스턴스마다 새로 생성되기 때문에 설사 동일한 Public IP를 재사용하더라도 새로운 서버로 인식합니다. Host Key를 사용해 서버에 접속하면 다음과 같은 과정을 거치는데요, 이 과정에서 이전에 접속했던 서버와 Host Key를 비교 하고, 값이 다를 경우 경고 메시지를 발생시키는 것 입니다.

SSH 클라이언트(ssh ec2-user@3.38.47.39)는 접속할 때 이전 접속 시 저장된 서버의 Host Key와 현재 접속하는 서버의 Host Key를 비교
만약 Host Key가 다르면, SSH 클라이언트는 이 서버가 원래 내가 접속하던 서버가 맞는지 의심하고 경고 메시지 출력

2. 발생할 수 있는 문제점

Host Key가 달라졌을 때, 경고를 무시하면 Man-in-the-Middle(MITM), 신뢰할 수 없는 서버에 대한 자동 로그인 차단 과 같은 문제가 발생하는데, 이에 대해 하나씩 살펴보겠습니다.

MITM
자동 로그인 차단

2-1. MITM

MITM 공격은 공격자가 네트워크상에서 중간에 개입해 가짜 서버를 운영하고, 사용자의 접속을 가로채는 공격 입니다.

In cryptography and computer security, a man-in-the-middle[a] (MITM) attack, or on-path attack, is a cyberattack where the attacker secretly relays and possibly alters the communications between two parties who believe that they are directly communicating with each other, where in actuality the attacker has inserted themselves between the two user parties.

사용자가 SSH를 통해 로그인할 때 기존 서버와 동일한 IP를 가진 가짜 서버가 응답을 보내면, 비밀번호나 SSH 키와 같은 중요한 인증 정보를 유출시키는 그런 공격이죠. 즉, SSH Hot Key 경고가 발생했는데 아무런 조치를 취하지 않으면 사용자는 가짜 서버에 접속할 위험이 있습니다.

공격자는 직접 동일한 IP를 가지지는 못하지만, DNS Spoofing, ARP Spoofing, Proxy Injection, BGP Hijacking 등의 방법을 통해 사용자가 실제 서버가 아닌 가짜 서버에 접속하도록 속이는 방법을 사용할 수 있습니다.

2-2. 신뢰할 수 없는 서버에 대한 자동 로그인 차단

SSH는 ~/.ssh/known_hosts 파일에 이전에 접속한 서버의 Host Key를 저장합니다. 만약 Host Key가 변경되었는데 자동으로 접속을 허용하면, 공격자가 운영하는 악성 서버(Malicious Server)에 접속할 위험이 있고요.

Malware (a portmanteau of malicious software) is any software intentionally designed to cause disruption to a computer, server, client, or computer network, leak private information, gain unauthorized access to information or systems, deprive access to information, or which unknowingly interferes with the user’s computer security and privacy.

공격자는 이 과정에서 사용자의 비밀번호, SSH 개인 키(Private Key), 또는 SSH 세션 내의 민감한 데이터를 가로챌 수 있습니요. 따라서 SSH는 Host Key가 변경되면 자동 로그인을 차단하고, 사용자에게 경고 메시지를 표시하여 수동으로 조치하도록 하는데, 이는 보안상 좋은 방법 이지만 서버를 운영하는 입장 에서는 꽤나 번거롭습니다.

비밀번호 기반 로그인 시 사용자가 입력하는 비밀번호
SSH Agent Forwarding이 활성화된 경우, 사용자의 SSH 개인 키 탈취
터미널에서 입력하는 명령어 및 전송하는 민감한 데이터
SSH Session Hijacking

운영 관점에서 불편한 점은 정상적인 서버 변경이나 재설치 후 장애 발생, SSH 접속 시 로드 밸런서를 거쳐 내부 서버로 연결, 여러 대의 서버를 운영하는 환경에서 서버 교체나 업데이트가 빈번 등이 있습니다.

정상적인 서버 변경이나 재설치 후 장애 발생
- 서버를 재설치하거나 OS를 업데이트하면서 SSH Host Key가 변경
- 이때 자동 로그인(스크립트 기반 접근 등)이 차단되면, 배포/운영 자동화가 중단
- 로드 밸런서 뒤 서버 변경 시 혼란
SSH 접속 시 로드 밸런서를 거쳐 내부 서버로 연결
- 백엔드 서버가 교체되면 Host Key가 바뀌어 인증 오류
- 서버 변경이 의도된 것임에도 불구하고 매번 수동으로 처리해야 하는 부담
- 대규모 시스템에서 관리 부담 증가
여러 대의 서버를 운영하는 환경에서 서버 교체나 업데이트가 빈번
- 모든 관리 노드에서 known_hosts를 수동으로 업데이트
- 이를 자동화하지 않으면 유지보수 부담

3. 해결책

해결책은 간단한데요, 경고 메시지에 나와 있는 대로 변경된 Host Key를 삭제하고, 새로운 Host Key를 등록하면 됩니다. 하지만 이는 서버가 적은 환경 에서는 큰 문제가 되지 않지만, 대규모 서버 환경에서는 번거로운 작업이 될 수 있습니다.

$ ssh-keygen -R 3.38.47.39

시간이 된다면 ssh-keygen 명령어도 가볍게 다루어 보겠습니다.

따라서 운영 관점에서, 서버가 많아졌을 때의 해결책이 필요한데요, 이를 위해 다음과 같은 방법을 고려할 수 있습니다.

StrictHostKeyChecking 옵션 조정
특정 서버의 Host Key만 삭제 후 재등록
SSH CA(@cert-authority) 방식 활용

3-1. StrictHostKeyChecking 옵션 조정

새 서버의 키는 자동으로 저장하지만, 기존 키와 다를 경우 경고를 표시하도록 설정할 수 있습니다.

  
$ ssh -o StrictHostKeyChecking=accept-new user@server

3-2. 특정 서버의 Host Key만 삭제 후 재등록

특정 서버의 Host Key가 변경된 경우, 기존 키를 삭제한 후 다시 등록할 수 있습니다. Bastion 서버나 특정 서버에 접속할 때 사용할 수 있습니다.

  
$ ssh-keygen -R server_ip_or_hostname
$ ssh user@server  # 새 키를 확인한 후 수동으로 저장

3-3. SSH CA(@cert-authority)

OpenSSH의 @cert-authority 기능을 사용하면, 개별 서버의 Host Key가 변경되더라도 인증 기관(CA)이 신뢰되면 문제없이 접속할 수 있습니다.

중앙에서 Host Key 관리
/etc/ssh/ssh_known_hosts 파일에 CA를 등록

4. 정리

왜 최초로 EC2 서버에 접속할 때, SSH Host Key 경고가 발생하는지 알아보았습니다. 이는 EC2 인스턴스를 생성하면, 새로운 Host Key가 자동으로 생성되기 때문인데요, 궁금하니까 이런 것도 찾아보네요.

Host Key Warning은 왜 발생할까?