SSHエージェントのフォワーディング、OAuthトークンでのHTTPS、デプロイキー、マシンユーザを使ってデプロイメントスクリプトを自動化する際に、サーバー上のSSHキーを管理できます。
SSHエージェントのフォワーディング
多くの場合、特にプロジェクトの開始時には、SSHエージェントのフォワーディングが最も素早くシンプルに使える方法です。 エージェントのフォワーディングでは、ローカルの開発コンピュータで使うのと同じSSHキーを使います。
長所
- 新しいキーを生成したり追跡したりしなくていい。
- キーの管理は不要。ユーザはローカルと同じ権限をサーバーでも持つ。
- サーバーにキーは保存されないので、サーバーが侵害を受けた場合でも、侵害されたキーを追跡して削除する必要はない。
短所
- ユーザはデプロイするためにSSHしなければならない。自動化されたデプロイプロセスは利用できない。
- SSHエージェントのフォワーディングは、Windowsのユーザが実行するのが面倒。
セットアップ
- エージェントのフォワーディングをローカルでオンにしてください。 詳しい情報についてはSSHエージェントフォワーディングのガイドを参照してください。
- エージェントフォワーディングを使用するように、デプロイスクリプトを設定してください。 たとえば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設定を変更する必要がない。
- デプロイキーはデフォルトではリードオンリーだが、リポジトリに追加する際には書き込みアクセス権を与えることができる。
短所
- デプロイキーは単一のリポジトリに対するアクセスだけを許可できる。 より複雑なプロジェクトは、同じサーバーからプルする多くのリポジトリを持っていることがある。
- デプロイキーは通常パスフレーズで保護されていないので、サーバーが侵害されると簡単にキーにアクセスされることになる。
セットアップ
- サーバー上で
ssh-keygen
の手順を実行し、生成された公開/秘密RSAキーのペアを保存した場所を覚えておいてください。 - GitHub Enterprise Serverの任意のページの右上で、プロフィールの写真をクリックし、続いてYour profile(あなたのプロフィール)をクリックしてください。
- プロフィールページでRepositories(リポジトリ)をクリックし、続いてリポジトリの名前をクリックしてください。
- リポジトリでSettings(設定)をクリックしてください。
- サイドバーでDeploy Keys(デプロイキー)をクリックし、続いてAdd deploy key(デプロイキーの追加)をクリックしてください。
- タイトルを入力し、公開鍵に貼り付けてください。
- このキーにリポジトリへの書き込みアクセスを許可したい場合は、Allow write access(書き込みアクセスの許可)を選択してください。 書き込みアクセス権を持つデプロイキーを使うと、リポジトリにデプロイメントのプッシュができるようになります。
- 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
サーバーが組織をまたいでリポジトリにアクセスする必要がある場合、GitHub Appで必要なアクセスを定義して、そのGitHub Appからスコープを厳格に設定した、サーバー対サーバーのトークンを生成します。 サーバー対サーバーのトークンは単一または複数のリポジトリをスコープとすることができ、権限を細かく設定できます。 たとえば、リポジトリのコンテンツへの読み取り専用アクセス権を持つトークンを生成できます。
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.
セットアップ
- 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.
- Determine the permissions your GitHub App requires, such as read-only access to repository contents.
- Create your GitHub App via your organization's settings page. For more information, see Creating a GitHub App.
- Note your GitHub App
id
. - Generate and download your GitHub App's private key, and store this safely. 詳しい情報については、秘密鍵を生成するを参照してください。
- 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.
- 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 singleinstallation_id
. You can identify thisinstallation_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. - 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.
- 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だけがマシンユーザをリードオンリーのアクセスにできる。 個人リポジトリは、常にコラボレータの読み書きアクセスを許可する。
- マシンユーザのキーは、デプロイキーのように、通常パスフレーズで保護されない。
セットアップ
- サーバー上で
ssh-keygen
の手順を実行し、公開鍵をマシンユーザアカウントに添付してください。 - マシンユーザアカウントに自動化したいリポジトリへのアクセスを付与してください。 これは、アカウントをコラボレータ、外部のコラボレータとして、あるいはOrganization内のTeamに追加することでも行えます。