SSH認証局について

SSH証明書とは、1つのSSHキーでもうひとつのSSHキーに署名する仕組みです。 SSH 証明機関 (CA) を利用して、organization のメンバーと外部コラボレーターに署名済みの SSH 認定資格証を発行すると、Enterprise アカウントまたは organization に CA を追加できるため、organization の投稿者がそれぞれの認定資格証を使用して、organization リソースにアクセスできるようになります。

          GitHub では、組織またはエンタープライズ レベルで構成された信頼された SSH 証明機関 (CA) に対して証明書の署名とフィールド (有効期間を含む) を検証することで、OpenSSH 形式の SSH ユーザー証明書を使用して SSH 経由で Git 操作を認証します。

メモ

SSH 認証局を使うには、organization が GitHub Enterprise Cloud を使っている必要があります。 GitHub Enterprise Cloud を無料で試す方法の詳細については、「GitHub Enterprise Cloud の試用版を設定する」を参照してください。

SSH CA を organization または Enterprise アカウントに追加すると、その CA を使用して、organization メンバーと外部コラボレーターのクライアント SSH 認定資格証に署名できるようになります。 organization の投稿者は、署名済み認定資格証を使用して、その organization のリポジトリにアクセスできます。

エンタープライズに追加された証明書は、企業アカウントが所有するすべての組織にアクセス権を付与します。詳しくは、「Enterprise でセキュリティ設定のポリシーを適用する」をご覧ください。

メンバーが organization のリソースにアクセスする際に SSH 証明書を使うよう要求できます。

または、メンバーや外部コラボレーターに対して、organization リソースへのアクセス時に SSH 認定資格証を使用するように求めることもできます。詳細については、「組織のSSH証明書認証局を管理する」および「Enterprise でセキュリティ設定のポリシーを適用する」を参照してください。

たとえば、毎朝新しい証明書を開発者に発行する内部システムなども構築できます。各開発者は、毎日の証明書を使用して、 GitHub上の組織のリポジトリで作業できます。 1日の最後になると証明書は自動的に失効するので、証明書が侵害されることがあっても、リポジトリは保護されます。

組織の共同作成者は、SAML シングルサインオン (SSO) を適用している場合でも、署名付き証明書を承認しなくても、認証に署名された証明書を使用できます。

SSH 証明書を要件にしない限り、組織のメンバーと外部のコラボレーターは、他の認証手段を引き続き使用して、ユーザー名とパスワード、 personal access token、独自の SSH キーなど、Git を使用して組織のリソースにアクセスできます。

企業が SSH CA によるユーザー所有リポジトリへのアクセスを許可していない限り、メンバーは証明書を使用して組織のリポジトリのフォークにアクセスできません。詳しくは、「SSH認証局について」をご覧ください。

SSH証明書を使用するSSH URLについて

Organization が SSH 認定資格証を必要とする場合、認証エラーを回避するために、organization のメンバーは、SSH 経由で Git 操作をする際に、organization ID を含む特別な URL を使用する必要があります。この特別なURLを使うと、クライアントとサーバーは認証の際にメンバーのコンピュータが使うキーに関して簡単にネゴシエーションできるようになります。メンバーが git@github.com で始まる通常の URL を使うと、SSH クライアントは間違ったキーを提供し、操作が失敗する場合があります。

リポジトリへの読み取りアクセス権を持つユーザーは、リポジトリのメインページで [コード] ドロップダウンメニューを選択し、 [SSH の使用] をクリックして、この URL を見つけることができます。

Organization が SSH 認定資格証を必要としない場合は、投稿者は、自分の SSH キーまたはその他の認証方法を使用し続けることができます。その場合は、特殊な URL または git@github.com で始まる通常の URL が機能します。

証明書の発行

各証明書を発行するときは、証明書の対象となるユーザー GitHub 指定する拡張機能を含める必要があります。ログインハンドルまたはユーザー ID を使用して、ユーザーを参照できます。たとえば、OpenSSH の ssh-keygen コマンドを使用して、KEY-IDENTITY をキー ID に、USERNAME を GitHub ユーザー名またはユーザー IDに置き換えることができます。あなたが生成する証明書は、あなたのOrganizationのリソースに対してそのユーザの代わりに振る舞うことを認可されるようになります。証明書を発行する前に、そのユーザのアイデンティティを必ず検証してください。

