클라우드 Mac SSH 호스트 키 검증과 안전한 교체

개발자가 클라우드 Mac에 처음 접속하면 터미널은 일반적으로 알 수 없는 호스트를 신뢰할지 묻습니다. 수동 접속에서는 yes를 입력하면 되고, CI에서는 StrictHostKeyChecking=no로 설정하면 더 간단해 보이지만, 두 방법 모두 호스트 신원 검증을 우회합니다. DNS나 주소 설정에 오류가 있거나 네트워크 경로가 잘못된 곳으로 연결되면 자격 증명과 빌드 자료가 엉뚱한 시스템으로 전송될 수 있습니다. 올바른 방법은 신뢰할 수 있는 터미널에서 호스트 키 지문을 먼저 확보한 다음, 개발 환경과 자동화 작업이 해당 키만 허용하도록 구성하는 것입니다.

독립적인 신뢰 기준 먼저 수립하기

호스트 키는 “현재 접속한 대상이 의도한 Mac인지”를 증명하는 용도로 사용되며, 사용자 로그인에 사용하는 개인 키와는 다릅니다. Ed25519 호스트 키를 예로 들면, XcodeVM 콘솔에서 제공하는 Web VNC로 로컬 터미널을 열고 대상 시스템에서 공개 키 지문을 확인할 수 있습니다.

sudo ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub -E sha256

SHA256: 값 전체를 기록하고 인스턴스 식별자, 접속 주소, 확인 방법도 함께 남깁니다. 검증 대상인 SSH 연결을 통해서만 이 값을 가져오면 검증 과정이 순환 구조가 되므로 피해야 합니다.

그다음 개발 환경에서 원격 호스트가 현재 제공하는 공개 키를 가져옵니다.

mkdir -p ~/.ssh
chmod 700 ~/.ssh
ssh-keyscan -T 5 -t ed25519 "$MAC_HOST" > ~/.ssh/xcodevm_known_hosts.new
ssh-keygen -lf ~/.ssh/xcodevm_known_hosts.new -E sha256

두 지문을 문자 단위로 비교합니다. 일치하는 것을 확인한 후 파일을 설치합니다.

install -m 600 ~/.ssh/xcodevm_known_hosts.new ~/.ssh/xcodevm_known_hosts
rm -f ~/.ssh/xcodevm_known_hosts.new

ssh-keyscan은 “공개 키를 가져오는” 도구이지 “공개 키를 신뢰할 수 있음을 증명하는” 도구가 아닙니다. 독립적으로 확보한 기준 지문이 없다면 스캔 결과를 운영 환경의 신뢰 파일에 바로 추가해서는 안 됩니다.

known_hosts를 프로젝트별로 분리하기

전역 ~/.ssh/known_hosts는 일상적인 대화형 접속에는 적합하지만, 팀 프로젝트에서는 별도 파일을 사용하는 편이 좋습니다. 이렇게 하면 변경 사항을 명확하게 검토할 수 있고, 개인이 호스트 기록을 정리해도 자동화 작업에 영향을 주지 않습니다.

~/.ssh/config에 별칭을 추가합니다.

Host xcodevm-build
    HostName 192.0.2.10
    User builder
    IdentityFile ~/.ssh/xcodevm_build_ed25519
    IdentitiesOnly yes
    UserKnownHostsFile ~/.ssh/xcodevm_known_hosts
    StrictHostKeyChecking yes
    HashKnownHosts yes
    ServerAliveInterval 30
    ServerAliveCountMax 3

IdentitiesOnly yes를 지정하면 클라이언트가 너무 많은 신원 파일을 차례로 시도하는 문제를 방지할 수 있습니다. StrictHostKeyChecking yes는 알 수 없거나 변경된 키가 감지될 때 즉시 접속을 실패하게 합니다. 접속하기 전에 확장된 설정을 확인하여 다른 규칙이 별칭 설정을 덮어쓰지 않았는지 검증합니다.

ssh -G xcodevm-build |
  grep -E '^(hostname|user|identityfile|userknownhostsfile|stricthostkeychecking) '

같은 프로젝트에서 여러 시스템을 사용한다면 시스템마다 별도의 항목을 저장하고, 내부 변경 기록에 인스턴스 식별자를 남겨야 합니다. 임의로 바뀌는 주소를 포괄적인 별칭 하나로 가리키지 마십시오.

CI에서 지문 고정하기

CI가 특정 개발자의 개인 신뢰 파일을 영구적으로 상속하게 해서는 안 됩니다. 더 안전한 방법은 예상 SHA256 지문을 보호 변수로 저장하고, 작업을 실행할 때마다 키를 스캔해 비교한 뒤 임시 known_hosts 파일을 만드는 것입니다.

set -euo pipefail

: "${MAC_HOST:?MAC_HOST is required}"
: "${EXPECTED_ED25519_SHA256:?fingerprint is required}"

scan_file="$(mktemp)"
known_hosts_file="$(mktemp)"
trap 'rm -f "$scan_file" "$known_hosts_file"' EXIT

ssh-keyscan -T 5 -t ed25519 "$MAC_HOST" > "$scan_file" 2>/dev/null
actual="$(ssh-keygen -lf "$scan_file" -E sha256 | awk '{print $2}')"

if [ "$actual" != "$EXPECTED_ED25519_SHA256" ]; then
  printf '%s
' "SSH host key verification failed" >&2
  exit 1
fi

install -m 600 "$scan_file" "$known_hosts_file"

ssh \
  -o UserKnownHostsFile="$known_hosts_file" \
  -o StrictHostKeyChecking=yes \
  -o IdentitiesOnly=yes \
  "$MAC_USER@$MAC_HOST" \
  'uname -m && sw_vers -productVersion'

개인 키, 예상 지문, 호스트 주소는 각각 별도로 관리해야 합니다. 문제 해결을 위해 로그에 실제 지문을 출력할 수는 있지만, 개인 키 내용이나 접속 비밀번호, 마스킹하지 않은 환경 변수를 출력해서는 안 됩니다.

호스트 키 변경을 올바르게 처리하기

호스트 키는 시스템 초기화, 호스트 키 재생성, 접속 주소 재사용 때문에 변경될 수 있으며, 연결이 잘못된 대상으로 유도되었다는 신호일 수도 있습니다. REMOTE HOST IDENTIFICATION HAS CHANGED가 표시되면 먼저 자동화 작업을 중지해야 하며, 곧바로 기존 기록을 삭제한 후 재시도해서는 안 됩니다.

안전한 키 교체는 다음 순서로 진행합니다.

1. 콘솔에서 인스턴스 식별자, 접속 주소, 최근 작업 내역이 예상과 일치하는지 확인합니다.
2. Web VNC의 로컬 터미널에서 Ed25519 공개 키 지문을 다시 확인합니다.
3. 다른 유지보수 담당자가 이전 지문과 새 지문, 변경 사유를 검토하게 합니다.
4. 원격 공개 키를 스캔하고 새 지문을 검증한 뒤 새로운 신뢰 파일을 생성합니다.
5. 테스트 작업부터 업데이트하고 읽기 전용 접속과 환경 점검을 한 차례 완료합니다.
6. 그다음 운영 작업을 업데이트하고 이전 지문을 폐기합니다.

해시 처리된 기록을 사용한다면 먼저 기존 항목을 찾을 수 있습니다.

ssh-keygen -F "$MAC_HOST" -f ~/.ssh/xcodevm_known_hosts
ssh-keygen -R "$MAC_HOST" -f ~/.ssh/xcodevm_known_hosts

두 번째 명령은 새 지문을 독립적으로 확인한 후에만 실행해야 합니다. 기존 기록을 삭제하는 것은 키 교체 작업일 뿐, 검증 작업이 아닙니다.

체크리스트로 검증 완료하기

운영 환경에 적용하기 전에 최소한 다음 항목을 점검해야 합니다.

부정 테스트도 한 번 수행해야 합니다. 예상 지문을 임시로 잘못된 값으로 바꾸고, 실제 원격 명령이 실행되기 전에 작업이 종료되는지 확인합니다. 이후 올바른 값으로 복원한 다음 읽기 전용 명령, 저장소 접근, 빌드 진입점을 다시 검증합니다. 그래야 보호 조치가 설정 파일에만 존재하는 것이 아니라 실제 실행 과정에 적용되고 있음을 입증할 수 있습니다.

SSH 신뢰 체인에 복잡한 시스템이 필요한 것은 아닙니다. 핵심은 “최초 승인”과 “변경 후 재접속”을 즉석에서 클릭하는 절차가 아니라 검토 가능한 프로세스로 바꾸는 것입니다. 신뢰할 수 있는 터미널에서 기준값을 확보하고, 프로젝트 파일에 고정된 대응 관계를 저장하며, CI가 매번 접속 전에 이를 검증하도록 해야 합니다. 변경이 감지되면 항상 먼저 멈추고 확인해야 합니다. 이러한 절차를 갖춰야 원격 개발과 자동 빌드가 동일하고 명확한 호스트 신원 경계를 공유할 수 있습니다.

자주 묻는 질문