EPEL リポジトリから Centos6.4 に gitolite3 をインストールしました。気に入らない点がいくつかあったので、変更することにしました。まず、あまり知られていない gitolite3 ユーザーから距離を置くために、「git」という追加のユーザーとグループを作成しました。次に、/var/lib/gitolite3 の代わりにカスタム フォルダー /Server/Projects を使用しました。所有権と権限が同じであることを確認しました。
セットアップも問題ありませんでした (su - git、次に管理者クライアント キーを使用して gitolite3 をセットアップ)。
通常、クライアント マシンでは、このコマンドはssh git@myserver infoリポジトリと権限をリストするわかりやすい gitolite プレーン リターンを生成します。しかし、今度はパスワードの入力を求められます。明らかに、gitolite はこのユーザー経由では ssh ポートに接続されなくなりましたが、通常の bash は接続されています。
私は SSH の専門家ではないので、何かがうまくいかなかったか、何かを忘れたようです。どこを確認すればよいでしょうか? git ユーザーによる SSH 要求が届いたときに SSHD が呼び出すアプリは、/usr/share/gitolite3/gitolite3-shell だと思います。
答え1
SSH は簡単ではありません。自分で解決しましたが、明らかではありませんでした。主に SELinux の問題でしたが、公開キーも適切に設定していなかったことがわかりました。
まず、gitolite サーバーを管理するローカル コンピューターの公開キー (admin.pub) を (再) 作成し、それをサーバーの git ユーザーのホーム フォルダーにコピーし、その公開キーを使用して gitolite セットアップを (git ユーザーのホーム フォルダーで) 再実行しました。ここで注意すべき点は、私のローカル コンピューターは msys-git を搭載した Windows であるため、問題は簡単には解決できないということです。
# su - git
$ cd /Server/Projects
$ gitolite setup --pubkey admin.pub
..これで公開鍵の問題が解決しました。selinux は学習曲線が大きかったですが、基本的にコピーするだけで元の /var/lib/gitolite3 フォルダーのコンテキスト ラベルがすべて失われます。ラベルを復元するには (semanage を使用)、現在の gitolite フォルダーを設定した元のフォルダーと同じラベルを参照します (-e フラグを使用)。これは既存の selinux ファイル コンテキストに追加されるだけなので、selinux ファイル コンテキストからこれらを復元する必要もあります。最後の落とし穴は、相対パスではなく絶対パスを使用することです。ll コマンドで何を行ったかを確認できます。
# semanage fcontext -a -e /var/lib/gitolite3 /Server/Projects
# restorecon -R /Server/Projects
# ll -aZ
さて、ローカル マシンで、公開キーの取得元であるコンピューターから以下のコマンドを実行してすべて試してください。私の場合はうまくいきました。ssh git@unclefloserver infoサーバーが要求元のユーザー/コンピューターの組み合わせの公開キーを実際に持っている場合にのみ、適切な gitolite3 リポジトリ情報出力が返されることを私は知りませんでした。また、この概念を少し理解できず、別のコンピューターからこれを試していました。
> git clone git@server:gitolite-admin
プレッシャーをかけ続けてくれた @Etan Reisner に大いに感謝します。