How to save password when using Subversion from the console

Question

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?

Swelling

See also can't make svn store password, even though the configuration is set to allow it for troubleshooting in case the accepted answer does not work. – Prittleprattle

Answer 1

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).

Barchan

I can't find this file in Red Hat Linux 2.6.18. any idea where it could be ? – Loveliesbleeding

@Loveliesbleeding You might need to make it if it doesn't already exist; I think SVN looks there in all distros – Barchan

+1, After creating file /etc/subversion/config system work as expected. Thanks – Loveliesbleeding

@IshKumar Thanks for sharing the global config file. I needed to change that too. – Teriann

@François Why the role back? Did I violate some rules? – Teriann

@Seven: Hi, that was some while back :) Looking at the change I think I based the descition to roll back on the fact that the addition/changes made on the original text were quite big and that if you personally had to do something else to get your issue solved that information might be better of as a comment. But if new information must be added to make the answer valid today full-stop any new text should propably be added below the original text without changing it. That way you see the original answer but also any new information which needs to be included today. Does that make sense? – Friedafriedberg

Under windows with TortoiseSVN, the file is "%APPDATA%\Subversion\config" – Oligochaete

On my system (centos 6), this actually saves the passwords in files under ~/.subversion/auth/. This should be the directory that gets 600 permissions. – Windjammer

@Teriann Better yet, just write a new answer that's more up-to-date. (The store-passwords option in config is now deprecated, according to some default comments I found in my config file; it has been replaced by the same option in servers.) – Massey

Also be sure the ~/.subversion directory (and its contents) are owned by you. If the ownership is incorrect, svn will not be able to save your password (and fails to display any error in this case). – Vendetta

This answer is obsolete since Subversion 1.12. Try the official "manually save password" workaround instead. – Pinna

Answer 2

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.

Hedvige

+1 I have this exact problem - svn+ssh always, always asks me for a password. Outside of a sharing a public key, is there a way to avoid this? I have tried ssh-agent, but with no luck. – Pali

@MichaelMikowski Seems SSH password cannot be saved to config for automatic login. You can create a new key-pair for it, store the location of the private key to .ssh/config, append the public key to SVN server. – Stereochemistry

Answer 3

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.

Shock

You mean the .subversion folder instead! – Grazing

I had the same problem. I didn't have any of the store-password settings set to "no" in my config or servers file, but this worked. – Salade

I was trying to change all kinds of settings to no avail. The only thing that ultimately solved this issue was indeed to delete the .subversion folder. – Distrustful

This worked for me as well. Interestingly, it stored the password inside ~/.subversion/auth/svn.simple folder for me. – Letterperfect

This did it for me as well, but I watched to see what the difference was — and it turned out to be ownership of the .subversion directory and its files. After transferring data from another machine, this directory somehow ended up owned by root, when it should be owned by me. Removing the directory and letting svn recreate it fixed the problem (but chown probably would have fixed it just as well). – Vendetta

this worked. after answering yes, i was never prompted again. but a note during process may contain why: You can avoid future appearances of this warning by setting the value of the 'store-plaintext-passwords' option to either 'yes' or 'no' in '/root/.subversion/servers'. however, store-plaintext-passwords was NOT specified in /root/.subversion/servers after saying yes. In fact, there were ZERO active options in config or servers. – Brakeman

Answer 4

Saving plaintext passwords was intentionally disabled in svn starting from version 1.12. There's no configuration key to re-enable this feature. The only way to make Subversion save your password as a plain text is to enable it at the compile time.

However, Subversion is still able to read the plaintext passwords.
And there's an official script to manually save your password as a plain text.

1. Consider removing any edits from ~/.subversion/config and ~/.subversion/servers. Just remove both files if in doubt.
2. Use your svn server at least once (e.g. checkout something).
   Verify and permanantly accept the server server certificate fingerprint, if asked.
   This would generate ~/.subversion/auth/svn.simple/xxxxx file (where "xxxxx" is some hash), but there would be no password in it yet.
3. Run svn auth and note the
   Authentication realm: <https://myserver.mydomain:12345> VisualSVN Server string in the output.
4. Use the official workaround script to store your password as plaintext:

wget https://svn.apache.org/repos/asf/subversion/trunk/tools/client-side/store-plaintext-password.py
chmod +x store-plaintext-password.py
./store-plaintext-password.py -u your_username "<https://myserver.mydomain:12345> VisualSVN Server"

5. doublecheck that ~/.subversion/auth/svn.simple/xxxxx now actually contains your password
6. chmod 700 ~/.subversion/auth/svn.simple/xxxxx
7. chmod 700 ~/.subversion/auth/svn.simple
8. try using your svn server again (e.g. svn update).

Just tested on svn version 1.14.1 (r1886195), installed with simply apt install subversion, on Ubuntu 22.

Pinna

Thanks! I have subversion 1.13.0 and this is the only answer that worked for me. – Chlamydate

Thanks! Also worked for me on SUSE Linux and svn version 1.14.1 – Allochthonous

Thanks!, this has been the only thing to finally get me up and running. svn: 1.14.1, Ubuntu 22.04.2 LTS – Mean

thanks, works for me too, although i just copied from a server to another.. – Plowshare

Answer 5

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.

Algonquian

In the same file, I had to set store-passwords = yes. I believe it was set before, but got unset when I updated to SVN 1.7 – Scribe

No matter what I do I can't get this to work using cygwin over http, svn svn, version 1.14.2 (r1899510) – Sunstone

Answer 6

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.

Favored

Thanks. For my svn v1.14, GPG-Agent is the only option. – Uptotheminute

Answer 7

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.

Grady

This helped me also, as seems default option should work, but unless explicitly specified, it doesn't :( – Leukorrhea

Instead of an empty setting I had to use password-stores = gnome-keyring. – Dubitable

Answer 8

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.

Accipitrine

That helped to see that there was a overriding at the same file (two "password-stores" declaration!). Corrected that and the svn.simple file was created with gnome-keyring property. – Nekton

Answer 9

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.

Ahem

Answer 10

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

ssh-copy-id user@remotehost

Septennial

Answer 11

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 ;)

Brandibrandice

Answer 12

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.

Declan

Answer 13

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.

Horotelic

Answer 14

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.

Imagism

Thank you. I tried everything but nothing worked. Then I renamed the 'auth' folder and tried again. This folder was regenerated with subtly different contents in auth/svn.simple/<hash> file and then it just worked. – Nestornestorian

Answer 15

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.

Scotticism

Answer 16

I finally discovered a way to use gnome-keyring from within ssh and other non-interactive scripts:

So you can leave subversion configured to not store plain text passwords. Instead configure it to use gnome keyring. I think that's the default on ubuntu anyway.

Then use the magic script found here to persistently unlock the keyring on the machine:

https://unix.stackexchange.com/questions/602313/unlock-gnome-keyring-daemon-from-command-line

~/bin/unlock-gnome-keyring:

echo 'NOTE: This script will only work if launched via source or .' >&2
echo -n 'Login password: ' >&2
read -s _UNLOCK_PASSWORD || return
killall -q -u "$(whoami)" gnome-keyring-daemon
eval $(echo -n "${_UNLOCK_PASSWORD}" \
           | gnome-keyring-daemon --daemonize --login \
           | sed -e 's/^/export /')
unset _UNLOCK_PASSWORD
echo '' >&2

Massorete

Answer 17

The only solution that worked for me was following the instructions from svnbook.

As per the instructions, I deleted the correct file:

$ ls ~/.subversion/auth/svn.simple/
5671adf2865e267db74f09ba6f872c28
3893ed123b39500bca8a0b382839198e
5c3c22968347b390f349ff340196ed39

$ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28

K 8
username
V 3
joe
K 8
password
V 4
blah
K 15
svn:realmstring
V 45
<https://svn.domain.com:443> Joe's repository
END

Once I located the proper cache file, I deleted it, and then I did svn up. The username and password were saved properly.

Actinochemistry