web-dev-qa-db-ja.com

Gitolite Oneユーザー-多くのキー-異なるユーザー名

私は指示に従ってうまくいけばgitoliteをセットアップしました、そしてすべてが計画通りに働いています。

ユーザー名の部分がどのように機能するかについては少し確信がありません。また、ドキュメントを確認しても役に立たなかった-おそらく私は単純な何かが足りないのです。

2人のクライアントマシンがあり、1人の実在の人が使用する場合、それらのマシンのそれぞれでユーザー名は、daveとdavidとしましょう。 keydirと設定ファイルのキーを整理して、両方が同じユーザーを表すようにするにはどうすればよいですか？認証時にこれを探すように見えるので、異なるクライアントマシンのユーザー名を接続する方法ではなく、接尾辞dave @ laptop、dave @ desktopを取得します（おそらくuser @ Host情報を含む公開鍵のため） ？）

必要に応じて詳細をお知らせします-関係のない情報ですべてを攻撃したくありませんでした。

どうもありがとう。

gitauthenticationsshgitolite
38
Adam

ドキュメントによる現在の推奨方法

「最も簡単で理解しやすいのは、（/ kedir内の）異なるサブディレクトリ（alice.pub、home/alice.pub、laptop/alice.pubなど）にキーを配置することです。」

参照： http://gitolite.com/gitolite/gitolite.html#multi-key

古い方法

次のことをどのように達成するかを尋ねている場合：

  1. デビッド（自宅のコンピューター）
  2. デビッド（仕事用コンピューター）
  3. デビッド（ラップトップ）

各コンピューターに異なるsshキーを使用して、キー（つまり、keygen "[email protected]"）を作成し、公開キーをgitolite keydirディレクトリ（gitolite-admin/keydir）にコピーします。その場合は、キーに[email protected]、[email protected]、および[email protected]という名前を付けます。キーをリポジトリー（git add keydir/.）に追加し、コミット（git commit -m "added David's additional keys"）およびgit Pushをサーバーに戻します。

Gitoliteは、別のキーであってもユーザー名（@の前）がdavidであり、そのユーザーがログインしてdavidのACLを使用できることを認識できるほど賢いです

お役に立てれば

john_home.pubjohn_work.pubを使用する可能性があるシナリオを修正するには、gitoliteリポジトリ（管理者リポジトリ）を開き、kedirのキーの名前を[email protected]および[email protected]コミットとプッシュに変更します。これで、ユーザーjohnはどちらのマシンからでもログインでき、同じユーザー名を使用できます。

これが機能するためには、SSHキーのメールアドレスがすべてのユーザーのキーで同じである必要があることに注意してください。したがって、上記の例を使用すると、[email protected]、[email protected]、[email protected]のすべてのキーに、[email protected]のメールアドレスが必要です。

上記はこれまでの「古い方法」でしたが、キーを「メールアドレスの方法」で名前を付けた場合、上記の説明とは逆に、ジトールはキーを検査しません。適切なメールアドレス。無視してください（わかりやすくするために元のコメントを残しました）。

51
Steve Ross

Gitolite v3の場合、少なくとも最も簡単な解決策は、ここに記載されているサブフォルダーシステムを使用することです http://sitaramc.github.com/gitolite/users.html

Gitoliteはkeydirを再帰的に検索し、すべての.pubを1人のユーザーとして関連付けます。私は現在、WindowsラップトップとLinux開発マシンでサブフォルダーシステムを使用しており、正常に動作しています。

User @ Hostの規則は複雑すぎるようです。

私はこのようなことをしています：

 keydir 
 | --mfang 
 | | --laptop01 
 | | | --mfang.pub 
 | | --linux01 
 | | | --mfang.pub 
 | ... etc
11
fangstar

Gitolite v3.5.2-10-g437b497（2013年9月、コミット 59c817d ）以降、さらに簡単な解決策があります：

ukm、「ユーザーキー管理」用 。

ユーザーキー管理では、特定のユーザーがキーを追加および削除できます。

