SVN + SSH Security

Я використовую snv + ssh з аутентифікацією на основі ключів. Зараз для того, щоб будь-який з моїх користувачів svn отримав доступ до сховища за допомогою Subversion, я повинен встановити файли репо, щоб вони читалися та могли записуватись у файловій системі для цих користувачів.

Я хочу не допустити, щоб користувачі могли видалити базу даних РЕПО під час входу на сервер через ssh, але в той же час мати змогу перевірити і ввести код.

Думки про те, як я можу це зробити?

Щоб отримати доступ до URL svn + ssh, клієнт svn запускає екземпляр svnserve за допомогою "ssh -q user @ host svnserve -t" і спілкується з цим екземпляром через stdin / stdout.

Якщо вашим користувачам потрібен звичайний доступ до ssh, ви все одно можете заборонити їм доступ до сховища, обмеживши доступ до одного користувача (chown -R svnserve: svnserve repo; chmod -R g-rwx, o-rwx repo) та замінивши команду svnserve на ця встановлена ​​програма / 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 /

Я бачу два можливі напрямки для нападу на цю проблему:

• надавати обмежений доступ до оболонки, наприклад, користувачі можуть використовувати svn лише зі своїми обліковими записами (може знадобитися інший обліковий запис, якщо доступ до оболонки потрібен і для інших цілей) - я знайшов кілька цікавих посилань, які гугли за svnonly . Примітка: не спробував їх сам.
• переходити до підривної роботи через https, додаючи клієнтські сертифікати. Я бачив, як люди обговорювали це, але ніколи цього не робив сам. Нижче: вимагає розповсюдження клієнтських сертифікатів на додаток до клавіш ssh.

я погоджуюсь з Грегом та Олафом - ідіть на доступ до https. Я використовую таку настройку досить довгий час і не бачу насправді жодних недоліків цього.

ви отримаєте додаткову користь від дрібнозернистого контролю доступу в сховищі - таким чином, ви можете зробити його частинами лише для читання, а деякі повністю недоступними для вибраних користувачів.