Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

KeepassXC not finding my running ssh-agent #3683

Closed
rsevero opened this issue Oct 27, 2019 · 15 comments
Closed

KeepassXC not finding my running ssh-agent #3683

rsevero opened this issue Oct 27, 2019 · 15 comments
Assignees

Comments

@rsevero
Copy link

rsevero commented Oct 27, 2019

When opening KeePassXC in my Artix machine I get the following error message:

No agent running, cannot add identity.

but I already have a ssh-agent running with the same user as I run KeepassXC as you can see below:

ps axuwf | grep ssh-agent
rodrigo   3449  0.0  0.0   5792   456 ?        Ss   06:36   0:00 ssh-agent

and

$ ps axuwf | grep keepassxc
rodrigo   4973  2.2  1.0 701136 84028 ?        SLl  07:15   0:01          |   \_ keepassxc

ssh-agent is setting the necessary environment variables, AFAICT:

$ set | grep SSH
SSH_AGENT_PID=3449
SSH_AUTH_SOCK=/tmp/ssh-2gEren5eA1JD/agent.3448

and ssh-agent's socket exists and is writeable by the appropriate user:

$ ls -Flah /tmp/ssh-2gEren5eA1JD/agent.3448
srw------- 1 rodrigo rodrigo 0 out 27 06:36 /tmp/ssh-2gEren5eA1JD/agent.3448=

Expected Behavior

I expected that when starting, KeePassXC managed to add my keys to the already running ssh-agent

Current Behavior

Keys aren't added to my ssh-agent

Steps to Reproduce

  1. Have ssh-agent started by ~/.bashrc through the following code:
if ! pgrep -u "$USER" ssh-agent > /dev/null; then
    ssh-agent > "$XDG_RUNTIME_DIR/ssh-agent.env"
fi
if [[ ! "$SSH_AUTH_SOCK" ]]; then
    eval "$(<"$XDG_RUNTIME_DIR/ssh-agent.env")"
fi
  1. Login KeePassXC
  2. See the error message "No agent running, cannot add identity.¨

Context

I can't identify any special circunstances that affect me. I believe I have a rather standard ssh-agent and KeePassXC install.

Debug Info

KeePassXC - Version 2.4.3
Revision: 5d6ef0c

Operating system: Linux Artix
CPU architecture: x86_64
Kernel: Linux version 5.3.6-artix1-1-ARTIX (builduser@orion) (gcc version 9.2.0 (GCC)) #1 SMP PREEMPT Sun Oct 13 15:42:39 UTC 2019

Plese let me know if you need any extra info.

@rsevero rsevero added the bug label Oct 27, 2019
@droidmonkey
Copy link
Member

Are you using the snap or flatpak?

@hifi
Copy link
Member

hifi commented Oct 29, 2019

Your .bashrc hack to start ssh-agent is likely the issue. The agent needs to be started as part of the session for programs that are not launched from your terminal to pick up any environment variables it exports.

The correct way to start it is part of any auto-start scripts that are run by your DM/WM or before they are executed. IIRC you can just add eval $(ssh-agent) into any startup script for it to export the environment variables into your login environment.

@Kusoneko
Copy link

Kusoneko commented Nov 2, 2019

I have the exact same problem and setup on Arch Linux w/
Kernel: Linux version 5.3.7-arch1-2-ARCH (linux@archlinux) (gcc version 9.2.0 (GCC)) #1 SMP PREEMPT @1572002934

@hifi, the KeepassXC documentation https://keepassxc.org/docs/#faq-ssh-agent-not-working here mentions that the ArchLinux Wiki offers a generic way to get the ssh-agent started, which is where I picked that .bashrc hack and I'm assuming the same is true of @rsevero. There are more than one "generic way" to get ssh-agent started in the ArchLinux Wiki, I'm not sure which of the possible ways to auto-start it I'm supposed to use that KeepassXC would support. Should I use the systemd user method? or maybe the hacky alias startx='ssh-agent startx' in .bash_aliases to start ssh-agent with the X session? The documentation would need to be clearer on that.

EDIT: So, I tried out the systemd user method and that doesn't work either, so my next option is gonna be the alias one. If it doesn't work, I'm just gonna go in either ~/.bash_profile and start it before startx runs or start it in the ~/.xinitrc file, which I'm assuming either of them would work properly. Hopefully.

@rsevero
Copy link
Author

rsevero commented Nov 4, 2019

Are you using the snap or flatpak?

None. Using AUR (Arch Linux) install.

@hifi
Copy link
Member

hifi commented Nov 5, 2019

@Kusoneko an entry in ~/.xinitrc before the WM/DM is started is the correct way if you're using startx without a login manager.

