Apple: SSH 및 FileVault

 (keith.github.io)
1P by GN⁺ | ★ favorite | 댓글 1개
  • FileVault 활성화 시 macOS 부팅 중, 데이터 볼륨이 잠김 상태임
  • OpenSSH 구성 파일이 데이터 볼륨에 저장되어 잠김 동안 기존 인증 방식이나 셸 접근 불가함
  • Remote Login(SSH)이 활성화되어 있으면, 암호 인증으로 원격 네트워크에서 데이터 볼륨 잠금 해제가 가능함
  • 이 방식은 SSH 세션 즉시 허용이 아니라, 잠금 해제 후 SSH 연결이 일시적으로 끊어짐 현상 발생함
  • 데이터 볼륨이 마운트되고 필요한 서비스가 시작된 뒤 SSH 접근 가능해짐

Apple의 SSH와 FileVault 연동 개요

  • FileVault가 활성화된 macOS에서는 데이터 볼륨이 잠겨 부팅 시점 이후에도 해당 볼륨 접근이 불가한 상황 발생함
  • OpenSSH의 모든 시스템 및 계정별 설정 파일이 데이터 볼륨 내에 저장되어 있음으로, 데이터 볼륨 잠김 상태에서는 일반적으로 구성된 인증 방식이나 셸 접근이 비활성화됨

Remote Login(SSH)로 원격 잠금 해제

  • 부팅 후 데이터 볼륨이 잠긴 상태에서도, Remote Login(SSH 로그인)이 활성화되어 있으면 네트워크를 통한 암호 인증 시도를 허용함
  • 사용자는 SSH를 이용해 원격에서 암호 인증을 통해 FileVault로 잠긴 볼륨을 해제할 수 있음

잠금 해제의 제한 사항 및 프로세스

  • 이 기능을 통해 데이터 볼륨 잠금은 해제되지만, SSH 세션이 바로 연결되는 것은 아님
  • 데이터 볼륨이 잠금 해제되는 즉시, macOS는 볼륨 마운트 및 이에 의존하는 지원 서비스 가동을 완료하는 동안 SSH 연결이 잠시 끊김 현상 발생함
  • 해당 절차 완료 이후에 SSH, 그리고 다른 활성화된 서비스의 정상 이용 가능함

