Lobsters

Setting up SSH keys on macOS with Touch ID

macOS에서 Touch ID로 SSH 키 설정하기

macOS Secure Enclave에서 추출할 수 없는 SSH 키를 만들고 Touch ID로 서명하는 방법을 소개합니다. 내장 도구 세 가지로 설정하며, 재부팅 뒤 에이전트에 키를 다시 등록해야 하고 Mac을 잃으면 해당 키도 복구할 수 없습니다.

에디터 노트

키를 기기 밖으로 내보내지 않는 대신 기기 고장 때 복구할 길도 사라집니다. 글이 보여주는 선택은 분명합니다. `bio`는 매번 Touch ID를 요구하고 `none`은 인증 단계를 생략하며, 어느 쪽도 키 백업 문제를 해결하지 않습니다. 댓글에서 1Password의 동기화 방식과 기기별 키 분리, SSH 인증서가 대안으로 나옵니다. 각 방식은 키 배포와 접근 관리의 조건이 다릅니다. 글의 절차는 macOS 기본 도구만으로 설정할 수 있다는 점을 구체적으로 보여주지만, 제공자 라이브러리의 동작 일부와 빈 PIN 처리 이유는 글쓴이도 추정으로 제시합니다. 이를 확정된 Apple 문서 설명과 구분해야 합니다.

AI 요약

macOS의 Secure Enclave에 개인 키를 생성하면 키 원문을 파일로 저장하거나 외부로 내보내지 않고 SSH 인증에 사용할 수 있습니다. 글은 이 키를 Touch ID로 보호하고 GitHub 같은 서비스에 등록하는 빠른 설정법을 먼저 설명한 뒤, Apple의 도구와 SSH 에이전트가 연결되는 과정을 추적합니다.

세 단계로 설정하기

먼저 sc_auth create-ctk-identity -l ssh-key -k p-256-ne -t bio를 실행해 생체 인증 보호를 적용한 CTK(CryptoTokenKit) 신원을 만듭니다. p-256-ne의 ne는 Non-Extractable을 뜻하며, 개인 키가 Secure Enclave 밖으로 나오지 않도록 하는 유형입니다. 글에 따르면 SSH에서 지원하는 곡선과 이 속성을 고려하면 p-256-ne를 선택하게 됩니다. -t none을 쓰면 Touch ID 확인 없이 프로그램이 키를 사용할 수 있습니다.

다음으로 ssh-add -K -S /usr/lib/ssh-keychain.dylib를 실행해 키를 SSH 에이전트에 등록합니다. 재부팅할 때마다 다시 실행해야 합니다. 새 서버에 등록할 공개 키는 ssh-add -L로 확인합니다. 여러 키가 나오면 sk-ecdsa-sha2-nistp256으로 시작하는 줄을 사용합니다. 이 공개 키를 GitHub에 등록하면 git push 같은 SSH 연결에서 Touch ID 인증을 요청합니다.

Secure Enclave와 SSH 에이전트의 연결

sc_auth는 키를 CTK 신원으로 관리합니다. 글은 p-256-ne가 Secure Enclave 안에서 생성되고 개인 키를 추출할 수 없는 유형이라고 설명합니다. 반면 p-256, p-384, p-521도 명령에서 허용되지만, 글에 따르면 p-384는 OpenSSH가 지원하지 않습니다. bio는 키를 쓸 때 생체 인증을 요구하고 none은 인증 절차를 생략합니다.

SSH 에이전트는 Secure Enclave 신원을 그대로 읽지 못하므로 Apple의 /usr/lib/ssh-keychain.dylib를 보안 키 제공자(Security Key Provider)로 지정합니다. ssh-add -K는 FIDO 방식 인증 장치의 키를 다루고 -S는 제공자 라이브러리를 지정합니다. 글쓴이는 라이브러리 인터페이스가 충분히 문서화되지 않았다고 밝히며, 내보내기 심볼을 조사해 _sk_load_resident_keys가 공개 키 목록을 제공하고 _sk_sign이 서명을 처리하는 것으로 추정합니다.

SSH 연결 시 에이전트는 공개 키를 서버에 제시합니다. 서버가 키를 받아들이면 에이전트가 해당 키에 대응하는 서명을 요청하고, Touch ID 인증을 거쳐 Secure Enclave가 서명합니다. 서버는 공개 키로 서명을 확인합니다. 글에 실린 ssh -vvv 로그에서도 에이전트가 키를 제시하고 서버가 받아들인 뒤 서명 단계에서 Touch ID 요청이 나타납니다. ssh-add가 PIN을 물을 때 빈 값을 입력해도 되는 이유는 글쓴이의 추정입니다. SSH가 USB 보안 키의 PIN을 예상하지만, 이 설정에서는 Apple 제공자가 인증을 처리하기 때문이라고 설명합니다.

키 보관의 장점과 제약

개인 키 파일이 디스크에 생기지 않고 키 자체를 복사해 훔칠 수 없다는 점이 이 방식의 장점입니다. 반면 키를 만든 Mac이 고장 나거나 사라지면 그 키를 복구할 수 없습니다. 새 키를 만들고 GitHub 등 등록한 서비스에 다시 등록해야 합니다. 기기별로 별도 키를 쓰면 접근 권한을 기기 단위로 나눌 수 있지만, 여러 기기와 서버를 관리할 때는 키 배포가 번거로워질 수 있습니다.