Some distributions (like Debian et al.) have a generic session script to launch the agent regardless of your WM/DM with a login manager: https://packages.debian.org/buster/all/x11-common/filelist 90x11-common_ssh-agent.

If you start your agent manually after the session is launched the socket path environment variable SSH_AUTH_SOCKET will be empty and it needs to be visible to KeePassXC when it's launched to work.

Since the agent settings page doesn't really have much in it I think showing the agent socket path from the effective environment and allowing the user to override it might be a good solution for a lot of people who are using non-standard methods of running the agent with a static socket path.

Created #3795 to track this.

@Kusoneko
Copy link

Kusoneko commented Nov 5, 2019

@hifi I don't remember exactly how I setup my X server, so I guess we'll know later when I add it to ~/.xinitrc and reboot.

But I hope #3795 will pass though. It would sove this sort of issue where people start ssh-agent in different ways.

@hifi
Copy link
Member

hifi commented Nov 5, 2019

If anyone with this issue has the ability to build and test #3801 it would be great, thanks!

@Kusoneko
Copy link

Kusoneko commented Nov 5, 2019

I'm gonna look into it

Just built and installed it, it seems to work -- doesn't complain about ssh-agent not running once I gave it what my terminal's echo $SSH_AUTH_SOCK returns.

@droidmonkey
Copy link
Member

@hifi does #3801 fix this issue?

@hifi
Copy link
Member

hifi commented Jan 5, 2020

@droidmonkey #3801 sort of solves this as it should help the user to discover the underlying issue. I don't consider this an actual bug as it depends on the way you set up your agent.

@droidmonkey
Copy link
Member

Ok closing then

@frederickjh
Copy link

I ran into this too. There is a lot of information out there telling people to start the ssh-agent in their shell startup scripts, ie. .bashrc, config.fish etc.

There are also linux distributions that automatically setup programs like Gnome Keyring, that start their own ssh-agent.

I had to disable the later in the automatic start programs on my distribution. I also checked that the ssh-agent was not being started in my shell startup scripts and then after a reboot I was able to get the KeepassXC ssh-agent working.

So, in the end there are a number of issues that could be causing it to not work.

@frederickjh
Copy link

frederickjh commented Jan 16, 2021

I just had to set this up on a new computer and ended up back here at my own comment. So, in case someone else looking for help ends up here here is what worked for me. This is on Ubuntu 18.04 Bionic, but it may work for other Ubuntu version and other linux distros. I am pretty sure this is also what I did on 16.04 too.

  • In the Startup Applications I found SSH Key Agent (GNOME Keyring: SSH Agent) and un-ticked the box for it to auto start.
  • After a reboot, KeepassXC reported that the "SSH Agent connection is working!"

I checked to see if the ssh-agent was being started by 90x11-common_ssh-agent by having it set some test environmental variables.
The /etc/X11/Xsession.d/90x11-common_ssh-agent file (that @hifi mentioned above) is sourced at xstart and SSH_AGENT_SOCKET gets set. This looks like this is the syslog file:

Jan 16 20:01:01 hostname systemd[4272]: Starting Start gnome-keyring as SSH agent...
Jan 16 20:01:01 hostname systemd[4272]: Started Start gnome-keyring as SSH agent.
Jan 16 20:01:01 hostname systemd[4272]: Started OpenSSH Agent.
Jan 16 20:01:01 hostname agent-launch[4588]: dbus-update-activation-environment: setting SSH_AUTH_SOCK=/run/user/1000/openssh_agent
Jan 16 20:01:01 hostname agent-launch[4588]: dbus-update-activation-environment: setting SSH_AGENT_LAUNCHER=openssh
Jan 16 20:01:01 hostname agent-launch[4588]: SSH_AUTH_SOCK=/run/user/1000/openssh_agent; export SSH_AUTH_SOCK;

I am not sure why it logs that the gnome-keyring is started as the ssh agent but removing it from the start up applications in the GUI (as describe above) allows this to work and KeepassXC is able to see the SSH_AUTH_SOCK environmental variable.
.

@jakec-dev
Copy link

I'm having the same issue. Is anyone able to provide the actual fix for this please? Do I just copy and paste the SSH stuff in .bashrc to .xinitrc?

@hifi
Copy link
Member

hifi commented Jul 8, 2021

Run ssh-agent from xinitrc:

$(ssh-agent)

Or something along these lines before your WM starts. The dollar wrapping is required for the environment variables to be exported to the shell properly. Backticks may work as well.

In regular DE setups it is started by the DE and the environment value is inherited to sub-processes of the DE. This is the default behavior of almost any distribution these days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants