Skip to main content
ドキュメントへの更新が� �繁に発行されており、このページの翻訳はま� 行われている� �合があります。最新情� �については、英語版のドキュメントをご覧く� さい。
� 

� 

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2023-01-18. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの向上、新機能の向上を図るために、最新バージョンの GitHub Enterprise にアップグレードします。 アップグレードに関するヘルプについては、GitHub Enterprise サポートにお問い合わせく� さい。

デプロイキーの管理

この記事では、次の� �目が扱われます。

デプロイメントのスクリプトを自動化する際にサーバー上のSSHキーを管理する様々な方法と、どれが最適な方法かを学んでく� さい。

SSHエージェントのフォワーディング、OAuthトークンでのHTTPS、デプロイキー、マシンユーザを使ってデプロイメントスクリプトを自動化する際に、サーバー上のSSHキーを管理できます。

SSHエージェントのフォワーディング

多くの� �合、特にプロジェクトの開始時には、SSHエージェントのフォワーディングが最も� 早くシンプルに使える方法です。 エージェントのフォワーディングでは、ローカルの開発コンピュータで使うのと同じSSHキーを使います。

長所

  • 新しいキーを生成したり追跡したりしなくていい。
  • キーの管理は不要。ユーザはローカルと同じ権限をサーバーでも持つ。
  • サーバーにキーは保存されないので、サーバーが侵害を受けた� �合でも、侵害されたキーを追跡して削除する必要はない。

短所

  • ユーザーは、デプロイに SSH 接続する 必要があります。自動デプロイ プロセスは使用できません。
  • SSHエージェントのフォワーディングは、Windowsのユーザが実行するのが面倒。

セットアップ

  1. エージェントのフォワーディングをローカルでオンにしてく� さい。 詳細については、SSH エージェントの転送に関するガイドを参照してく� さい。
  2. エージェントフォワーディングを使用するように、デプロイスクリプトを設定してく� さい。 たとえば、bash スクリプトでは、エージェントの転送を有効にすると、次のようになります: ssh -A serverA 'bash -s' < deploy.sh

OAuthトークンを使ったHTTPSでのクローニング

SSH キーを使用しない� �合は、OAuth トークンで HTTPS を使用できます。

長所

  • サーバーにアクセスできる人なら、リポジトリをデプロイできる。

  • ユーザはローカルのSSH設定を変更する必要がない。

  • 複数のトークン（ユーザごと）が必要ない。サーバーごとに1つのトークンで十分。

  • トークンはいつでも取り消しできるので、本質的には使い捨てのパスワードにすることができる。

  • 新しいトークンの生成は、OAuth API を使用して簡単にスクリプト化できます。

短所

  • トークンを確実に正しいアクセススコープで設定しなければならない。
  • トークンは本質的にはパスワードであり、パスワードと同じように保護しなければならない。

セットアップ

個人用アクセス トークンの作成に関するガイドを参照してく� さい。

デプロイ キー

のリポジトリからプロジェクトをサーバーに起動するには、デプロイ キーを使用します。これは、単一のリポジトリへのアクセスを許可する SSH キーです。 GitHub Enterprise Server は個人アカウントの代わりに、リポジトリに直接キーのパブリックな部分をアタッチし、キーのプライベートな部分はサーバーに残ります。 詳細については、「デプロイを配信する」を参照してく� さい。

書き込みアクセス権を持つキーをデプロイすれば、管理アクセス権を持つOrganizationのメンバー、あるいは個人リポジトリのコラボレータと同じアクションを行えます。 詳細については、「Organization のリポジトリ ロール」および「個人アカウント リポジトリのアクセス許可レベル」を参照してく� さい。

長所

  • リポジトリとサーバーにアクセスできる人は、誰でもプロジェクトをデプロイできる。
  • ユーザはローカルのSSH設定を変更する必要がない。
  • デプロイ キーは既定では読み取り専用ですが、リポジトリに追� するときに書き込みアクセス権を付与することができます。

短所

  • デプロイキーは単一のリポジトリに対するアクセス� けを許可できる。 より複雑なプロジェクトは、同じサーバーからプルする多くのリポジトリを持っていることがある。
  • デプロイキーは通常パスフレーズで保護されていないので、サーバーが侵害されると簡単にキーにアクセスされることになる。

セットアップ

  1. サーバーで ssh-keygen 手� �を実行し、生成された公開キーと秘密 RSA キーのペアを保存する� �所を覚えておいてく� さい。
  2. 任意の GitHub Enterprise Server ページ上の右上隅にある自分のプロフィール写真をクリックしてから、 [自分のプロフィール] をクリックします。 プロフィールへのアクセス
  3. プロフィール ページで、 [リポジトリ] をクリックし、リポジトリの名前をクリックします。 リポジトリのリンク
  4. リポジトリから、 [設定] をクリックします。 リポジトリ設定
  5. サイドバーで、 [キーのデプロイ] 、 [デプロイ キーの追� ] の� �にクリックします。 デプロイ キーの追� リンク
  6. タイトルを入力し、公開鍵に貼り付けてく� さい。 デプロイキーのページ
  7. このキーにリポジトリへの書き込みアクセス権を付与する� �合は、 [書き込みアクセスを許可する] を選択します。 書き込みアクセス権を持つデプロイキーを使うと、リポジトリにデプロイメントのプッシュができるようになります。
  8. [キーの追� ] をクリックします。

1つのサーバー上で複数のリポジトリを利用する

1つのサーバー上で複数のリポジトリを使うなら、それぞれのリポジトリに対して専用のキーペアを生成しなければなりません。 複数のリポジトリでデプロイキーを再利用することはできません。

