SVN + SSHセキュリティ

鍵ベースの認証でsnv + sshを使用しています。現時点では、svnユーザーがSubversionを使用してリポジトリにアクセスするために、repoファイルをファイルシステム上で読み取りおよび書き込みできるように設定する必要があります。

ユーザーがssh経由でサーバーにログインしたときにリポジトリデータベースを削除できなくても、コードをチェックアウトしてコミットできるようにしたいのですが。

これをどうやってできるのか？

svn + ssh URLにアクセスするには、svnクライアントが「ssh -q user @ host svnserve -t」を使用してsvnserveインスタンスを起動し、stdin / stdoutを介してそのインスタンスと通信します。

ユーザーが通常のsshアクセスを必要とする場合でも、アクセスを1人のユーザーに制限し（chown -R svnserve：svnserve repo; chmod -R g-rwx、o-rwx repo）、svnserveコマンドをこのsetuid / setgid svnserveラッパープログラム。

共有ユーザー環境では、実際のSubversionサーバーを（svnserveまたはApache経由で）セットアップすることをお勧めします。この環境では、すべてのファイルアクセスはサーバープロセスのユーザーアカウントで行われるため、個々のユーザーはリポジトリファイルにアクセスする必要はありません。

Subversionブックには、サーバー構成の選択に関するセクションがあります。そのセクションから（私の強調）：

SSHアカウントに大きく基づいている既存のインフラストラクチャがあり、ユーザーがサーバーマシンに既にシステムアカウントを持っている場合は、svnserve-over-SSHソリューションをデプロイするのが理にかなっています。それ以外の場合は、このオプションを広くお勧めしません。一般に、本格的なシステムアカウントではなく、svnserveまたはApacheによって管理される（架空の）アカウントを介してユーザーがリポジトリにアクセスする方が安全であると考えられています。

このサイトにはいくつかの素晴らしいトリックがあります：http : //svn.apache.org/repos/asf/subversion/trunk/notes/ssh-tricks

それでもうまくいかない場合は、回避策でうまくいくでしょうか？次のようなものをコミットフックに追加することで、誰かが何かをコミットするたびにリポジトリのバックアップをとることができます：sudo rsync -a / my / repo / path / my / closed / path /

この問題を攻撃するための2つの可能な方向がわかります。

• 制限されたシェルアクセスを提供します。たとえば、ユーザーは自分のアカウントでのみsvnを使用できます（シェルアクセスが他の目的でも必要な場合は、別のアカウントが必要になる場合があります）-svnonlyに関する興味深い参照がいくつか 見つかりました。注：自分で試したわけではありません。
• https経由でsubversionに移行し、クライアント証明書を追加します。私はこれについて議論している人を見たことがありますが、私自身はそうしませんでした。欠点：sshキーに加えてクライアント証明書の配布が必要です。

私はグレッグとオラフに同意します-httpsアクセスに行きます。私はかなり長い間このような設定を使用しており、実際にその欠点を確認できません。

リポジトリ内のきめの細かいアクセス制御の追加の利点が得られます-そのため、その一部を読み取り専用にして、一部を選択したユーザーが完全にアクセスできないようにすることができます。