Lobsters 반응

  • @msangi — 재부팅 후 키를 다시 추가하는 수고를 줄이려면 SSH_SK_PROVIDER=/usr/lib/ssh-keychain.dylib를 설정하면 ssh-add -K만 입력하면 됩니다.
    • @nmattia — 좋은 방법입니다. ~/.ssh/config에 설정할 수도 있습니다. 글에서는 필요할 때 명시적으로 켜고 끌 수 있게 명령에 직접 적었습니다.
  • @eta — 저는 Secretive를 쓰는데, macOS 기본 도구만으로도 할 수 있는 줄 몰랐습니다.
    • @nmattia — macOS가 이 기능에 필요한 도구를 기본 제공하기 시작한 지는 얼마 되지 않았습니다. 저는 서드파티 도구를 피하는 편이지만 조사 중 Secretive에 관한 좋은 평가도 읽었습니다.
  • @bityard — 키를 쓸 때마다 생체 인증이 필요한가요, 아니면 시스템이 한동안 인증을 기억하나요? 자동화 작업에도 편하도록 데스크톱 로그인 때 SSH 키를 자동으로 잠금 해제해 씁니다.
    • @nikaro — -t bio 대신 -t none을 쓰면 지금 설정과 같은 방식으로 쓸 수 있습니다.
  • @atmosx — 저는 기기 사이에 SSH 키를 공유하므로 1Password를 씁니다. 기기마다 키를 하나씩 두는 방법도 이해하지만, 여러 노트북과 시스템에서 10대 넘는 서버에 접속하려면 키 배포가 번거롭습니다.
    • @nmattia — 저도 MacBook 여러 대와 Linux 시스템을 쓰지만 기기마다 별도 키를 둡니다. 기기별로 접근을 세밀하게 관리할 수 있습니다. 1Password가 개인 키를 저장하는지, SSH 보안 키 제공자 역할을 하는지 궁금합니다.
    • @atmosx — 1Password는 SSH 키를 생성하거나 기존 키를 저장할 수 있습니다. 백그라운드 에이전트를 켜고 SSH 설정에서 IdentityAgent 소켓을 지정하면 됩니다. 키는 클라우드로 동기화되므로 새 기기에서도 가져올 수 있습니다.
    • @nmattia — 그렇다면 기본 SSH 에이전트 대신 1Password 키만 쓸 수 있나요? ~/.ssh의 키도 찾아보나요?
    • @JustinAzoff — SSH 설정의 Match 블록을 쓰면 호스트별로 IdentityAgent를 다르게 지정할 수 있습니다.
    • @atmosx — 맞습니다. 1Password를 통하면 1Password 키를 씁니다. 기본 에이전트를 쓰려면 1Password 연동 설정을 주석 처리해야 합니다. 호스트별로 에이전트 소켓을 나누는 방법도 있습니다.
  • @bityard — 개인 키를 생성한 기기 밖으로 복사하지 않는 편이 좋습니다. 임시 디렉터리나 USB에 실수로 남길 수 있고 기기가 침해될 수도 있습니다. SSH 인증서를 쓰면 사용자 키를 배포하지 않고 CA로 호스트와 사용자 공개 키에 서명할 수 있습니다.
    • @atmosx — 동의합니다. 제 경우 개인 키는 1Password 보관함에 있고 Touch ID로 SSH 세션에서 사용합니다. 소규모 홈 네트워크라 CA 설정은 과하다고 봅니다.
    • @colonelpanic — CA 설정은 간단합니다. ssh-keygen으로 Ed25519 CA 키를 만들고 서버의 sshd_config에 TrustedUserCAKeys를 설정한 뒤 사용자 공개 키에 서명하면 됩니다.
  • @bramh — 개인 키를 추출할 수 없다면 백업도 할 수 없나요? 하드웨어 고장에 대비해 중요한 키는 물리적으로 출력해 둡니다.
    • @tonyarkles — Secure Enclave 안에서 키를 생성하면 개인정보 보호에는 유리하지만 백업할 방법이 없습니다. YubiKey를 쓸 때는 키를 외부에서 생성해 암호로 보호한 USB에 백업한 뒤 장치에 넣었습니다. 키가 메모리에 평문으로 존재하는 순간이 생기는 절충안입니다. sc_util에는 CTK 신원과 인증서를 가져오는 명령도 있습니다. PKCS#12 파일에서 개인 키 보호 방식을 지정하는 옵션이 있어 비슷한 절차가 가능한지는 시사하지만 직접 시험해 보지는 않았습니다.
  • @iv — Secure Enclave에 키를 둔 채 Git의 GPG 커밋 서명에도 쓸 수 있나요?
    • @adamcstephens — GPG 키를 꼭 써야 하는 게 아니라면 Git은 SSH 키로 서명할 수 있습니다.
    • @nmattia — 이론상 가능할 것 같지만 실제로는 조정이 필요할 수도 있습니다. 더 알아봐야 합니다.
  • @mandeep — Anthropic 덕분에 이제 NIST P-256을 믿을 수 있겠네요. Secure Enclave는 P-256 키만 지원합니다.

원문: nmattia.com / 번역·요약: Trawling

원문 보기 ↗토론 보기 ↗