Hi, thanks for the info in this thread. It lead me into a work-around
that seems to work for me.
The scenario in my case: something is defining SSH_AUTH_SOCK but there's
no ssh-agent running, despite use-ssh-agent being set in
/etc/X11/Xsession.options. gnome-keyring-deamon is however running,
where it's started is however unknown to me.
The reason seems different (opposite) but the ssh-behavior is the same:
It's not possible to log-in with keys.
In my case I'm running unity and LightDM but have have a set-up where
both unity, i3 and gnome has been VM/DM. I also still like to alter
between VM:s as the machine is used by different users liking one or the
other VM more.
What's possibly worsened it is that the system has not had a clean re-
install since 8.04, i.e. it's always been upgraded. (Some-where along
the way I believe recalling having issues with gnome-keyring and
possibly making an effort to disable it.)
As I don't know where these environment variables are being set (not
even SSH_AGENT_PID which in my case is unset), my workaround is to put
the following line in /etc/bash.bashrc:
if [ "X$(ps -Al -u $USER | grep ssh-agent)" == "X" ]; then
unset SSH_AUTH_SOCK
fi
I'd appreciate feed-back if there are serious drawbacks with this
approach or if a better/right way to manage this exists. (One obvious
drawbacks is that tweaks like this become obsolete whence the right
solution is pushed by the distribution and may cause new issues whence
upgrading/updating, which may be how I ended up here in the first pace).
Thanks
--
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-keyring in Ubuntu.
https://bugs.launchpad.net/bugs/1586835
Title:
ssh-agent fighting gnome-keyring on Ubuntu Gnome 16.04
Status in gnome-keyring package in Ubuntu:
Confirmed
Bug description:
Sometimes I open a terminal and try to login to a remote server, just
to be greeted by a command-line-based prompt asking for my password.
Whenever that happens, it is ssh-agent instead of gnome-keyring that
is providing the SSH agent capabilities:
$ echo $SSH_AUTH_SOCK
/tmp/ssh-qeG7CTbx4w7D/agent.4592
$ ps -p 4592 -f
UID PID PPID C STIME TTY TIME CMD
xeno 4592 4576 0 20:53 tty3 00:00:00
/usr/lib/gnome-session/gnome-session-binary --session=gnome
$ ps -p $SSH_AGENT_PID -f
UID PID PPID C STIME TTY TIME CMD
xeno 4652 4592 0 20:53 ? 00:00:00 /usr/bin/ssh-agent
/usr/bin/im-launch gnome-session --session=gnome
I usually close the GNOME Terminal and open a new one (sometimes I
must do this more than once), and I eventually get the expected
output:
$ echo $SSH_AUTH_SOCK
/run/user/1000/keyring/ssh
$ ps -p $SSH_AGENT_PID -f
UID PID PPID C STIME TTY TIME CMD
xeno 4652 4592 0 20:53 ? 00:00:00 /usr/bin/ssh-agent
/usr/bin/im-launch gnome-session --session=gnome
Interestingly, the $SSH_AGENT_PID variable seems to continue pointing
to the process where ssh-agent is running.
Generally once I get the keyring socket in the $SSH_AUTH_SOCK
environment variable, it will stay that way even when I close the
terminal and launch a new one.
This seems to be a weird conflict between two programs offering the
ssh-agent service.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/1586835/+subscriptions
--
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help : https://help.launchpad.net/ListHelp
