Skip to main content
ドキュメントには� �繁に更新が� えられ、その都度公開されています。本ページの翻訳はま� 未完成な部分があることをご了承く� さい。最新の情� �については、英語のドキュメンテーションをご参照く� さい。本ページの翻訳に問題がある� �合はこちらまでご連絡く� さい。
Enterprise Server 3.0
日本語
� 
Developers
Enterprise Server 3.0
日本語

� 

このバージョンの GitHub Enterprise はこの日付をもって終了となりました: 2022-02-16. 重大なセキュリティの問題に対してであっても、パッチリリースは作成されません。 パフォーマンスの向上、セキュリティの改善、新機能のためには、最新バージョンのGitHub Enterpriseにアップグレードしてく� さい。 アップグレードに関する支援については、GitHub Enterprise supportに連絡してく� さい。

デプロイキーの管理

ここには以下の内容があります:

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

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

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

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

長所

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

短所

  • ユーザはデプロイするためにSSHしなければならない。自動化されたデプロイプロセスは利用できない。
  • SSHエージェントのフォワーディングは、Windowsのユーザが実行するのが面倒。

セットアップ

  1. エージェントのフォワーディングをローカルでオンにしてく� さい。 詳しい情� �についてはSSHエージェントフォワーディングのガイドを参照してく� さい。
  2. エージェントフォワーディングを使用するように、デプロイスクリプトを設定してく� さい。 For example, on a bash script, enabling agent forwarding would look something like this: ssh -A serverA 'bash -s' < deploy.sh

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

If you don't want to use SSH keys, you can use HTTPS with OAuth tokens.

長所

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

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

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

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

  • 新しいトークンの作成は、OAuth APIを使って容易にスクリプト化できる。

短所

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

セットアップ

See our guide on creating a personal access token.

デプロイキー

You can launch projects from a repository on your GitHub Enterprise Server instance to your server by using a deploy key, which is an SSH key that grants access to a single repository. GitHub Enterprise Serverは個人ユーザアカウントの代わりに、リポジトリに直接キーのパブリックな部分をアタッチし、キーのプライベートな部分はサーバーに残ります。 詳しい情� �については「デプロイメントのデリバリー」を参照してく� さい。

書き込みアクセス権を持つキーをデプロイすれば、管理アクセス権を持つOrganizationのメンバー、あるいは個人リポジトリのコラボレータと同じアクションを行えます。 For more information, see "Repository roles for an organization" and "Permission levels for a user account repository."

長所

  • リポジトリとサーバーにアクセスできる人は、誰でもプロジェクトをデプロイできる。
  • ユーザはローカルのSSH設定を変更する必要がない。
  • デプロイキーはデフォルトではリードオンリー� が、リポジトリに追� する際には書き込みアクセス権を与えることができる。

短所

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

セットアップ

  1. Run the ssh-keygen procedure on your server, and remember where you save the generated public and private rsa key pair key pair.
  2. GitHub Enterprise Serverの任意のページの右上で、プロフィールの写真をクリックし、続いてYour profile（あなたのプロフィール）をクリックしてく� さい。 プロフィールへのアクセス
  3. プロフィールページでRepositories（リポジトリ）をクリックし、続いてリポジトリの名前をクリックしてく� さい。 リポジトリのリンク
  4. リポジトリでSettings（設定）をクリックしてく� さい。 リポジトリの設定
  5. サイドバーでDeploy Keys（デプロイキー）をクリックし、続いてAdd deploy key（デプロイキーの追� ）をクリックしてく� さい。 デプロイキーのリンクの追� 
  6. タイトルを入力し、公開鍵に貼り付けてく� さい。 デプロイキーのページ
  7. このキーにリポジトリへの書き込みアクセスを許可したい� �合は、Allow write access（書き込みアクセスの許可）を選択してく� さい。 書き込みアクセス権を持つデプロイキーを使うと、リポジトリにデプロイメントのプッシュができるようになります。
  8. Add key（キーの追� ）をクリックしてく� さい。

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

サーバー間トークン

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

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 Appを作成する」を参照してく� さい。
  4. GitHub App idをメモします。
  5. GitHub Appの秘密鍵を生成してダウンロードし、安全な方法で保存します。 詳しい情� �については、秘密鍵を生成するを参照してく� さい。
  6. 動作させたいリポジトリにGitHubをインストールします。Organizationの全リポジトリにGitHub Appをインストールしても構いません。
  7. GitHub AppとOrganizationリポジトリとの接続を表わすinstallation_idを特定します。 GitHub AppとOrganizationの各ペアには、最大1つのinstallation_idがあります。 認証されたアプリケーションのOrganizationインストール情� �を取得することで、installation_idを識別できます。 このためには、JWTを使用して、GitHub Appとして認証する必要があります。詳細については、「GitHub Appとして認証する」を参照してく� さい。
  8. 対応するREST APIエンドポイントを使用して、サーバー間トークンを生成します。「アプリケーションに対するインストールアクセストークンの作成」を参照してく� さい。 このためには、JWTを使用してGitHub Appとして認証する必要があります。詳しい情� �については、「GitHub App として認証する」および「インストールとして認証を行う」を参照してく� さい。
  9. このサーバー間トークンを使用して、REST、GraphQL API、またはGitクライアント経由でリポジトリとやり取りします。

マシンユーザ

サーバーが複数のリポジトリにアクセスする必要がある� �合、新しいアカウントをyour GitHub Enterprise Server instanceで作成し、自動化専用に使われるSSHキーを添付できます。 your GitHub Enterprise Server instanceのこのアカウントは人間によって使用されるものではないため、マシンユーザと呼ばれます。 マシンユーザは、個人リポジトリにはコラボレータとして（読み書きのアクセスを許可）、Organizationのリポジトリには外部のコラボレータとして（読み書き及び管理アクセスを許可）、あるいは自動化する必要があるリポジトリへのアクセスを持つTeamに（そのTeamの権限を許可）追� できます。

長所

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

短所

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

セットアップ

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

参考リンク