Gitolite管理ユーザーが新しいssh公開鍵を追加できるだけでなく、他のユーザーも追加できるようになった場合に、委任のレベルを導入できます。

また、公開SSH鍵の追加/削除も容易になります。

「 contrib/t/ukm.t "：

Gitoliteのドキュメント そのトピックに関するセクションを含む ですが、ukmを使用すると簡単です（セクション "- 複数のキーを管理したいユーザー "）：

Gitolite管理者は、キーの1つを初期キーとしてgitolite IDを作成します。このキーを管理できるのはgitolite管理者だけであり、ユーザーは管理できません。それは基本的にあなたがgitoliteに知られている名前の下で決定します。

このIDに新しいキーを追加し、自由に削除できます 。

# The admin can add multiple keys for the same userid.
try "
ADDOK u5 admin u4\@example.org
ADDOK u5 admin u4\@example.org\@home
ADDOK u5 admin laptop/u4\@example.org
ADDOK u5 admin laptop/u4\@example.org\@home
";
4
VonC

私はgitolite管理者のkeydirを数回再編成しましたが、それでも、物事を整理するための最良の方法はまだ決定していません。あなたがいくつかの慣習に固執することができれば、物事は確かに簡単になりますが、それが常に可能であるとは限りません。幸いなことに、ジトールは柔軟性があります。

一般的に、私はnotがすべてのキーを含む単一のフラットディレクトリを使用することを好み、命名規則 "[email protected]"にsolelyを使用して物事をまっすぐにします。 （これは他の回答で暗示されているようですか？）複数のホストに複数のキーがあり、単一の「実際の」ユーザーに複数のユーザー名がある場合（または2つの異なるホスト上の2つの異なるユーザーに同じユーザー名であっても）、混乱する可能性があります。サブディレクトリを使用すると、あらゆる深さのツリーを使用して物事を整理するのに役立ちますが、通常は1つのレベルのみを使用します。

2つの主要なオプション（またはそれらの組み合わせ）：

  1. 「実際の」ユーザーごとに1つのディレクトリ。各ディレクトリにはそのユーザーの複数のキーが含まれます（たとえば、通常はホストごとに1つ）。
  2. （許可された）ホストごとに1つのディレクトリ、そのホストで作業するユーザーごとに1つ（または複数）のキー。ユーザーは自分の秘密鍵を別のホストにコピーすることができますが、（私の場合）推奨されません。いずれの場合も、サブディレクトリは、キーが最初に生成されたホストにちなんで名付けられます。

ユーザーごとに1つのサブディレクトリの例として（オプション＃1）：

conf
 |--gitolite.conf
keydir
 |--john.doe
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |--will.rodgers
 |    |--wrodgers.pub
 |    |[email protected]
 |    |[email protected]
 |    |[email protected]
 |...etc

ご了承ください：

  • （keydirの下の）ディレクトリ名はgitoliteには関係ありません。
  • ディレクトリ名は、電子メールアドレスや他のグローバルIDなど、普遍的に一意である必要があります。これにより、異なるホスト上で同じユーザー名を持つ可能性のある「git」ユーザーが許可されます。
  • 「user.pub」や「[email protected]」などのキーは、複数のホスト間でユーザーによって共有される場合があります。ただし、これはポリシーに基づいて推奨されない場合があります。

一般的に、私はオプション＃1を好み、使用します。オプション＃2のいくつかの例がちりばめられています。オプション＃2は、サーバーが行き来し（おそらくVMのプロビジョニングとリサイクル）、ユーザーレベルではなくホストレベルで維持したい場合に、イントラネットの自動化を単純化する可能性があるため、（たとえば）古いものを簡単にクリーンアップできます廃止されたホストのキー（例：短期テストVM）。

Gitoliteの良い点は、keydirディレクトリの（再）編成がユーザーに影響を与えないことです。ただし、注意しないと、ユーザー（または自分自身）を（偶然に）簡単にロックアウトできます。

3
michael

あなたはいつもこのように接続します：

git clone gitoliteuser@gitoliteserver:reponame

あなたがどんなユーザーであっても。 Gitoliteは、提供する公開キーによってユーザーを識別します。このキーは、たとえばdave.pubと呼ばれます。この公開鍵とのssh接続を介して行われることはすべて、構成ファイルで「dave」または「all」が使用されている場所に応じてgitoliteによって精査されます。

さまざまなマシンやさまざまなリポジトリで、名前と電子メールを自由に設定できます。コミットにはその情報が含まれます。ただし、読み書きできるブランチ、ツリー、リポジトリは、sshに同じ公開/秘密鍵を使用する場合、管理リポジトリの設定ファイルで「dave」がどのように制限されているかによって決まります。

お役に立てれば。

2
Adam Dymitruk

誰もがここで見逃しているか、少なくともはっきりと答えていないように見える微妙な点があります。

OPは、2つの異なるユーザー名と、2つの異なるプラットフォーム上の2つの異なる（関連付けられた）pub-keyを使用して、同じPERSONを処理する方法を尋ねました。

例えば。 dave@platform_a.pubとdavid@platform_b.pubはどちらも同じ実際のgitユーザーを表しています。

Gitolite.confファイルの "@known"（既知のユーザー）行のユーザーとして、daveとdavidの両方を追加し、両方のキーをkeydirに配置するのは簡単ですが、それが2つであるかどうかを判断する方法はありません。別のユーザー、または同じ人。

例えば。 「git blame」は、daveとdavidを2人の別々のユーザーとして扱います。

OPの投稿以外に、同じプロジェクトで複数のDavidが作業している場合、さらに複雑になりますか？

私は関係するデービッドがシステムを考え出さなければならないだろうと思います（またはお互いを非難することに満足です;-)。

1
Dave E

サーバー上の1人のユーザーの下でgitoliteをインストールします。通常はgitであり、SSH接続文字列では、常に明示的にgit@servernameを使用してGitユーザーアカウントに接続します。次に、Gitoliteは提供している公開鍵を確認し、構成内でそれを見つけて、関連付けられているユーザーであるかのように扱います。

1
Brian Campbell

Gitoliteは、ssh強制コマンドを使用して認証を行います。 gitoliteリポジトリにアクセスできるすべてのユーザーは、gitoliteがインストールされている場所でログインします。フックはkeydirで新しいキーを取得し、強制コマンドを使用するように構成された承認済みキーファイルに追加します。

ユーザーはパラメーター付きのgitoliteシェルを使用する必要があり、そのパラメーターはユーザー名です。関連するフックの次の部分は、ファイルパスを取得してそれをユーザーに割り当て、名前に/が含まれるすべてのディレクトリとファイルを削除します。残りの文字は、末尾が.pubである限りユーザー名になり、追加の文字が少なくとも1つある限り、@サフィックスの前の単一の.pub記号を無視します。

my $user = $f;
$user =~ s(.*/)();                # foo/bar/baz.pub -> baz.pub
$user =~ s/(\@[^.]+)?\.pub$//;    # baz.pub, [email protected] -> baz

これにより、次のような機能が提供されます。

keydir
  |--Host1
       |--dave.pub
       |--david.pub
  |--Host2
       |--dave.pub

ディレクトリは任意ですが、組織的な目的のために、ホストは構造を与えるために使用されます。結局、2人のdaveユーザーと1人のdavidユーザーになります。

私はこのような構成を使用します：

keydir
  |--steve
       |[email protected]@laptop.pub
       |[email protected]@desktop.pub
  |--services
       |--jenkins
            |[email protected]
            |[email protected]
       |--redmine
            |[email protected]
       |--jira
            |[email protected]

ここでも、ディレクトリ構造は重要ではありません。これにより、ユーザーに[email protected]、jenkins、redmine、およびjiraが提供されます。 [email protected]ユーザーには、jenkinsユーザーと同様に2つのキーがあります。 1人以上のユーザーがいる場合は、おそらくsteve keyディレクトリを含むusersサブディレクトリが存在します。

0
Steve Buzonas