Мой сервер Subversion предоставляет доступ только через HTTPS; поддержка svn + ssh была прекращена, потому что мы хотели избежать создания системных пользователей на этой машине только для доступа к SVN. Теперь я пытаюсь предоставить пользователям возможность на некоторое время кэшировать свои пароли, не оставляя их в файловой системе в незашифрованном виде.
Это не проблема для пользователей Gnome или KDE, потому что они могут использовать gnome-keyring и kwallet соответственно. IIRC, TortoiseSVN также имеет аналогичный механизм кеширования. Но как насчет пользователей системы без графического интерфейса?
Некоторый контекст: в этом случае у нас есть сервер разработки / тестирования, на котором один проект был зарегистрирован в каталоге Apache htdocs. Разработка этого проекта почти завершена, и только незначительные изменения текста / макета выполняются непосредственно на этом сервере. Тем не менее, изменения следует зарегистрировать в репозитории. В этой системе нет kwallet и gnome-keyring, и ssh-agent не может помочь, потому что доступ к репозиторию осуществляется через https вместо svn + ssh.
Насколько мне известно, это оставляет им выбор: вводить пароль каждый раз, когда они разговаривают с сервером SVN, или сохранять его небезопасным способом.
Есть ли способ получить что-то вроде того, что предоставляют gnome-keyring и kwallet в среде без графического интерфейса?
Нет, ты не можешь.
HTTPS не поддерживает одностороннее хеширование паролей. В какой-то момент вам понадобится доступный текстовый пароль. Возможно, удастся зашифровать его до этого момента, однако, учитывая, что вам также понадобится ключ дешифрования на сервере, в этом очень мало смысла.
Даже если HTTPS поддерживает одностороннее хеширование паролей, вы не сможете этого сделать (потребуется некоторая защита от атак повторного воспроизведения, иначе хэш вашего пароля станет паролем!)
Это не настоящее решение, но переход на что-то распространенное, например Git, отлично решит эту проблему. Вы бы попросили пользователей настроить пересылку агента SSH на машину, к которой они подключались, и auth будет основан на этом.
Не уверен, что ИТ-парни сделали с нашим сервером SVN, чтобы вызвать это, но я устал от запроса пароля графического интерфейса, поэтому я настроил ~/.subversion/config файл, чтобы удалить [gui] kwallet, и использовать только подсказку в текстовом режиме:
password-stores = gnome-keyring
Но даже это все еще немного раздражало, поэтому я сделал это несколько раз в своем дереве исходных текстов:
vi +/http .svn/entries
и изменил http: к https: пару раз, а потом мне уже не подсказали.
Как ни странно, мне не нужно было менять его везде ... или, может быть, где-нибудь ... в какой-то момент демон умер, или отправлено SIGHUP, или что-то в этом роде ... Я заметил, что один из файлов в этом каталоге обновился:
~/.subversion/auth/svn.simple/
Кажется, неплохо как. Ах, хитрый обходной путь.
Как сказал @devicenull, в конечном итоге должен быть доступен фактический пароль. Однако одним из вариантов было бы использовать что-то вроде Encfs или ecryptfs для шифрования всего или части домашних каталогов пользователей [0], что означает, что пароль будет храниться на диске в зашифрованном виде. Это все равно нужно будет разблокировать при входе в систему (хотя это можно сделать с помощью PAM, если они используют аутентификацию по паролю), и пользователи должны будут убедиться, что он отключен, когда они будут выполнены.
[0] Очевидно, вы хотите, чтобы ~ / .ssh / находился в зашифрованной части.