-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Comments
Are you using the snap or flatpak? |
Your 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 |
I have the exact same problem and setup on Arch Linux w/ @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 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 |
None. Using AUR (Arch Linux) install. |
@Kusoneko an entry in 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 If you start your agent manually after the session is launched the socket path environment variable 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. |
If anyone with this issue has the ability to build and test #3801 it would be great, thanks! |
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 |
@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. |
Ok closing then |
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. 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 So, in the end there are a number of issues that could be causing it to not work. |
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.
I checked to see if the ssh-agent was being started by 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 |
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? |
Run ssh-agent from xinitrc:
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. |
When opening KeePassXC in my Artix machine I get the following error message:
but I already have a ssh-agent running with the same user as I run KeepassXC as you can see below:
and
ssh-agent is setting the necessary environment variables, AFAICT:
and ssh-agent's socket exists and is writeable by the appropriate user:
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
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.
The text was updated successfully, but these errors were encountered: