Как сохранить пароль при использовании Subversion с консоли

Ответ 1

В ~/.subversion/config у вас, вероятно, есть store-passwords = no. Измените его на yes (или просто прокомментируйте это, потому что он по умолчанию имеет значение yes), и в следующий раз, когда вы предоставите Subversion свой пароль, он должен сохранить его.

Возможно, вы захотите убедиться, что владелец и разрешения ~/.subversion/config верны (нет открытого или группового доступа, 600).

Ответ 2

Это зависит от протокола, который вы используете. Если вы используете SVN + SSH, SVN-клиент не может сохранить ваш пароль, потому что он никогда не затрагивает его - клиент SSH запрашивает его для него напрямую. В этом случае вы можете использовать SSH-ключ и ssh-agent, чтобы избежать постоянных запросов. Если вы используете протокол svnserve или HTTP (S), тогда клиент SSH обрабатывает ваш пароль и может его сохранить.

Ответ 3

Попробуйте очистить папку .subversion в своем домашнем каталоге и попытаться выполнить еще раз. Он должен запросить у вас пароль, а затем спросить вас, хотите ли вы сохранить пароль.

Ответ 4

Мне пришлось отредактировать ~/.subversion/servers. Я установил store-plaintext-passwords = yes (ранее не было). Это сделал трюк. Однако это может считаться небезопасным.

Ответ 5

Обратите внимание на следующий абзац из файла ~/.subversion/servers:

Оба "хранилища-пароли" и "store-auth-creds" теперь могут быть   указанный в файле "servers" в вашем каталоге конфигурации.   Все, что указано в этом разделе, переопределяется настройками  указанный в файле 'servers'.

Это, по крайней мере, для версии SVN 1.6.12. Поэтому имейте в виду также редактировать файл серверов, так как он переопределяет ~/.subversion/config.

Ответ 6

Если вы используете svn + ssh, вы можете скопировать свой открытый ключ ssh на удаленную машину:

ssh-copy-id [email protected]

Ответ 7

Для меня (пользователя Mac) проблема заключалась в том, что в цепочке для ключей уже была запись для моих учетных данных, но права доступа были неправильными.

Удаление записи в приложении цепочки ключей, а затем ее повторное использование с помощью svn устранило проблему.

Ответ 8

Использование открытого текста может быть не лучшим выбором, если пароль когда-либо используется как что-то еще.

Я поддерживаю принятый ответ, но для меня это не сработало - по очень определенной причине: я хотел использовать хранилища паролей kwallet или gnome-keyring. Я попытался изменить настройки по всем четырем файлам:

/etc/subversion/config
/etc/subversion/servers
~/.subversion/config
~/.subversion/servers

Даже после того, как все было установлено одинаково, с password-stores и именем KWallet (по умолчанию может быть неправильно, верно?), он не работал и постоянно запрашивал пароль. Файлы в ~/.subversion имели разрешения 600.

Хорошо, в этот момент вы можете попытаться проверить одну простую вещь:

which svn

Если вы получаете:

/usr/bin/local/svn

то вы можете с большой вероятностью подозревать, что этот клиент был создан из источника, локально, вашим администратором (который может быть самим собой, как в моем случае).

Subversion - это неприятный зверь для компиляции, очень простой для случайного создания без поддержки HTTP или, как в моем примере, без поддержки зашифрованных хранилищ паролей (вам нужны файлы разработки Gnome или KDE, и многие из них!). Но ./configure script не скажет вам об этом, и вы получите менее функциональную команду svn.

В этом случае вы можете вернуться к клиенту, который пришел с вашим дистрибутивом, обычно в /usr/bin/svn. Недостаток - вам, вероятно, потребуется переустановить рабочие копии, так как нет команды svn downgrade. Вы можете проконсультироваться Линус Торвальдс о том, что думать о Subversion, во всяком случае;)

Ответ 9

Ни один из этих замечательных ответов не работал для меня на новой установке Ubuntu. Вместо этого, подсказка из этого ответа сделала свое дело для меня.

Мне пришлось разрешить "простое" хранилище паролей, установив этот пустой в ~/.subversion/config:

password-stores =

Там не было никакого существующего параметра, поэтому быть пустым очень важно.

Это было в дополнение к:

store-passwords = yes

в ~/.subversion/servers.

Ответ 10

К сожалению, ответы не решили проблему запроса пароля для ssh + svn с защищенным закрытым ключом. После некоторых исследований я обнаружил:

ssh-add

утилита, если у вас есть компьютер с Linux. Убедитесь, что ваши ключи хранятся в /home/username/.ssh/ и введите эту команду в Терминале.

Ответ 11

Чтобы добавить в Heath ответ: Похоже, Subversion 1.6 отключен, сохраняя пароли по умолчанию, если он не может хранить их в зашифрованном виде. Вы можете разрешить хранение незашифрованных паролей, явно указав password-stores = (то есть пустое значение) в ~/.subversion/config.

Чтобы проверить, какую версию Subversion использует хранилище паролей, посмотрите в ~/.subversion/auth/svn.simple. Он содержит несколько файлов, каждый из которых содержит хеш-таблицу с простой кодировкой ключ/значение. svn:realmstring в каждом файле определяет, для какой области этот файл. Если файл имеет

K 8
passtype
V 6
simple

затем он сохраняет пароль в виде обычного текста где-то в этом файле, в записи K 8 password. Иначе, он пытается использовать один из настроенных password-stores.

Ответ 12

Я использую TortoiseSVN клиент в Windows и для меня задает параметр store-passwords как yes в% USERPROFILE%\AppData\Roaming\Subversion\config не помогает хранить пароль.

Пароль был успешно сохранен после удаления этой папки (только при переименовании):

%USERPROFILE%\AppData\Roaming\Subversion\auth

Окружающая среда:

Windows 7, TortoiseSVN 1.7.11 (сборка 23600 - 64 бит, 2012-12-12T19: 08: 52), Subversion 1.7.8.