SSH認証局について

SSH認証局について

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

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

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

SSHがリポジトリで無効になっていなければ、Organizationのリソースにメンバーがアクセスする際に、SSH証明書を使わなければならないようにすることができます。

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

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

organization の投稿者は、SAML シングル サインオン (SSO) を強制している場合でも、署名済み認定資格証を承認する必要なしに、署名済み認定資格証を認証に使用できます。

SSH 認定資格証を要件にしている場合を除き、organization のメンバーと外部コラボレーターは、その他の認証方法 (ユーザー名とパスワード、personal access token、独自の SSH キーなど) を使用し、Git で organization リソースにアクセスし続けることができます。

企業が 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のリソースに対してそのユーザの代わりに振る舞うことを認可されるようになります。 証明書を発行する前に、そのユーザのアイデンティティを必ず検証してください。

ユーザーの識別に 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 の場合、 に、 必要 があります。 この日付より前に がアップロードされた CA の場合、 以前に、-V フラグは任意であり、取り消し不能で永続的な証明書を作成できます。

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

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

SSH を使用して複数の GitHub 製品にアクセスするユーザに証明書を発行するには、2 つのログイン機能拡張を含めて、各製品のユーザ名を指定できます。 たとえば、次のコマンドは、GitHub Enterprise Cloud のユーザーのアカウントに対して USERNAME-1 の証明書を発行し、HOSTNAME の GitHub Enterprise Server のユーザーのアカウントに対して 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」を参照してください。

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