2026 リモートMacのSFTP/SSHとFIDO2ハードウェア鍵（ecdsa-sk/ed25519-sk）：PIN・タッチ、ヘッドレスCI衝突、SSH CA/OIDC比較マトリクス

痛みの分解

痛み1：FIDO2-skを強い公開鍵と同一視するとPINロックやプレゼンスタイムアウトに失敗が分散します。

痛み2：人間とCIがauthorized_keysを共有すると夜間に連鎖失敗しMaxAuthTriesへ波及します。

痛み3：known_hostsなしではホスト身元が固定されません。

痛み4：遅いときは先に並列SFTPを疑います。

脅威モデルと観測

クライアント強化とホスト証明は別レイヤー

FIDO2裏付きのecdsa-sk/ed25519-skは「秘密鍵の持ち出し耐性」を上げますが、MITMや誤接続先からは守りません。known_hostsやホストCAで接続先の身元を固定しないまま鍵だけ強くしても、運用上の穴は残ります。

プレゼンスとPINがクリティカルパスに乗る理由

-O verify-requiredやタッチ確認は人間の操作前提です。GitHub ActionsのようなエフェメラルRunnerはUSBトークン常駐やPIN入力UIを満たせず、ジョブは「ランダム失敗」に見えます。ここでいちばん危ないのは、夜間に再試行が連鎖してMaxAuthTriesやレート制限に当たり、日中の正当な手作業まで巻き込むことです。

アカウント分離が最短の現場対処になる

現実的にはsshd_configのMatch Userで「エンジニア＝FIDO2-sk」「ci_upload＝証明書/OIDC専用」を分け、authorized_keysを同居させないのが安全です。人間用鍵をCIシークレットに混ぜる設計は、ローテーションと監査の両方で破綻しやすいです。

SSHユーザ証明書とOIDCは別の運用負債

SSHユーザ証明書は署名鍵の保護とシリアル失効が中心課題で、OIDCはaudienceやenvironment protectionのドリフトが中心です。OIDC記事とSSH CA記事を同じRunbookに載せ、「どの経路がどの失敗ログを吐くか」を先に決めておくと、オンコールの推測が減ります。

転送遅延と認証失敗を混同しない

大容量アーティファクトで並列SFTPが詰まると、体感はログイン失敗に似ます。往復遅延、帯域、p95、sshd側の認証ログを分離して見ないと、FIDO2のせいにし続ける罠に落ちます。

定量基準

タッチ付きSSHは往々にして2〜8秒の追加遅延が乗ります。パイプラインSLOに余白がないなら、そもそもFIDO2をCI経路に置かない判断が先です。

SSHユーザ証明書はTTL残20%を切る前に更新ジョブが走るようアラートを張り、失敗時は「鍵が無効」ではなく「発行パイプが詰まった」のかを区別します。

OIDCは千ビルドあたりの失敗率が急増したら、まずaudience/issuer/環境スコープを疑い、次にIdP側のレート制限を疑います。

SFTP側は同時セッション数・転送バイト・認証失敗を別系列で持ち、ダッシュボード上で相関させます。

読書順

まず本稿で「FIDO2をどの経路に置くか」を決め、その後に次の順が読みやすいです：known_hosts→OIDC→SSH CA→並列SFTP→MaxAuthTries→ホーム。

Appleシリコンのリモートビルドで成果物が肥大化しているチームは、認証強化だけ先に進めると「遅い＝鍵が悪い」という誤学習が起きやすいです。転送のボトルネック切り分けを先に固めてから、FIDO2-skの適用範囲を狭めると意思決定が安定します。

セキュリティレビューでは「人間のログイン」と「CIのデプロイ」を同一スプレッドシートで管理しないでください。principal、ホスト、パイプラインIDをキーにした表を別にすると、監査で詰まりにくいです。

FAQ

まとめ：FIDO2-skは人間側に強いがCI・ホスト・転送課題は残る。

限界：自前プールは整合コストが高い。

対比：SFTPMACホスト型リモートMacは運用面を製品化しレンタルで安定リズムを得やすい。