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

デプロイキーの管理

デプロイメントのスクリプトを自動化する際にサーバー上の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を使って容易にスクリプト化できる。

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

トークンでのGit自動化ガイドを参照してください。

デプロイキー

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

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

長所
  • リポジトリとサーバーにアクセスできる人は、誰でもプロジェクトをデプロイできる。
  • ユーザはローカルのSSH設定を変更する必要がない。
  • デプロイキーはデフォルトではリードオンリーだが、リポジトリに追加する際には書き込みアクセス権を与えることができる。
短所
  • デプロイキーは単一のリポジトリに対するアクセスだけを許可できる。 より複雑なプロジェクトは、同じサーバーからプルする多くのリポジトリを持っていることがある。
  • デプロイキーは通常パスフレーズで保護されていないので、サーバーが侵害されると簡単にキーにアクセスされることになる。
セットアップ
  1. サーバー上でssh-keygenの手順を実行し、生成された公開/秘密RSAキーのペアを保存した場所を覚えておいてください。
  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

Server-to-server tokens

If your server needs to access repositories across one or more organizations, you can use a GitHub App to define the access you need, and then generate tightly-scoped, server-to-server tokens from that GitHub App. The server-to-server tokens can be scoped to single or multiple repositories, and can have fine-grained permissions. For example, you can generate a token with read-only access to a repository's contents.

Since GitHub Apps are a first class actor on GitHub Enterprise Server, the server-to-server tokens are decoupled from any GitHub user, which makes them comparable to "service tokens". Additionally, server-to-server tokens have dedicated rate limits that scale with the size of the organizations that they act upon. For more information, see Rate limits for Github Apps.

長所
  • Tightly-scoped tokens with well-defined permission sets and expiration times (1 hour, or less if revoked manually using the API).
  • Dedicated rate limits that grow with your organization.
  • Decoupled from GitHub user identities, so they do not consume any licensed seats.
  • Never granted a password, so cannot be directly signed in to.
短所
  • Additional setup is needed to create the GitHub App.
  • Server-to-server tokens expire after 1 hour, and so need to be re-generated, typically on-demand using code.
セットアップ
  1. Determine if your GitHub App should be public or private. If your GitHub App will only act on repositories within your organization, you likely want it private.
  2. Determine the permissions your GitHub App requires, such as read-only access to repository contents.
  3. Create your GitHub App via your organization's settings page. For more information, see Creating a GitHub App.
  4. Note your GitHub App id.
  5. Generate and download your GitHub App's private key, and store this safely. For more information, see Generating a private key.
  6. Install your GitHub App on the repositories it needs to act upon, optionally you may install the GitHub App on all repositories in your organization.
  7. Identify the installation_id that represents the connection between your GitHub App and the organization repositories it can access. Each GitHub App and organization pair have at most a single installation_id. You can identify this installation_id via Get an organization installation for the authenticated app. This requires authenticating as a GitHub App using a JWT, for more information see Authenticating as a GitHub App.
  8. Generate a server-to-server token using the corresponding REST API endpoint, Create an installation access token for an app. This requires authenticating as a GitHub App using a JWT, for more information see Authenticating as a GitHub App, and Authenticating as an installation.
  9. Use this server-to-server token to interact with your repositories, either via the REST or GraphQL APIs, or via a Git client.

マシンユーザ

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

長所
  • リポジトリとサーバーにアクセスできる人は、誰でもプロジェクトをデプロイできる。
  • (人間の)ユーザがローカルのSSH設定を変更する必要がない。
  • 複数のキーは必要ない。サーバーごとに1つでよい。
短所
  • Organizationだけがマシンユーザをリードオンリーのアクセスにできる。 個人リポジトリは、常にコラボレータの読み書きアクセスを許可する。
  • マシンユーザのキーは、デプロイキーのように、通常パスフレーズで保護されない。
セットアップ
  1. サーバー上でssh-keygenの手順を実行し、公開鍵をマシンユーザアカウントに添付してください。
  2. マシンユーザアカウントに自動化したいリポジトリへのアクセスを付与してください。 これは、アカウントをコラボレータ外部のコラボレータとして、あるいはOrganization内のTeamに追加することでも行えます。

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

OR, learn how to contribute.