メモ

これらのコマンドを使うには、OpenSSH 7.6 以降に更新する必要があります。

ユーザーの識別に login を使用するには、extension:login を使用します:

ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@github.com=USERNAME ./user-key.pub

ユーザー ID を使用するには、 extension:idを使用します。

ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:id@github.com=ID ./user-key.pub

警告

証明書が署名されて発行されると、その証明書を取り消すことはできません。

2024 年 3 月 27 日以降にアップロードされた CA証明書の有効期間を 366 日未満に構成するには、-V フラグを使用する必要があります。この日付前にアップロードされた CA より前のバージョンでは、 -V フラグは省略可能であり、取り消し不可能で永続的な証明書を作成できます。

有効期限の要件から除外されているレガシ CA がある場合は、CA をアップグレードして要件を適用できます。詳細については、「組織のSSH証明書認証局を管理する」と「Enterprise でセキュリティ設定のポリシーを適用する」を参照してください。

ログイン拡張機能としてユーザー名を使用する場合、 GitHub は、証明書が発行されてから、名前付きユーザーの名前が変更されていないことを検証します。これにより、基になるユーザーアカウントが変更された場合でも、ユーザー名に対して発行された証明書が有効である場合、名前変更攻撃を防ぐことができます。これを適用するには、証明書に valid_after 要求を含める必要があります。この要求は、証明書が発行された日時を伝えます。証明書に有効期限が不要な場合、このフィールドは見つからないことが多いため、有効期限が必要になりました。

SSH を使用して複数の GitHub 製品にアクセスするユーザーに証明書を発行するには、2 つのログイン拡張機能を含めて、各製品のユーザー名を指定できます。たとえば、次のコマンドでは、 GitHub Enterprise Cloudの場合はユーザーのアカウントに対して USERNAME-1 の証明書を発行し、hostname で GitHub Enterprise Server またはデータ所在地付き GitHub Enterprise Cloud にユーザーのアカウントの USERNAME-2 を発行します。

ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@github.com=USERNAME-1 extension:login@HOSTNAME=USERNAME-2 ./user-key.pub

          `source-address` 拡張機能を使用して、Organization のリソースに Organization のメンバーがアクセスできる IP アドレスを制限できます。 エクステンションには、CIDR 表記を用いて特定の IP アドレスまたは一定範囲の IPアドレスを指定できます。 コンマで値を区切ることで、複数のアドレスや範囲を指定できます。 詳細については、ウィキペディアの「[Classless Inter-Domain Routing](https://en.wikipedia.org/wiki/Classless_Inter-Domain_Routing#CIDR_notation)」を参照してください。

ssh-keygen -s ./ca-key -V '+1d' -I KEY-IDENTITY -O extension:login@github.com=USERNAME -O source-address=COMMA-SEPARATED-LIST-OF-IP-ADDRESSES-OR-RANGES ./user-key.pub

証明書の失効と CA のローテーション

          GitHub は、署名、フィールド (有効期間を含む)、および署名 CA が組織レベルまたはエンタープライズ レベルで信頼されているかどうかに基づいて SSH 証明書を検証します。 OpenSSH 証明書では、証明書失効リスト (CRL) またはオンライン証明書状態プロトコル (OCSP) は使用されないため、同じ CA を信頼し続けながら、既に発行されている個々の証明書を取り消す方法はありません。

証明書の有効期限が自然に切れる前に証明書を無効にするには、発行元 CA を組織または企業の設定から削除します。 CA を削除すると、 GitHub がその CA によって署名された SSH 証明書をすぐに受け入れなくなります。

警告

組織またはエンタープライズ設定から CA を削除すると、署名したすべての証明書 (まだ期限切れになっていない証明書を含む) が無効になります。

中断を最小限に抑えて証明機関 (CA) をローテーションするには:

新しい CA を企業または組織の設定に追加します。
証明書発行システムを更新して、新しい CA で新しい証明書に署名します。
すべてのユーザーが新しい CA から新しい証明書を受信したら、古い CA を削除します。

有効期間の短い証明書を発行すると、証明書が侵害された場合のリスク期間が短縮されます。 CA の管理の詳細については、「AUTOTITLE」および「AUTOTITLE」を参照してください。

SSH認証局について

この記事で