Problems configuring Duplicacy with keyring (Linux)

Support
#1

I’m having a hard time trying to setup Duplicacy to run in a cloud VM using keyring for passwords…

I already read some posts regarding this subject, like this, this and this.

It’s a Digital Ocean droplet, running Debian 10 x64 (already tried Ubuntu also).

I can run commands without problems as long as I save the passwords in the preferences file. But, for security reasons, I prefer to use keyring.

set command returns:

DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1000/bus

And whem I try sudo --preserve-env duplicacy -d list I get:

Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: read unix @->/run/user/1000/bus: EOF

for each of the “application” variables (I’m using B2) and for the storage password, and at the end I get:

Failed to store the value to the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: read unix @->/run/user/1000/bus: EOF

If I run unset DBUS_SESSION_BUS_ADDRESS

and run the Duplicacy command again I get:

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

and at the end:

Failed to store the value to the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: dbus: DBUS_SESSION_BUS_ADDRESS not set

I’ve searched dozens of forums looking for a solution.

Any idea?

macOS keychain troubles: stores empty credentials?
Duplicacy no longer seems to be able to access gnome-keyring
#2

Does that file contain correct data? It seems it reached end of file unexpectedly while trying to fetch session id?

#3

I found instructions here for setting up keyring on headless linux very clear: keyring · PyPI

That is, run these two commands first before duplicacy:

dbus-run-session -- bash
gnome-keyring-daemon --unlock
#4

This bus is a socket:

~$ file /run/user/1000/bus
/run/user/1000/bus: socket
#5

The first command worked perfectly, but the second became unresponsive. After a few minutes I canceled with ^C.

Now I get:

~$ ps -ef | grep gnome
    1  0 11:52 pts/1    00:00:00 /usr/bin/gnome-keyring-daemon --start --foreground --components=secrets

When rerunning the Duplicacy command, the error messages changed:

Failed to get the value from the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: read unix @->@/tmp/dbus-s7GAAcJBR9: EOF

Failed to store the value to the keyring: keyring/dbus: Error connecting to dbus session, not registering SecretService provider: read unix @->@/tmp/dbus-s7GAAcJBR9: EOF

Notice the tmp…

Now I’m searching for "gnome-keyring-daemon --unlock unresponsive" :upside_down_face:

#6

I ran it again, this time providing the root password (?!). Still unresponsive after ctrl+D.

Now I get:

/usr/bin$ duplicacy -d list
dbus-daemon[739]: [session uid=1000 pid=739] Activating service name='org.freedesktop.secrets' requested by ':1.0' (uid=1000 pid=756 comm="duplicacy -d list ")
** Message: 12:25:16.412: The Secret Service was already initialized

and stops there.

Dbus "authentication failed"
#7

Some more info:

~$ sudo journalctl --since="72 hours ago" | grep -i gnome-keyring

returns:

Aug 03 11:52:56 gnome-keyring-daemon[625]: couldn't access control socket: /run/user/1000/keyring/control: No such file or directory
Aug 03 12:25:16 gnome-keyring-daemon[625]: The Secret Service was already initialized

/control end path ? :thinking:

#8

One more step:

Failed to store the value to the keyring: keyring/dbus: CreateItem error: Cannot create an item in a locked collection
#9

@gchen, it looks like the secret-tool looks in the keyring for a attribute-value format:

secret-tool lookup {attribute} {value}

ref: Ubuntu Manpage: secret-tool - Store and retrieve passwords

Considering Passwords, credentials and environment variables, what would be the “attribute-value” to look for?

#10

I don’t know if secret-tool can see the password created by Duplicacy, but I used lssecret and found it:

~/lssecret/lssecret 
Collection:	

Collection:	Login

Item:	password - duplicacy
Key:	xdg:schema
Value:	org.freedesktop.Secret.Generic
Key:	username
Value:	password
Key:	service
Value:	duplicacy
1 Like
#11

I used a new (empty) keyring for which I ran duplicacy -d list to perform the initial setup of passwords.

I used lssecret and got:

Item:   <storage redacted>_password - duplicacy
Secret: <storage password redacted>
Key:    xdg:schema
Value:  org.freedesktop.Secret.Generic
Key:    username
Value:  <storage redacted>_password
Key:    service
Value:  duplicacy

(note: username is not redacted, it is actually the word “username”)

I think this will be the way forward.

#12

I’ve been thinking: what if there was the option (opt-in) of using in Linux the same type of keyring file specific to :d:, the same way it is done in Windows? Wouldn’t it facilitate this type of setup?
:thinking:

#13

Windows provides an encryption API for this kind of usage. Linux doesn’t have an equivalent. It is easy to implement a simple encryption scheme (like what I did for the web GUI) but I think keyring is much safer.

#14

I agree, but it’s much more complicated to make it work flawless (just look at this topic) and it’s problematic with different sessions/users.