Can't make SVN store passwords, even though the configuration is set to allow it

Question

I did everything the book says, i.e. removed the authentication files from .subversion/auth, and explicitly set the relevant configuration parameters to 'yes' even though this is a default, and yet the shell SVN commands ask for a password each time. The repository is on cvsdude.com, and the client is Linux. I also use the Subclipse plugin that caches the password OK.

I vaguely remember that when I started working with it, the command asked interactively if I wanted to save clear password, and I said no. Can this choice be stored somewhere and take precedence over the configuration?

Answer 1

With recent versions of Subversion (~ 1.8) you can configure password caching via $HOME/.subversion/servers:

[global]
store-passwords = yes
store-plaintext-passwords = yes

But depending on your system this may be not enough. If it is not, make sure that $HOME/.subversion/config contains:

[auth]
password-stores =

Which means that the variable password-stores is explicitly set to the empty string (background is that svn now contains support for some key-agent tools - and the interfacing to the default configured ones may be fragile - resulting in silent ignoring of the above options and non-caching behaviour).

When using svn for the first time, the hierachy $HOME/.subversion is created after the first svn operation - e.g. when doing the first checkout. Subversion creates then the mentioned files and fills them with the most important options - commented out, including some documentation.

Thus, it also makes sense to move an old $HOME/.subversion directory away to have a well-defined starting point.

Another pitfall are permissions - i.e. files which are not readable under $HOME/.subversion - but this should not often be the problem, because when svn creates them, it takes care of the right permissions (e.g. the auth directory is only readable by the user then, not by the group/all, independent of the configured umask).

Answer 2

Veni

I believe I tried everything:

• checked the server configuration
• checked the ~/.subversion permissions, all 600
• checked the ~/.subversion/config file
  • store-plaintext-passwords = yes
  • store-passwords = yes
  • store-auth-creds = yes
    • did the above both in the [global] and [groups] section with my username
• checked the ~/.subversion/servers file
  • same as above

For all configuration files, I verified all sections, and also entered one wrong parameter and verified that the svn client stopped working (so, the config file was being read).

• removed and re-created the ~/.subversion/auth directory

Checked that the client configuration in $HOME/.subversion/config disabled password stores:

[auth]
### Set password stores used by Subversion. They should be
### delimited by spaces or commas. The order of values determines
### the order in which password stores are used.
# password-stores = gpg-agent,gnome-keyring,kwallet
### To disable all password stores, use an empty list:
password-stores =
### Both 'store-passwords' and 'store-auth-creds' can now be
### specified in the 'servers' file in your config directory
### and are documented there. Anything specified in this section
### is overridden by settings specified in the 'servers' file.
store-passwords = yes    # just in case
store-auth-creds = yes   # just in case

Nothing worked.

Vidi

Then I read the fine manuals. Everything was copacetic: you are not expected to be able to do this. "On Unix systems, client-side storage of passwords in plaintext on disk is disabled by default at compile-time".

Vici

Fortunately, the part that reads the passwords is still there in the client binary. So, if the password happened to be stored, it would work. I am running SVN 1.13:

svn, version 1.13.0 (r1867053)
   compiled Mar 24 2020, 12:33:36 on x86_64-pc-linux-gnu

So I opened the file just created in the ~/.subversion/auth/svn.simple directory (it may contain more than one file, you might need to inspect them to find the one with the realm you want) and found this content:

K 15
svn:realmstring
V 37
<svn://home.sweet.home:3690> Profekto
K 8
username
V 6
lserni
END

The syntax is straightforward: "K" is the key followed by the length of the key, "V" is the value followed by the length of the value.

At the top of the file, I added by hand the eight lines that supply the plaintext password:

K 8
passtype
V 6
simple
K 8
password
V 20
NotTheActualPassword

(Note: on the latest Ubuntu, passtype is by default gpg-agent, and so my password gets overwritten. So I have to change "K 9 V gpg-agent" to "K 6 V simple". You may not believe this - and I might have made some mistake when I thought I observed this behaviour - but if the K 8 passtype is not present in the file, you have to add it before username and password, or it will not work).

and now it works.

Answer 3

Since SVN 1.12 (April 2019), you basically can't. From the Release Notes:

On Unix-like systems, client-side storage of passwords in plaintext on disk is now disabled by default at compile-time. Password caching mechanisms based on Gnome Keyring, Kwallet, or GPG-Agent, are recommended instead.

This change does not affect Windows or Mac OS platforms, where passwords have always been stored in an encrypted representation.

So... unless you compiled your own SVN client, you now most probably have a version that does not allow plaintext passwords to be stored.

