10 ポイント 投稿者 GN⁺ 2025-03-27 | 1件のコメント | WhatsAppで共有
  • CloudflareはOPKSSH(OpenPubkey SSH)をオープンソースとして公開
  • OPKSSHはOpenID ConnectベースのSSOログインにより、SSHキーを自動生成して利用できるようにする
  • ユーザーはSSH公開鍵/秘密鍵を自分で管理したり、サーバーへ配布したりする必要がなくなる
  • SSHプロトコルを変更せずに、SSH認証へIDベースのアクセス方式を導入できる

SSOとOpenID Connectの背景説明

  • SSO(Single Sign-On)は、ユーザーが一度ログインすれば複数のシステムにアクセスできるようにする認証方式
  • OpenID ConnectはSSOで主に利用されるプロトコルで、ユーザー情報を含むIDトークンを発行する
  • IDトークンにはユーザーのメールアドレスなどの情報は含まれるが、公開鍵は含まれない → SSHのようなセキュリティプロトコルではそのまま利用できない

OpenPubkeyの紹介

  • OpenPubkeyはIDトークンにユーザーの公開鍵を含め、PK Tokenとして扱えるようにする
  • これにより「Googleがalice@example.comユーザーは公開鍵0x123を使用している」と認証できる
  • 既存のOpenID Connectプロトコルを変更せずに適用できる

OPKSSHの役割と利点

  • OPKSSHはOpenPubkeyをSSHに統合し、SSOログインを通じて使い捨てのSSHキーを生成する
  • 既存のSSHプロトコルを変更せずに動作し、設定ファイルに2行追加するだけで適用できる
  • セキュリティ向上

    • 長期鍵の代わりに使い捨てSSHキーを使用 → 鍵漏えい時の影響を抑え、鍵の寿命を制限できる
    • デフォルトで24時間で失効し、設定で変更可能
  • ユーザー利便性の向上

    • opkssh loginコマンドを実行するだけでSSHキーの生成とログインが可能
    • SSH秘密鍵を複数のコンピューターにコピーする必要がない
  • 管理の可視性向上

    • 鍵ベースのアクセスではなくメールアドレスベースなので、誰がユーザーなのかを明確に追跡できる
    • bob@example.comのようなメールアドレスをアクセス許可ファイルに追加すれば、すぐにアクセス可能

OPKSSHの動作方式

  • ユーザーがopkssh loginを実行すると:
    • 一時的なSSH公開鍵/秘密鍵を生成
    • ブラウザーでOpenID Provider(Googleなど)にログイン
    • 成功すると、OpenPubkeyプロトコルを通じて公開鍵とユーザーIDを含むPK Tokenを生成
    • .sshディレクトリにPK Tokenを含む公開鍵ファイルと秘密鍵ファイルを保存
  • SSH接続時:
    • SSHクライアントがPK Tokenを含む公開鍵をSSHサーバーへ送信
    • サーバーはAuthorizedKeysCommandに設定されたOpenPubkey verifierを通じて公開鍵の有効性を検証
    • PK Tokenが有効で、メールアドレスがアクセス許可リストにあれば接続を承認

技術的な問題の解決

  • PK Tokenの送信: SSH証明書の拡張フィールドを使ってPK TokenをSSH公開鍵に含める
  • サーバー側での有効性検証: AuthorizedKeysCommandを使って公開鍵の有効性検証をカスタムプログラム(OpenPubkey verifier)に委譲
  • 公開鍵の一致性検証: SSHセッションを保護する公開鍵がPK Token内の鍵と一致するか確認

オープンソース化とその意味

  • OPKSSHはApache 2.0ライセンスでGitHubに公開された
  • 以前はプロトタイプ段階だったが、現在は完全なSSH機能として安定したリリースを提供
  • Cloudflareはこれを維持・保証するものではないが、OpenPubkeyコミュニティにコードを寄贈した

主な改善点

  • 実運用可能なSSH機能を追加
  • 自動インストールスクリプトを提供
  • 改善された構成ツールを同梱

1件のコメント

 
GN⁺ 2025-03-27
Hacker Newsの意見
  • SSH証明書はかなり前から存在しており、独自のSSH CAを構築して短期証明書を発行できる
    • 証明書を自動取得するためのさまざまな選択肢があり、その1つがstep-caプロジェクト
    • step-caはOAUTH/OIDCシステムやクラウドプロバイダーと連携できる
    • 商用ソリューションも存在する
  • SSH CAとハードウェアを使う方法を好む
    • SSHDでサードパーティーのコードを呼び出す必要がなく、攻撃対象領域と攻撃ベクトルを最小化できる
    • キー漏えいや再利用攻撃を完全に防止できる
    • 標準のssh-keygenコマンドですべて実行できるため、管理者の観点から有利
  • IDトークンにはユーザー公開鍵が含まれないためSSHプロトコル自体を直接保護できない、という主張に疑問を持つ
    • SSH認証は必ずしも鍵ベースである必要はない
    • GSSAPIを通じて実装できたのではないかと考える
  • Teleportを使って証明書ベースのSSH認証を行っており、SSO認証で短期証明書を発行している
    • アクセス制御と監査ログの利点がある
  • TerminalwireというSSH代替を開発中
    • 開発者ワークステーションからSaaSに対して単発コマンドを実行する用途に適している
    • サーバーからクライアントへstdioをストリーミングするSSHに似ているが、追加コマンドを提供する
  • UserifyのSSHキー技術と比較している
    • Userifyは分散された通常の鍵を使い、中央制御プレーンだけを集中管理する
    • 認証サーバーがオフラインでもサーバーにログインできる
    • ユーザーセッションを終了し、アカウントを削除する機能がある
  • ブログ記事の執筆者でありopksshの主要コントリビューターとして、質問に答える用意がある
  • OIDCをサポートするSSH CAを運用する場合との違いが分かりにくい
    • サーバーはCAの鍵だけを信頼すればよい
  • X.509証明書CAをサポートするOpenSSHフォークがある
    • 公開鍵をトークンとして返す標準と、それを使ってSSHにログインするサーバー側認証バイナリが革新的なものとして提示されているのが興味深いと思う