macOS 26 Tahoe 버전의 도입

  • SSH를 통한 데이터 볼륨 원격 잠금 해제 기능은 macOS 26 Tahoe 버전에서 최초로 도입됨

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견

  • FileVault를 활성화하면 데이터 볼륨이 잠기고, 계정 비밀번호로 인증할 때까지 부팅 중이나 부팅 후에 접근이 불가능함을 경험함, macOS용 OpenSSH는 시스템, 계정별 설정 파일 모두를 데이터 볼륨에 저장함. 그래서 FileVault가 걸린 동안에는 보통 설정한 인증 방식이나 쉘 접근이 불가함. 그런데 Remote Login을 활성화해두면, SSH를 통한 비밀번호 인증이 이런 상황에서도 가능해짐. 이것으로 네트워크상에서 원격으로 데이터 볼륨 잠금을 해제할 수 있음. 다만 바로 SSH 세션이 이어지는 것은 아니고, SSH를 통한 볼륨 해제 후에는 macOS가 볼륨 마운트와 서비스 재시작을 마칠 동안 잠깐 연결이 끊어졌다가 이후부터 SSH(및 기타 서비스)가 정상적으로 사용 가능해짐. 정말 반가운 변화임

  • 이제 정전 뒤 자동 재부팅 후 물리적으로 키보드를 연결하지 않고도 완전한 원격 맥 미니 서버를 운영할 수 있다는 뜻인지 궁금함. 정말 멋진 변화임

    • 직접 테스트 진행 결과 완벽하게 동작함을 확인함
      1. General > Sharing > Remote Management 활성화
      2. 재부팅 후 SSH 접속 시 "이 시스템은 잠겨 있습니다. 잠금 해제를 위해 계정 이름과 패스워드를 사용하세요. 해제하면 정상 접속 가능"이라는 메시지 확인
      3. 성공적으로 SSH로 인증하면 SSH 연결이 끊기고, "시스템 잠금 해제 완료. 이제 SSH로 정상적으로 인증 가능" 메시지 표시
      4. 다시 SSH 접속하면 정상적으로 들어올 수 있음
    • 다음 커맨드도 사용 가능함 
      sudo fdesetup authrestart -delayminutes -1
      이 방법은 다음 재부팅 한 번만 선택한 계정으로 자동 로그인하게 해줌. 비밀번호 입력이 필요 없어서 편리하지만 보안적으로 리스크가 있음. 상황에 따라 용인할 수 있음
    • 진심으로 궁금한 점인데, 왜 서버 운영체제로 macOS를 선택하는지 묻고 싶음. 나 역시 맥 미니 하드웨어는 정말 매력적이라고 생각해 고민한 적 있음. 하지만 macOS 대신 Linux를 돌리는 게 망설여짐
    • 예전에 CI 머신에서 실수로 FileVault를 활성화한 동료 때문에 직접 서버를 랙에서 빼고, 먼지 닦고, 모니터/키보드 꽂아서 로그인‧해제까지 해야 했던 경험이 있음. 이제 SSH로 잠금 해제가 가능하니 또 그런 일이 생겨도 원격에서 바로 해결 가능해짐
    • FileVault가 켜진 원격 맥을 정전 이후 온라인으로 올리려면 물리적 로그인 필수였던 불편함을 잘 알고 있음. 재부팅 후 GUI로 완전히 원격 접속까지 가능한지 궁금함. 집 실험실용 맥 미니 장만을 고민 중인데, 혹시 필요하다면 KVM 같은 리모트 장치를 써야 하는지까지 생각함

  • 이 변화는 회사 등 비(非)개인용 Mac 환경에 엄청난 변화임을 언급하고 싶음. Mac Mini의 가성비와 품질이 자동화 용도로 꽤 쓸만하고, 실제 회사에서도 이슈만 아니었으면 점진적으로 도입을 늘리고 있었음. FileVault 이슈가 발목을 잡던 주요 원인이었음

    • Mac을 범용 서버로 쓰는 것에 관심이 있었음. 서버로 쓰기 더 쉽게 관리하려면 추가적으로 하는 설정이나 방법이 있는지 궁금하고, 맥 전용 워크로드를 올리는지, 아니면 컨테이너 기반 리눅스 워크로드도 운영하는지 질문함

  • macOS 26 Tahoe에서 SSH를 통한 데이터 볼륨 언락 기능이 추가된 점 반가움. 최근 Tahoe 업그레이드 후 SSH 접속이 예상외로 됐던 게 여기서 비롯된 변화임을 알게 됨. 평소엔 맥을 끄지 않지만, 가끔 원격에서 접속해야 할 때 전날 대규모 업데이트 설치했단 사실을 잊고 당황하곤 했음. 이번 변화로 걱정이 줄어듦

  • 이제 시스템 볼륨에는 FileVault 암호화가 적용되지 않는다는 뜻인지 추측함. 시스템 볼륨이 읽기 전용, 내용 고정, 모든 macOS에서 동일하기 때문이라 생각함. 네트워킹까지 모두 부팅하고 데이터 볼륨 암호 해제가 요구되는 논리도 설득력 있음. FileVault가 굳이 시스템 볼륨 암호화를 건너뛴다면 매우 합리적인 변화라 생각함. 오버레이 기술로 시스템 파티션에 쓰는 척하지만 실제로는 데이터 볼륨에 기록하는 경우가 많은 점도 언급함

    • WiFi 비밀번호 같은 정보도 데이터 볼륨에 저장되므로 네트워킹이 항상 되는 건 아님을 짚음

  • 흥미로운 변화이지만, 데이터 볼륨에 쉘이 저장된 경우와 같이 그래픽 세션에서 발생하는 ‘경쟁 조건’ 이슈가 SSH에도 적용될지 궁금함. 예를 들어, 재시작하며 앱 복원을 선택 시 모든 볼륨이 마운트되기 전에 앱이 먼저 떠버리면 쉘 실행이 실패하는 상황이 실제로 있었음. Nix로 쉘 설치 시 주로 발생. SSH에서도 동일 문제 발생 가능성이 높아 보임. 시스템 차원에서 이런 이슈가 해결됐는지 궁금함

    • SSH로 언락하는 과정에서는 접속을 데이터 볼륨 언락 직후 종료시킴. 볼륨 마운트가 끝난 뒤, 다시 접속하면 쉘이 실행되므로 이런 문제 없음. Nix store를 사용할 때는 wait4path을 이용하는 shim으로 해결해본 경험 있음. shim을 미리 데이터 볼륨의 알려진 경로에 설치해두고 로그인 쉘로 지정하면 됨
    • Apple은 장치 언락 후 모든 프로세스를 종료(“userspace reboot”)하는 방법으로 이 문제를 원천 차단함
    • 재연결로 대부분 해결될 문제라 생각함. 특히 SSH에서는 네트워크 재시도 메커니즘이 일반적으로 있기 때문에 큰 문제 아님
    • 이 케이스는 OS에 오래전부터 포함된 wait4path 유틸리티로 해결 가능하다고 봄

  • 정말 반가운 변화라고 생각함. 이 기능 때문에 FileVault를 꺼두고 있었던 입장임

  • Omarchy(방향성이 강한 Arch 구성)의 전체 디스크 암호화(Full Disk Encryption)를 실험하며 메인 VM으로 쓸 수 있을지 고민함. 직접 물리적으로 작업 시 GPU 가속 데스크탑과 모든 장기 연산 작업 접근이 가능함. 하지만 몇 주 동안 원격에 있다 머신이 리부팅되면, 디스크 암호를 반드시 물리적으로 입력해야 하는 문제로 시도 자체가 망설여졌음. ProxMox로 구동 중이지만 USB 패스스루 등 설정 때문에 표준 VNC 뷰어로는 접근이 불가능함. Omarchy가 macOS처럼 원격 언락을 시도해볼지 궁금함

    • 리눅스에서는 아주 오래전부터 initramfs에 dropbear를 넣어 원격 잠금 해제 기능을 구현할 수 있었음

  • 분명히 어딘가에 취약점 공격 경로가 존재할 거라 생각함

    • 패스워드 기반 SSH의 일반적인 보안 위험 외에 딱히 추가적인 리스크가 떠오르지는 않음. 만약 걱정된다면 Wireguard 같은 방화벽 뒤에 두는 걸로 충분히 개선 가능하다고 봄. 이전엔 Mac 서버에서 FileVault를 꺼야 했기에, 비교하면 훨씬 반가운 변화라 생각함
    • Blastdoor와 같은 보안 이슈 경험상 이런 변화에는 늘 조심스럽게 접근하게 됨

  • 이 기능이 없어서 홈랩용으로 포기했던 맥 미니가 있으나, 이제 모든 게 달라짐을 느낌

답변달기