How to save password when using Subversion from the console

SvnPasswords

Svn Problem Overview


I was wondering if there is a way to save my Subversion password when doing svn operations from the console. The console is the only option that I have. When I try to do any Subversion action, e.g. svn commit, it prompts for the account password every time. Is there a way to save this password somehow so that I don't have to retype it every time?

Svn Solutions


Solution 1 - Svn

In ~/.subversion/config, you probably have store-passwords = no. Change it to yes (or just comment it out because it defaults to yes), and the next time you give Subversion your password it should save it.

You might want to ensure that the owner and permissions of ~/.subversion/config are correct (no public or group access; 600).

Solution 2 - Svn

It depends on the protocol you're using. If you're using SVN + SSH, the SVN client can't save your password because it never touches it - the SSH client prompts you for it directly. In this case, you can use an SSH key and ssh-agent to avoid the constant prompts. If you're using the svnserve protocol or HTTP(S), then the SSH client is handling your password and can save it.

Solution 3 - Svn

Try clearing your .subversion folder in your home directory and try to commit again. It should prompt you for your password and then ask you if you would like to save the password.

Solution 4 - Svn

I had to edit ~/.subversion/servers. I set store-plaintext-passwords = yes (was no previously). That did the trick. It might be considered insecure though.

Solution 5 - Svn

Please note the following paragraph from the ~/.subversion/servers file:

> Both 'store-passwords' and 'store-auth-creds' can now be specified in the 'servers' file in your config directory. Anything specified in this section is overridden by settings specified in the 'servers' file.

It is at least for SVN version 1.6.12. So keep in mind to edit the servers file also as it overrides ~/.subversion/config.

Solution 6 - Svn

None of these wonderful answers worked for me on a fresh install of Ubuntu. Instead, a clue from this answer did the trick for me.

I had to allow "simple" password store by setting this empty in ~/.subversion/config:

password-stores =

There was no existing setting, so being empty is significant.

This was in addition to:

store-passwords = yes

in ~/.subversion/servers.

Solution 7 - Svn

Just to emphasize what Tomasz Gandor and Domain said about having the right version of svn and that it was compiled to enable plain text password storage, you need verify what you have:

svn --version
svn, version 1.9.7 (r1800392)
...
WARNING: Plaintext password storage is enabled!
...

The following authentication credential caches are available:

* Plaintext cache in /gr/home/ffvdqb/.subversion
* GPG-Agent

Versus:

svn --version
svn, version 1.12.2 (r1863366)
...

The following authentication credential caches are available:

* Gnome Keyring
* GPG-Agent
* KWallet (KDE)

Once you see that your version of svn was enabled for plain text password storage, then apply all the rest of the answers here.

Solution 8 - Svn

For me (Mac user) the problem was that the keychain already had an entry stored for my credentials, but the access rights were not right.

Deleting the entry in the key chain app and then recreating it by using svn fixed the issue.

Solution 9 - Svn

If you use svn+ssh, you can copy your public ssh key to the remote machine:

ssh-copy-id user@remotehost

Solution 10 - Svn

Using plaintext may not be the best choice, if the password is ever used as something else.

I support the accepted answer, but it didn't work for me - for a very specific reason: I wanted to use either kwallet or gnome-keyring password stores. I tried changing the settings, all over the four files:

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

Even after it all was set the same, with password-stores and KWallet name (default might be wrong, right?) it didn't work and kept asking for password forever. The files in ~/.subversion had permissions 600.

Well, at that point, you may try to check one simple thing:

which svn

If you get:

/usr/bin/local/svn

then you may suspect with great likelihood that this client was built from source, locally, by your administrator (which may be yourself, as in my case).

Subversion is a nasty beast to compile, very easy to accidentally build without HTTP support, or - as in my example - without support for encrypted password stores (you need either Gnome or KDE development files, and a lot of them!). But the ./configure script won't tell you that, and you just get a less functional svn command.

In that case, you may go back to the client, which came with your distribution, usually in /usr/bin/svn. The downside is - you'll probably need to re-checkout the working copies, as there is no svn downgrade command. You can consult Linus Torvalds on what to think about Subversion, anyway ;)

Solution 11 - Svn

To add to Heath's answer: It looks like Subversion 1.6 disabled storing passwords by default if it can't store them in encrypted form. You can allow storing unencrypted passwords by explicitly setting password-stores = (that is, to the empty value) in ~/.subversion/config.

To check which password store subversion uses, look in ~/.subversion/auth/svn.simple. This contains several files, each a hash table with a simple key/value encoding. The svn:realmstring in each file identifies which realm that file is for. If the file has

K 8
passtype
V 6
simple

then it stores the password in plain text somewhere in that file, in a K 8 password entry. Else, it tries to use one of the configured password-stores.

Solution 12 - Svn

I'm using the TortoiseSVN client on Windows, and for me, setting store-passwords parameter as yes in %USERPROFILE%\AppData\Roaming\Subversion\config does not help to store the password.

The password was successfully saved after removing this folder (just in case renaming):

%USERPROFILE%\AppData\Roaming\Subversion\auth

Environment:

Windows 7, TortoiseSVN 1.7.11 (Build 23600 - 64 bit, 2012-12-12T19:08:52), Subversion 1.7.8.

Solution 13 - Svn

All methods mention here are not working for me. I built Subversion from source, and I found out, I must run configure with --enable-plaintext-password-storage to support this feature.

Solution 14 - Svn

Unfortunately the answers did not solve the problem of asking for password for ssh+svn with a protected private key. After some research I found:

ssh-add

utility if you have a Linux computer. Make sure that you have your keys stored in /home/username/.ssh/ and type this command on Terminal.

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
Questionjohn mcdonaldView Question on Stackoverflow
Solution 1 - SvnMichael MrozekView Answer on Stackoverflow
Solution 2 - SvnnobodyView Answer on Stackoverflow
Solution 3 - SvnEarlzView Answer on Stackoverflow
Solution 4 - SvnhajamieView Answer on Stackoverflow
Solution 5 - SvnRusu BogdanView Answer on Stackoverflow
Solution 6 - SvnHeath RafteryView Answer on Stackoverflow
Solution 7 - SvnJimView Answer on Stackoverflow
Solution 8 - SvntriasView Answer on Stackoverflow
Solution 9 - SvnMichael SchmidView Answer on Stackoverflow
Solution 10 - SvnTomasz GandorView Answer on Stackoverflow
Solution 11 - SvnthakisView Answer on Stackoverflow
Solution 12 - SvnAnton SamokatView Answer on Stackoverflow
Solution 13 - SvnDomainView Answer on Stackoverflow
Solution 14 - SvnwwwView Answer on Stackoverflow