By the way, your previously working plaintext password may even stop working after a Subversion upgrade.

If you don't bother entering the password once per session, using gpg-agent is quite easy, though. Just start it with gpg-agent --daemon, run your svn command entering the password, and the next command won't request it anymore.

Answer 4

I would like to submit a detailed answer in case it helps someone in future.

Subversion 1.6 and later will cache your username and password by default however it will not cache the passwords in plaintext unless you explicitly allow it via the command line or by changing the Subversion configuration.

If you checked out a working copy using the --username and --password options you will see the following message:

-----------------------------------------------------------------------
ATTENTION! Your password for authentication realm:

<https://subversion.assembla.com:443> Assembla Restricted Area

can only be stored to disk unencrypted! You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible. See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'~/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? 

So as mentioned in the message, subversion will only save the password unencrypted if you enter 'yes'. If you do so then you should not need to add the --username or --password options when performing svn commands in future.

However, if you prefer not to see this prompt at all you can change the global configuration for your Subversion client by changing the configuration file called "server" on your local machine. It is stored here:

~/.subversion/server

You will need to add the following lines to the "server" file:

[global]
store-plaintext-passwords = yes

With this change, you only need to perform an svn command using the --username and --password options once. Then Subversion will automatically save your credentials without the above prompt.

For more information on disabling this warning about caching passwords in plain text see the Subversion 1.6 Security Improvements blog post.

Answer 5

I ran into this same issue, and believe I set all the appropriate configs in .subversion/servers and .subversion/config, too, tried removing .subversion/auth, etc., but to no avail.

I ended up saving the credentials by moving the .subversion directory (or removing it would work too) and running svn co. I got the following message:

-----------------------------------------------------------------------
ATTENTION!  Your password for authentication realm:

   <http://sweeney:80> Subversion repository

can only be stored to disk unencrypted!  You are advised to configure
your system so that Subversion can store passwords encrypted, if
possible.  See the documentation for details.

You can avoid future appearances of this warning by setting the value
of the 'store-plaintext-passwords' option to either 'yes' or 'no' in
'/home/davids/.subversion/servers'.
-----------------------------------------------------------------------
Store password unencrypted (yes/no)? 

I typed yes, and then got the same message. Stubbornly, I typed yes again. Now my password seems to be saved.

Somewhat surprisingly, looking at the configs in .subversion, none of the settings are uncommented; they're all set to the defaults, so I imagine I would have to answer this warning twice to save a password for a different server in the future.

Hope this helps.

Answer 6

I think I've found a helpful hint here: http://svn.haxx.se/users/archive-2013-07/0094.shtml

As I understood, the client forgot to check if a "gpg-agent" is currently running.

It is inserting the "passtype" = "gpg-agent" into the ~/.subversion/auth/svn.simple/-cache-files by default.

That is a mistake!

As a solution (and to avoid to alter the password-cachefiles in ~./subversion/auth/svn.simple/ by hand) remove these file (but make a save-copy).

Add the line, into ~/.subversion/config ([auth]-section):

password-stores=

(CONSIDER: the empty value! This prevents the client from choosing any wrong stuff and assume "simple".)

Now e.g. try a:

svn up

Subversion will now warn you to save plain passwords.

If you got no problem with that, type "yes" and all is fine again.

After that, Subversion has created a cache-file for a particular server, and you can remove the "password-stores"-entry again.

Answer 7

Delete old stored password like rm ~/.subversion/auth/svn.simple/*. I have tried every other suggestion and this is what worked for me.

Answer 8

Nothing worked for me, no matter what I've done. I checked all possible options, config files and hundred pages in google about this problem. Eventually I gave up and just put this into my .bashrc

alias svn='svn --password <mypassword>'

Answer 9

Thanks to your comments I found the problem - it's the settings in the servers file (don't store plain passwords). I wonder why there is this redundancy with the [auth] section of the configuration file. The SVN book also does not mention this when talking about storing passwords.

Answer 10

I needed to make to changes to the server file to make this work for me

# Password / passphrase caching parameters:
store-passwords = yes
store-plaintext-passwords = yes

Answer 11

On Windows with slikSVN, I was having the same issue, but only with one of the projects, so I went in %AppData%\Roaming\Subversion\auth\svn.simple and deleted the file containing that project information.

The next SVN command I typed asked for the password and created the file again and now it's running great.

Maybe the fact I changed configuration and servers files helped too, but it was not working till I deleted that file (and it was working also with the previous configuration till there was a password issue on the server and the administrator reset permissions).

Answer 12

You may use the gnome-keyring even without X inited. You should run

export `gnome-keyring-daemon`

on login and

kill $GNOME_KEYRING_PID

before logout.

Then you can use keyring_tool commandline utility.

Answer 13

A solution that worked for me (even isnt' the better solution, at least bailed me out), it's to grant my local user all permissions to ~/.subversion directory and subdirectorys. Then i could do operations on subversion fast without prompt username and password.

Answer 14

If you are trying to reset the authentication on an existing working copy, I'd recommend you checkout a fresh copy after you do all of the above changes. This was the only thing that worked for me when I was trying to release the project with the maven-release-plugin (which uses stored svn credentials in order to auto commit your tags, etc...)

Answer 15

For some odd reason, my .subversion folder was not owned by me and SVN wouldn't save certificates of passwords.

I just did a sudo chown -R me ~/.subversion and now everything works!

Answer 16

Please be aware that there is a difference behaviour related to the password storing between a svn co/up and a svn log!

I tried all of the hints above and alway tried to verify with 'svn log' -- the svn command always asked me again and again for password, no matter if store-plaintext-passwords was set correctly to ask or yes. But when I made a new checkout or update I suddenly had the correct behaviour and my password got save

I assume this is a bug to subversion to have different handling of password storing for the different commands -- at least I read no where about that before.

Answer 17

I experienced such problems after a password change and cured it deleting the SVN configuration (and thus recreating it from scratch).

Answer 18

Delete files from the below directory:

For Windows:

For example:

C:\Users\abcd.xyz\AppData\Roaming\Subversion\auth\svn.simple

abcd.xyz-->username

Note: Delete all files. These files contain meta data about the checkout. The next time when you store your password it will automatically create a file here.

Delete the .keyring file from your STS/Eclipse installation. Stop Eclipse and delete the file.

For example:

D:\Executables\New STS\STS-3.5.0-e4.3.2-win64\configuration\org.eclipse.core.runtime -->.keyring

Answer 19

For Windows Subsystem for Linux (WSL) users, first turn on the gpg-agent: gpg-agent --daemon. The next time you run an svn update, it will prompt you for the password like normal, but the next time you run svn update you will receive a different password prompt from gpg-agent. Enter your password here to save it. If you run into any issues, reset subversion settings by deleting your ~/.subversion directory.

Answer 20

From what I read in the previous answers, none of these worked. What I found to work for me could be a combination of things or this final step which is to open the keychain app, find the key in question.

Right-click and go to "get info". Click access control section on the top. Then click the "Allow all applications to access this item". Although this might do something unintended.

Answer 21

Was able to resolve this in macOS,vscode,

svn version 1.14.1

Change $HOME/.subversion/servers:

[global]
store-passwords = yes

Change $HOME/.subversion/config contains:

[auth]
password-stores = keychain

Goto ~/.subversion/auth/svn.simple Find and delete the config file which contains my svn site.

Open the Keychain Access Tool remove the related keys.

Goto my project folder, run svn up --username xxxx --password xxxx Reopen VSCode. it will be OK.

Answer 22

Alupotha solution worked for me. I also edited ~/.subversion/config and for password-stores set only one key storage tool. I removed all other tools and used gnome-keychain.

password-stores = gnome-keychain

Answer 23

In my case, I had to store an SVN password inside a Docker container.

Changing the settings, as described in other answers, didn't actually help. So I copied the configuration file from another running instance and pasted it into running container to ~/.subversion/auth/svn.simple/14c4b06b824ec593239362517f538b29 (keep in mind, that the hashed string is the actual configuration file).

In that file, set example values:

cat ~/.subversion/auth/svn.simple/14c4b06b824ec593239362517f538b29
K 8
passtype
V 6
simple
K 8
password
V 16
<<YourPassword>>
K 15
svn:realmstring
V 55
<https://svn.example.com:6443> [iSource] SVN repository
K 8
username
V 7
svnuser
END

Pay special attention to the values prepended with V!

If it reads password V 16, it means the actual password is 16 characters long. The same rule applies to all other entries (username V 7 svnuser means, svnuser is 7 characters long, etc.).

Keep it in mind when you update password or username to values of different length.

Answer 24

On Centos there is a shared library that needs to be installed in order to "activate" the Gnome-Keyring setting. So even if you have the password-stores = gnome-keyring line in the config file, it will never do anything unless it finds the libsvn_auth_gnome_keyring-1.so.0 file. Note that there is no error message shown if this shared library is not present - it will simply ignore the setting. I used "strace" on an svn command to figure this out. You need to install the "subversion-gnome" package on Centos and then the password-stores line will be used.