サーバーの SSH 構成ファイル (通常 ~/.ssh/config) に、各リポジトリのエイリアス エントリを追� します。 次に例を示します。

Host my-GHE-hostname.com-repo-0
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-0_deploy_key

Host my-GHE-hostname.com-repo-1
        Hostname my-GHE-hostname.com
        IdentityFile=/home/user/.ssh/repo-1_deploy_key
  • Host my-GHE-hostname.com-repo-0 - リポジトリのエイリアス。
  • Hostname my-GHE-hostname.com - エイリアスで使用するホスト名を構成します。
  • IdentityFile=/home/user/.ssh/repo-0_deploy_key - 秘密キーをエイリアスに割り当てます。

こうすれば、ホスト名のエイリアスを使ってSSHでリポジトリとやりとりできます。この� �合、このエイリアスに割り当てられたユニークなデプロイキーが使われます。 次に例を示します。

$ git clone git@my-GHE-hostname.com-repo-1:OWNER/repo-1.git

サーバー間トークン

サーバーが 1 つ以上の組織にわたるリポジトリにアクセスする必要がある� �合、GitHub アプリを使用して必要なアクセスを定義し、その GitHub アプリから スコープを厳� �に設定した、サーバー間 のトークンを生成します。 サーバー対サーバーのトークンは単一または複数のリポジトリをスコープとすることができ、権限を細かく設定できます。 たとえば、リポジトリのコンテンツへの読み取り専用アクセス権を持つトークンを生成できます。

GitHub AppはGitHub Enterprise Serverでも主役級の存在なので、サーバー間トークンはあらゆるGitHubユーザから分離され、「サービストークン」に相当します。 さらに、サーバー間トークンには独自のレート制限があり、その制限は実行されるOrganizationの規模に応じて拡大されます。 詳細については、「GitHub Apps のレート制限」を参照してく� さい。

長所

  • 権限設定と有効期限 (1時間、またはAPIで手動で取り消された� �合にはそれ以下) が明確に定義された、スコープが厳� �なトークン。
  • Organizationの規模に従って拡大する、独自のレート制限。
  • GitHubユーザIDと分離されているため、ライセンスのシート数を消費しない。
  • パスワードが付与されないので、直接サインインされない。

短所

  • GitHub Appを作成するには追� 設定が必要。
  • サーバー間トークンは1時間後に期限切れとなるので、再生成する必要がある (通常はコードを使用して、オンデマンドで行なう)。

セットアップ

  1. GitHub Appをパブリックにするかプライベートにするか決定します。 GitHub AppがOrganization内のリポジトリのみで動作する� �合は、プライベートに設定した方がいいでしょう。
  2. リポジトリのコンテンツへの読み取り専用アクセスなど、GitHub Appが必要とする権限を決定します。
  3. Organizationの設定ページからGitHub Appを作成します。 詳細については、「GitHub アプリの作成」を参照してく� さい。
  4. GitHub アプリ id をメモします。
  5. GitHub Appの秘密鍵を生成してダウンロードし、安全な方法で保存します。 詳細については、「秘密キーを生成する」を参照してく� さい。
  6. 動作させたいリポジトリにGitHubをインストールします。Organizationの全リポジトリにGitHub Appをインストールしても構いません。
  7. GitHub アプリと、それがアクセスできる組織リポジトリの間の接続を表す installation_id を特定します。 各 GitHub アプリと組織のペアには、最大で 1 つの installation_id があります。 「認証されたアプリの組織のインストールを取得する」を使用してこの installation_id を識別できます。 これには、JWT を使用した GitHub アプリとしての認証が必要です。詳細については、「GitHub アプリとしての認証」を参照してく� さい。
  8. 「アプリのインストール アクセス トークンを作成する」を使用して、対応する REST API エンドポイントを使用してサーバー間トークンを生成します。 これには、JWT を使用した GitHub アプリとしての認証が必要です。詳細については、「GitHub アプリとしての認証」と「インストールとしての認証」を参照してく� さい。
  9. このサーバー間トークンを使用して、REST、GraphQL API、またはGitクライアント経由でリポジトリとやり取りします。

マシンユーザ

サーバーが複数のリポジトリにアクセスする必要がある� �合、新しいアカウントをで作成し、自動化専用に使われるSSHキーを添付できます。 のこのアカウントは人間によって使用されるものではないため、マシン ユーザー と呼ばれます。 マシン ユーザーを個人リポジトリの コラボレーター� (読み取りと書き込みアクセス権の付与)、組織リポジトリの 外部コラボレーター� (読み取り、書き込み、または管理者アクセス権の付与)、または自動化する必要があるリポジトリへのアクセス権を持つ チー� � (チー� のアクセス許可の付与) として追� できます。

長所

  • リポジトリとサーバーにアクセスできる人は、誰でもプロジェクトをデプロイできる。
  • （人間の）ユーザがローカルのSSH設定を変更する必要がない。
  • 複数のキーは必要ない。サーバーごとに1つでよい。

短所

  • Organization� けがマシンユーザをリードオンリーのアクセスにできる。 個人リポジトリは、常にコラボレータの読み書きアクセスを許可する。
  • マシンユーザのキーは、デプロイキーのように、通常パスフレーズで保護されない。

セットアップ

  1. サーバーで ssh-keygen 手� �を実行し、公開キーをマシン ユーザー アカウントにアタッチします。
  2. マシンユーザアカウントに自動化したいリポジトリへのアクセスを付与してく� さい。 これを行うには、アカウントを コラボレーター として、外部コラボレーター として、または組織内の チー�  に追� します。

参考資料