gnome-keyring demands unspecified password, breaking svn commits

Thank you for your bug report, are you sure you are using the right keymap with no capslock enabled? could you run ssh -vvv and get details on what is happening there?

On Tue, Nov 3, 2009 at 9:38 PM, Sebastien Bacher <email address hidden> wrote:

> Thank you for your bug report, are you sure you are using the right
> keymap with no capslock enabled? could you run ssh -vvv and get details
> on what is happening there?
>

That was a quick response!

i'm not using SSH here - the svn repos having this problem are https rather
than svn+ssh (e.g. Google Code), authenticated against credentials the svn
client stored 1+ years ago. If i use kdesvn i do not get prompted for login
info and can commit normally. If i use the command-line client, the keyring
manager wants something from me and i have no idea what. i have verified
that it's happening on all of my repos which use https, e.g.:

stephan@jareth:~/cvs/qboard/trunk$ svn ci -m "just testing gnome-keyring
thingie" config.qmake
Password for 'login' GNOME keyring:
Password for 'login' GNOME keyring:
svn: Commit failed (details follow):
svn: OPTIONS of 'https://qboard.googlecode.com/svn/trunk': authorization
failed: Could not authenticate to server: rejected Basic challenge (
https://qboard.googlecode.com)
stephan@jareth:~/cvs/qboard/trunk$ svn info
Path: .
URL: https://qboard.googlecode.com/svn/trunk
Repository Root: https://qboard.googlecode.com/svn
...

i've tried killing the keyring manager process, but that doesn't solve the
problem - it's apparently getting re-started as part of the authentication
process.

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

Could you try to unset SSH_AUTH_SOCK and see if that makes a difference? what value does it have there?

On Tue, Nov 3, 2009 at 10:45 PM, Sebastien Bacher <email address hidden> wrote:

> Could you try to unset SSH_AUTH_SOCK and see if that makes a difference?
> what value does it have there?
>

stephan@jareth:~/cvs/qboard/trunk$ echo $SSH_AUTH_SOCK
/tmp/ssh-BnKSce7396/agent.7396
stephan@jareth:~/cvs/qboard/trunk$ svn ci -m "testing gnome-keyring thingie"
config.qmake
Password for 'login' GNOME keyring:
svn: Commit failed (details follow):
svn: OPTIONS of 'https://qboard.googlecode.com/svn/trunk': authorization
failed: Could not authenticate to server: rejected Basic challenge (
https://qboard.googlecode.com)

stephan@jareth:~/cvs/qboard/trunk$ unset SSH_AUTH_SOCK
stephan@jareth:~/cvs/qboard/trunk$ echo $SSH_AUTH_SOCK

stephan@jareth:~/cvs/qboard/trunk$ svn ci -m "testing gnome-keyring thingie"
config.qmake
Password for 'login' GNOME keyring:
svn: Commit failed (details follow):
svn: OPTIONS of 'https://qboard.googlecode.com/svn/trunk': authorization
failed: Could not authenticate to server: rejected Basic challenge (
https://qboard.googlecode.com)

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

you still get the password entry? did you try to enter you login password to unlock it?

ignore the question about the login password the response is in the description

you will might to stop gnome-keyring and see if you still get the bug

On Wed, Nov 4, 2009 at 12:20 AM, Sebastien Bacher <email address hidden> wrote:

>
> ignore the question about the login password the response is in the
> description
>

Actually:

stephan@jareth:~/cvs/qboard/trunk$ echo $SSH_AUTH_SOCK

stephan@jareth:~/cvs/qboard/trunk$ svn ci -m "testing gnome-keyring thingie"
config.qmake
Password for 'login' GNOME keyring:
Sending config.qmake
Transmitting file data .

So i must assume i mis-typed my login password before, which i didn't try
until the 3rd or 4th attempt because i though it wanted the password for my
SSH or PGP _key_ (since it is a keyring manager).

:-D

Killing the keyring app didn't help - it was being re-started automatically
each time i tried to commit. That behaviour _might_ go away if i unset
SSH_AUTH_SOCK in my login shell, but i haven't tried (i can't log out just
yet - too many emaces and shells configured for work mode).

Now i've got a workaround, but i'm still damned annoyed that i have to enter
my login password after i'm already logged in (it's not a sudo operation,
after all). i do a considerable of committing, so this is going to get old
really fast.

Nonetheless, THANK YOU Sebastian for the workaround!

i would recommend closing this as "uninformed/surprised user experience",
but i suspect others will soon encounter this problem and be confused by it.
In many years of using svn over SourceForge i've never had this happen, so i
was surprised as hell by it.

:)

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

I was experiencing this issue and I resolved it as follows:

rm ~/.gnome2/keyrings/login.keyring

I could then commit to svn without receiving the "Password for 'login' GNOME keyring:" challenge.

I encountered the same error and the work around does not work for me.

raghu@rp$ echo $SSH_AUTH_SOCK

raghu@rp$
raghu@rpr$ svn update
Password for 'login' GNOME keyring:
svn: OPTIONS of 'https://example.com/svn/repo': authorization failed: Could not authenticate to server: rejected Basic challenge (https://example.com)

I tried both : entering correct password (no capslock) and just typing error.

Is this an svn bug in that it is not handling interaction with keyring properly?

Sorry for the rant but : why is such a restriction is added without me opting in? I never entered any keyring password or explicitly did anything with keyring. This is painful for even for fairly experienced users (but no experience with keyring of course), I wonder how painful it would be for average users.

> why is such a restriction is added without me opting in

the restriction is not wanted, not sure what is going on there bug you can choose to cache your ssh key in gnome-keyring in which case the ssh agent will not to unblock the keyring to access it, I've not seen command line prompts about those though

On Wed, Nov 4, 2009 at 2:12 AM, pleiades <email address hidden> wrote:

> I was experiencing this issue and I resolved it as follows:
>
> rm ~/.gnome2/keyrings/login.keyring
>

After a reboot i was having the problem again (forgot to unset SSH_AUTH_SOCK
in my login script, so i'm not sure if that's a long-term fix or not), but
removing the login.keyring solved it for me. Thanks for that tip :).

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

> rm ~/.gnome2/keyrings/login.keyring

this worked for me too. Thanks.

> the restriction is not wanted, not sure what is going on there bug you can choose to cache your ssh key in gnome-keyring in which case the ssh agent will not to unblock the keyring to access it, I've not seen command line prompts about those though

Thanks Sebastien. Do you think this bug is still "incomplete"?
 It is only a https:// access not a ssh access to the svn server.

Any good pointers to overview of Keyring in Ubuntu/Gnome would be appreciated.

The issue is an upstream one and it would be nice if somebody having it could send the bug the to the people writting the software (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)

On Wed, Nov 4, 2009 at 11:02 PM, Sebastien Bacher <email address hidden> wrote:

> The issue is an upstream one and it would be nice if somebody having it
> could send the bug the to the people writting the software
> (https://wiki.ubuntu.com/Bugs/Upstream/GNOME)
>

It seems like it _might_ be a distro-specific configuration bug (e.g. in a
system-wide configuration file)??? i'll be happy to get the bug report
moving, but i'm quite uncertain about which app/lib/project to assign it to.
What would you recommend, Sebastien?

Thank you again for your excellent help in getting this moving along and
resolved :).

--
----- stephan beal
http://wanderinghorse.net/home/stephan/

I'm still not sure to understand the issue and why gnome-keyring would ask for a password on the command line but upstream could known better though

i have reported this "upstream" at:

https://bugzilla.gnome.org/show_bug.cgi?id=600758

and tagged it as gnome-keyring. Maybe they will know where to categorize it.

Merci, Sebastien!

An update: My machine was rebooted because of a power outage and next time svn commit worked without any of the work-around-s.

The bug report to https://bugzilla.gnome.org/show_bug.cgi?id=600758 is marked as resolved, apparently passing it off as a subversion problem.

I encountered the problem doing a checkin to a subversion repository from inside the netbeans 6.7.1 IDE. Under ubuntu 9.0.4 this worked fine. Under 9.10 such subversion access fails. There is no prompt at all for a keyring password. There is simply a credentials failure.

Removing the login.keyring file fixed it.

Is anyone doing any investigation? If not, I will tackle that.

What changed between 9.04 and 9.10:
gnome keyring?
subversion?
default user settings?

upstream commented saying it's a subversion issue

> rm ~/.gnome2/keyrings/login.keyring
this worked for me too. Thanks.

Could be that the current SVN client (1.6.5) is not completely compatible with older SVN servers. I know I did not have this problem in Ubuntu 9.04 which used SVN 1.5.4 or something around there.

Same problem here, after updating to 9.10. Deleting login.keyring fixed it for me too, allowing me to commit without entering any password.

In order to prevent SVN from asking you for 'login' keyring password you may try to add the following line to [auth] section in ~/.subversion/conf :
password-stores =

E.g.
--- cut ---
### saving of *new* credentials; it doesn't invalidate existing
### caches. (To do that, remove the cache files by hand.)
# store-auth-creds = no
password-stores =

### Section for configuring external helper applications.
[helpers]
--- cut ---

One correction, the file correct file to modify is ~/.subversion/config

I also encountered the problem doing a checkout to a subversion repository (Google code) from inside the netbeans 6.8 IDE. And under my Ubuntu 9.10 (upgraded from 9.04 clean install) subversion access fails. There is no prompt at all for a keyring password. There is just a credentials failure:

OPTIONS of 'https://MYREPO.googlecode.com/svn': authorization failed: Could not authenticate to server: rejected Basic challenge ('https://MYREPO.googlecode.com/svn').

Removing the login.keyring file fixed it (rm ~/.gnome2/keyrings/login.keyring) exactly as Willy Mills wrote on 2009-11-16.

This bug is also present in updated Kubuntu 10.04 beta.

i'm at ubuntu lucid; no ~/.gnome/keyring/.. at all; getting
Password for '(null)' GNOME keyring:
and failure afterwards on any svn server with http/https.

a line:
password-stores =
in the ~/.subversion/config fixes it (as Piotr Piastucki suggested above).

same problem here

echo - "[auth]\npassword-stores = \n" >~/.svn/config did not work

solved problem by rm ~/.gnome2/keyring/*

after breaking ssh-agent, gnome-keyring just earned itself a second scoring point on my "useless daemons creating problems" list. is it really necessary that so many packages depend on gnome-keyring? I would love to be able to purge it from my systems.

I have the exact same problem, deleting the login keyring makes svn fall back to the ~/.subversion/auth plain-text storage.

Gnome-keyring needs a manual which explains how to add password groups and SVN needs some info on where/how it reads off gnome-keyring.

Only commits need passwords for me, so this doesn't hit me when svn up ... only when I svn commit.

Have this issue on Lucid 10.04 too
(without KDE or GNOME installed, only dependencies like libraries/utils, i.e. gnome-keyring)

$ svn log -rhead
Passwort für GNOME-Schlüsselring »(null)«:

solved by rm ~/.gnome2/keyrings/login.keyring
(although it didn't ask for 'login' explicitly ...)

same problem here with my Kubuntu lucid.
I haven't the .gnome2/keyrings/* and adding the [auth]\npassword-stores = \n didn't change anything on my ubuntu.
It's strange, it works well on my old computer (which has an upgrade to lucid) but with my fresh new install of lucid on my laptop, I have this bug from the begining and I can't commit my googlecode, please do something!

the log:
svn commit
Authentication realm: <https://PROJECT.googlecode.com:443> Google Code Subversion Repository
Password for 'MYUBUNTULOGIN': // why is it my ubuntu login here ?
Authentication realm: <https://PROJECT.googlecode.com:443> Google Code Subversion Repository
Username: MYGOOGLELOGIN
Password for 'MYGOOGLELOGIN': //of course the password is good
Authentication realm: <https://PROJECT.googlecode.com:443> Google Code Subversion Repository
Username:
Password for '':
svn: Commit failed (details follow):
svn: MKACTIVITY of '/svn/THING': authorization failed: Could not authenticate to server: rejected Basic challenge (https://PROJECT.googlecode.com)

I've seen this too, on 10.04.

Editing ~/.subversion/config as suggested in comment #23 fixes it, takes gnome keyring out the loop.

I also have to go with comment #28 here, I'm not sure what problems gnome-keyring is trying to solve, but they are not the ones I have. I've already had to turn off its SSH support as I kept on being prompted for keys which were in ~/.ssh and not password protected, now even svn is breaking.

It as if the use case "store passwords securely in one place for users" has forgotten about the other use case "let automated scripts and cron jobs do their work without user intervention"

Did you recently change your system login password? This might be related to #416825.
Try entering your old system login password to the Gnome keyring dialog.

I observe this in a 10.10 installation, shortly after I changed my password with "passwd".
It does seem to be similar to 416825, but that seems to be specific to Ubuntu 1, and
this isn't. Probably the same underlying problem though -- the keyring somehow didn't
notice I changed my password.

As suggested, using my old password for the keyring worked OK, and using my current
password fails.

I am seeing this as "Password for '(null)' GNOME keyring".
I have no idea what is a keyring in general, and what is the '(null)' keyring in particular.
I typed in my sudo password, and it worked, but svn must not require sudo password!

Expected: I expected svn to just work
Actually: "svn update" requires my administrator's password. The prompt to enter this password does not explain anything.

[Yes, I believe the duplicate status is wrong]

$ svn update
Password for '(null)' GNOME keyring:
svn: OPTIONS of 'https://svn.---.com/---/trunk': authorization failed: Could not authenticate to server: rejected Basic challenge (https://svn.---.com)
$ uname -a
Linux --- 2.6.35-28-generic #49-Ubuntu SMP Tue Mar 1 14:40:58 UTC 2011 i686 GNU/Linux

$ cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=10.10
DISTRIB_CODENAME=maverick
DISTRIB_DESCRIPTION="Ubuntu 10.10"

Got the issue with Ubuntu 11.10. And I only see the gnome keyring message if I don't provide my own login parameters in the command. I tried some parameters in the ~/.subversion/config but no working svn so far. So why is it a duplicate? I think the package was compiled against the wrong libraries or there were bugs or someone broke the api.

Right before this issue I had that issue: http://andrewbrobinson.com/2011/11/01/fixing-ssl-handshake-failed-ssl-error-key-usage-violation-in-certificate-has-been-detected-error-on-svn-checkout/

To be perfectly clear about this: I used the --password and --username parameters and it still fails. In that case it should NOT use anything related to the keyring.

Well, if i leave out other parameters it does show the keyring message again even if i provide the login credentials.

I hit this (or very similar) problem on 2 machines, after i have been using & storing password in gnome-keyring

I think my problem is because i changed password on the user using the "passwd" command,
and it is not updating the gnome-keyring. So the gnome-keyring still requires me to enter the "old" password, which is working correctly. I suppose my problem could have been avoided by using some gnome UI tool to change user password.

See bug duplicate for more complete information but posting for posterity (and because I found this through the same SVN problem -- even if that's not the root cause).

1) Run the "Passwords and keys" utility from either that new "Dash" thingie or via "# seahorse" on the command-line
2) Right click the keychain and select "Change password"
3) Update the password to match your login password

Voila.