Dbus "authentication failed"

chaseadam · 20 September 2021 14:49

Hoping to get duplicacy working with dbus secrets on my Fedora 34 system.

When running duplicacy with -d in a zsh gnome-terminal session, I see the following:
Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: authentication failed

First chasing a SecretService issue:

Looking at journalctl, I have a corresponding error to duplicacy attempts to access the keyring:
gnome-keyring-daemon[1887]: couldn't write to client: Error sending data: Broken pipe

Using lssecrets, as mentioned by @gchen in Problems configuring Duplicacy with keyring (Linux), the first time failed with
Error: Couldn't get secret service for unkown reason No such secret item at path: /org/freedesktop/secrets/collection/login/7

Running seahorse did not list a “login” keyring and attempts to create an additional keyring did not appear to have any affect (but it did actually create them).

Running gnome-keyring-daemon --components=ssh,secrets --replace appears to have resolved some bad state of the SecretService. After rebooting the system, keyring was present as well, so it seems like it was in some bad state.

Sill receiving same error:

Now, that the keyring access appears to be in a good state (lssecrets is returning values and seahorse has keyring listed), I still receive the same error from duplicacy:

Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: authentication failed

This appears to be the same as https://github.com/gilbertchen/duplicacy/issues/565 from 2019. Would be good to close the loop on that issue with any solution from this thread.

gchen · 21 September 2021 17:21

The error is generated here:

github.com

gilbertchen/go.dbus/blob/8591994fa32f1dbe3fa9486bc6f4d4361ac16649/auth.go#L78-L127


	for _, v := range s {
		for _, m := range methods {
			if name, data, status := m.FirstData(); bytes.Equal(v, name) {
				var ok bool
				err = authWriteLine(conn.transport, []byte("AUTH"), []byte(v), data)
				if err != nil {
					return err
				}
				switch status {
				case AuthOk:
					err, ok = conn.tryAuth(m, waitingForOk, in)
				case AuthContinue:
					err, ok = conn.tryAuth(m, waitingForData, in)
				default:
					panic("dbus: invalid authentication status")
				}
				if err != nil {
					return err
				}
				if ok {

This file has been truncated. show original

The best way to debug this is to add a few Printf statements to that file and then compile your own executable. For instance, you can print out what s contains before entering that loop.

luxaritas · 12 July 2022 03:22

Currently running into this same issue. Pretty sure this had worked fine when I initially set stuff up at the end of last year. Not sure the best way to debug - journalctl doesn’t show anything related.

algebro · 29 July 2022 02:41

I’ve been having this problem on Arch Linux for months now. I’m happy to try and debug the go.dbus loop but I can’t get duplicacy to build for the life of me–it’s complaining about GOROOTs and GOPATHs etc and I can’t figure out the correct directory structure/envvars/etc to satisfy it. I’d appreciate any pointers so I can get my backups working again

sevimo · 29 July 2022 10:03

GO111MODULE=off go get -u github.com/gilbertchen/duplicacy/...

algebro · 29 July 2022 11:16

Thanks, but that’s for downloading and installing upstream as I understand it…in this case I want to check it out for local development and point it to a local folder for go.dbus, which as far as I can tell, dep and go get aren’t able to do. Any suggestions on how to do that?

sevimo · 29 July 2022 16:31

It will download and compile everything including , you can make changes to downloaded code and re-run the command again, just skip -u the next time so it goes faster.

algebro · 29 July 2022 17:43

Thanks, this seems to work, but GoLand’s debugger isn’t letting me see or set breakpoints outside of the main module with this setup. It would be better to get a proper debugger working than to debug with print statements…any ideas?

algebro · 29 July 2022 18:14

In the meantime, stepping through with printf debugging (yuck), we are getting this far:

github.com

gilbertchen/go.dbus/blob/master/auth.go#L140

    
      
          // tryAuth tries to authenticate with m as the mechanism, using state as the
          // initial authState and in for reading input. It returns (nil, true) on
          // success, (nil, false) on a REJECTED and (someErr, false) if some other
          // error occured.
          func (conn *Conn) tryAuth(m Auth, state authState, in *bufio.Reader) (error, bool) {
          	for {
          		s, err := authReadLine(in)
          		if err != nil {
          			return err, false
          		}
          		switch {
          		case state == waitingForData && string(s[0]) == "DATA":
          			if len(s) != 2 {
          				err = authWriteLine(conn.transport, []byte("ERROR"))
          				if err != nil {
          					return err, false
          				}
          				continue
          			}
          			data, status := m.HandleData(s[1])
          			switch status {

The result in s at that point is REJECTED, so obviously the AUTH attempt is failing. Inspecting the arguments to authWriteLine(), we’ve got:

name: EXTERNAL v: EXTERNAL status: 0 data: <algebro in hex>

This is as far as I’ve gotten, I’ll probably have to go read the dbus spec to figure out what could be wrong with those variables.

sevimo · 29 July 2022 18:41

Is your keyring password different from your login password? I’d remove/re-create login keyring to see if this fixes the problem.

algebro · 29 July 2022 18:48

It is not, and the issue is occurring on all of my Arch computers where it worked fine before (without any changes to my keyring or login passwords) so I don’t think it’s a local keyring problem. Usually when this happens there is some change or bug in the package that hasn’t hit the major distros yet

algebro · 29 July 2022 18:55

So maybe I’m confused…based on the spec, my understanding is we are supposed to first send AUTH EXTERNAL, to which the server responds with DATA (I’ve confirmed this in my testing), and then we send the cred data. What duplicacy is doing right now is sending AUTH EXTERNAL <creds> in the same message without using DATA at all, and the server is responding with REJECTED. Relevant excerpt from spec:

AUTH command

The AUTH command is sent by the client to the server. The server replies with DATA, OK or REJECTED.

If an AUTH command specifies a mechanism, and the server supports said mechanism, the server should begin exchanging SASL challenge-response data with the client using DATA commands.

If the server does not support the mechanism given in the AUTH command, it must send either a REJECTED command listing the mechanisms it does support, or an error.

If the [initial-response] argument is provided, it is intended for use with mechanisms that have no initial challenge (or an empty initial challenge), as if it were the argument to an initial DATA command. If the selected mechanism has an initial challenge and [initial-response] was provided, the server should reject authentication by sending REJECTED.

If authentication succeeds after exchanging DATA commands, an OK command must be sent to the client.

edit: well, I’m kind of stumped now. Manually trying to follow the other flow listed in the spec didn’t work either:

Client: AUTH EXTERNAL
Server: DATA
Client: DATA [username in hex]
Server: REJECTED

algebro · 29 July 2022 20:21

Just to make sure, I’ve also deleted and recreated the login keyring and it’s still not saving the passwords, so no idea why it’s failing

gchen · 1 August 2022 20:02

Is this commit relevant: do not send data with DBUS auth mechanisms · godbus/dbus@31b5df7 · GitHub

algebro · 2 August 2022 14:47

@gchen that patch fixed it! Can you merge it into your fork for duplicacy?

gchen · 13 August 2022 01:01

This commit should fix the issue: Switch to godbus/dbus from gilbertchen/go.dbus · gilbertchen/keyring@2c65fff · GitHub

Please note that this is a commit in gilbertchen/keyring, not gilbertchen/duplicacy. You’ll need to update the dependency to get the fix.

towerbr · 13 August 2022 13:18

@gchen, given that these issues with keyring on linux have already been the subject of several topics here, and it’s something that has been dragging on for some time, it wouldn’t be the case to generate a new CLI 2.7.3 version incorporating this commit (and others) ?

algebro · 1 October 2022 17:55

+1… @gchen any chance of this getting upstreamed?

gchen · 4 October 2022 02:10

A new CLI release should be out in a couple of days.