bug: ssh-agent can't call ssh-askpass unless you manually restart the service

[toast003]

Are you following the right branch?

• [X] My Nixpkgs and Home Manager versions are in sync

Is there an existing issue for this?

• [X] I have searched the existing issues

Issue description

I use ssh-agent with keepassxc to keep my ssh keys safe, however I have noticed that if you enable confirmation to use a key it can't be used since the confirmation dialog never shows up (ksshaskpass in my case).

I have tried debug mode so that it outputs logs (exec ssh-agent with -d instead of -D) and the logs don't really show anything useful:

mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug1: new_socket: type = CONNECTION
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug2: fd 4 setting O_NONBLOCK
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug1: process_message: socket 1 (fd=4) type 27
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug2: process_extension: entering
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug2: process_ext_session_bind: entering
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug1: process_ext_session_bind: recorded ED25519 SHA256:*key goes here* (slot 0 of 16)
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug1: process_message: socket 1 (fd=4) type 11
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug2: process_request_identities: entering
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug1: process_request_identities: key 0 / 2: ssh-ed25519 SHA256:*key goes here*
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug3: identity_permitted: entering: key ED25519 comment "Toast (git)", 1 socket bindings, 0 constraints
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug1: process_request_identities: key 1 / 2: ssh-ed25519 SHA256:*key goes here*
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug3: identity_permitted: entering: key ED25519 comment "Toast (GitHub)", 1 socket bindings, 0 constraints
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug2: process_request_identities: replying with 2 allowed of 2 available keys
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug1: process_message: socket 1 (fd=4) type 13
mar 27 11:53:11 WinMax2 ssh-agent[2537]: debug1: process_sign_request2: entering
mar 27 11:53:11 WinMax2 ssh-agent[2537]: process_sign_request2: user refused key

Maintainer CC

@sumnerevans @lheckemann

System information

- system: `"x86_64-linux"`
 - host os: `Linux 6.8.1, NixOS, 24.05 (Uakari), 24.05.20240327.dirty`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.18.2`
 - nixpkgs: `/nix/store/zaza7mgggz4m5h6z18kajabf4wciaj47-source`

[lheckemann]

I'm guessing this is because it's started independent of graphical-session.target, so the DISPLAY (or WAYLAND_DISPLAY) variable isn't imported into systemd yet. I don't think we should have it depend on the target though, since this could break headless use cases; maybe we can socket-activate the service so that it doesn't start until it's needed (and presumably the graphical session, if any, has already started)?

[toast003]

Yeah, I think having it socket activated would be ideal

[stale[bot]]

Thank you for your contribution! I marked this issue as stale due to inactivity. Please be considerate of people watching this issue and receiving notifications before commenting 'I have this issue too'. We welcome additional information that will help resolve this issue. Please read the relevant sections below before commenting.

If you are the original author of the issue

* If this is resolved, please consider closing it so that the maintainers know not to focus on this. * If this might still be an issue, but you are not interested in promoting its resolution, please consider closing it while encouraging others to take over and reopen an issue if they care enough. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

If you are not the original author of the issue

* If you are also experiencing this issue, please add details of your situation to help with the debugging process. * If you know how to solve the issue, please consider submitting a Pull Request that addresses this issue.

Memorandum on closing issues

Don't be afraid to manually close an issue, even if it holds valuable information. Closed issues stay in the system for people to search, read, cross-reference, or even reopen – nothing is lost! Closing obsolete issues is an important way to help maintainers focus their time and effort.

[purepani]

Still having this issue, if it's possible to fix. It currently breaks most of git for me.