Closed JonMcEntee closed 6 years ago
You don't have a keyring daemon running, it seems.
I know this isn't related to your code at all but, do you know how to start the libsecret daemon on linux? I already installed it using yum install libsecret
uname -r
produces: 3.10.0-693.11.6.el7.x86_64
It should be automatically started when you log in from a GUI.
From a terminal, you can start it like this:
ssh -X <host>
dbus-run-session bash
gnome-keyring-daemon -r
I believe this requires fairly recent dbus packages.
Hi @gaborcsardi ,
I had the same problem in an Ubuntu server (no GUI), so I manually started the keyring from a terminal as you suggested:
ssh -X <host>
dbus-run-session bash
gnome-keyring-daemon -r
** Message: Replacing daemon, using directory: /run/user/1002/keyring GNOME_KEYRING_CONTROL=/run/user/1002/keyring SSH_AUTH_SOCK=/run/user/1002/keyring/ssh
Then, from R:
keyring::key_set(service = "email", username = "name@domain.com")
But I get the following error:
PASSWORD: ***** ** Message: Remote error from secret service: org.freedesktop.Secret.Error.IsLocked: Cannot create an item in a locked collection Error in b_ss_set_with_value(self, private, service, username, password, : Secret service keyring error in 'set': 'Cannot create an item in a locked collection'
Please, let me know if you need any other info.
Cheers.
@gorkang The keyring is locked, you need to unlock it first. Unfortunately you need a GUI for that, AFAIK, at least a remote GUI.
Closing this, since the original issue is solved. Well, as much as possible.
Thanks for your response @gaborcsardi
Not sure why, but even after unlocking the keyring (using seahorse remotely), I keep on getting the same error (it is very likely my own ignorance, though).
Funny enough, the code that for some strange reason seems to work is:
keyring::key_set(service = "email", username = "name@domain.com", keyring = "")
So, same code but with that last keyring = ""
parameter.
Please, don't hesitate to let me know if I am doing something extremely stupid/unsafe.
I have also run into this problem. The problem for me was that the ssh terminal was not connecting to the existing dbus process. To get around this I added the following hack to my ~/.bash_profile
# set dbus for remote SSH connections
if [ -n "$SSH_CLIENT" -a -n "$DISPLAY" ]; then
machine_id=$(LANGUAGE=C hostnamectl|grep 'Machine ID:'| sed 's/^.*: //')
x_display=$(echo $DISPLAY|sed 's/^.*:\([0-9]\+\)\(\.[0-9]\+\)*$/\1/')
dbus_session_file="$HOME/.dbus/session-bus/${machine_id}-${x_display}"
if [ -r "$dbus_session_file" ]; then
export $(grep '^DBUS.*=' "$dbus_session_file")
# check if PID still running, if not launch dbus
ps $DBUS_SESSION_BUS_PID | tail -1 | grep dbus-daemon >& /dev/null
[ "$?" != "0" ] && export $(dbus-run-session) >& /dev/null
else
export $(dbus-run-session) >& /dev/null
fi
fi
I borrowed this from this answer but replaced it with dbus-run-session to remove the X11 dependency. This is a nasty little hack and starts an additional dbus process rather than connecting to the existing one. You should be able force this via setting $DISPLAY and using pam as outlined in this blog post but I couldn't get it working.
Note that this must go in .bash_profile not .bashrc as if it's in .bashrc it will launch a process for every terminal not just the login terminal. This can lead to side-effects such as key presses only registering every second stroke.
Though I can still only get the keyring "" to work which does not persist between sessions. I can't get the default keyring to unlock on ubuntu while headless.