bug: service.gpg-agent: SSH_AUTH_SOCK not set

[trev-dev]

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

It looks like $SSH_AUTH_SOCK is stubbornly stuck at /run/user/1000/keyring/ssh after setting up services.gpg-agent.

gpgconf --list-dirs agent-ssh-socket puts out /run/user/1000/gnupg/S.gpg-agent.ssh

All of my other configs look great. I can't seem to use the gpg-agent to connect however.

Maintainer CC

No response

System information

programs.bash = {
    enable = true;
    shellAliases = {
      ll = "ls -l";
      la = "ls -al";
    };
  };

  programs.gpg = {
    enable = true;
  };

  services.gpg-agent = {
    enable = true;
    enableSshSupport = true;
    defaultCacheTtl = 60480000;
    defaultCacheTtlSsh = 60480000;
    maxCacheTtl = 60480000;
    pinentryFlavor = "gnome3";
    sshKeys = ["FF9F589746CBDCE989E5C2D75928BCCDC1E7C015"];
  };
}

OS: NixOS 22.05.3231.893b6b9f6c4 (Quokka)

[trev-dev]

It looks like the right env should be set here but it's not in my .bashrc https://github.com/nix-community/home-manager/blob/master/modules/services/gpg-agent.nix#L233

[Pizmovc]

It would not go into your .bashrc, but into .profile which in turn sources /etc/profiles/per-user/${YOUR_USER}/etc/profile.d/hm-session-vars.sh, it should be set there.

[trev-dev]

Thanks for the tip. I have since switched to zsh. Should I leverage home.sessionVariables or programs.zsh.envExtra for this purpose?

[Pizmovc]

I'm also using zsh and have used home.sessionVariables for other variables, but not SSH_AUTH_SOCK, since setting services.gpg-agent.enableSshSupport adds it for you.

One thing that was an issue in my case is that some scripts/services are still launch programs using .../bin/bash program, so I've also had to set programs.bash.enable = true, so that those programs also have correct environment.

[dacioromero]

I was just having the same issue and fixed it. If you're running Gnome on Wayland it could be https://github.com/NixOS/nixpkgs/issues/101616.

I added the following to my home-manager config to fix:

{
  xdg.configFile."autostart/gnome-keyring-ssh.desktop".text = ''
    [Desktop Entry]
    Type=Application
    Hidden=true
  '';
}

[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.

[Neon-44]

1. did you ever find out what was the Problem and how to fix it?
2. unrelated, but does gpg-agent.sshKeys work for you? because it doesn't for me

[Pizmovc]

2. unrelated, but does gpg-agent.sshKeys work for you? because it doesn't for me

It works for me with the config below. I'm using Home-manager on a NixOS.

config

My home-manager gpg.nix

  programs.gpg.enable = true;

  services.gpg-agent = {
    enable = true;
    enableSshSupport = true;
    sshKeys = [ lib.my.personalSshKey.keygrip ];
    maxCacheTtl = 86400; # 24h
    maxCacheTtlSsh = 86400;
    defaultCacheTtl = 14400; # 4h
    defaultCacheTtlSsh = 14400;
    # FIXME: Should be added only when emacs.enable = true
    extraConfig = ''
      allow-emacs-pinentry
    '';
  };

where lib.my.personalSshKey.keygrip evaluates to "041ED89778F45F0C7E7FA6410813530376AEC894" .

I've also had to configure shell a bit to get it working:

home-manager shell.nix

{ pkgs, config, lib, ... }:
{
  programs.zsh = {
    enable = true;
    history.expireDuplicatesFirst = true;
  };

  # Certain programs are started with `/bin/bash program`, which means if I only have ZSH setup,
  # these programs won't have the correct sessionVariables present
  programs.bash.enable = true;
}

And I've also had to configure it a bit on the NixOS side (perhaps you can move this into your home-manager config as well).

My NixOS shell.nix

{ self, config, lib, pkgs, ... }:
{
  environment = {

    loginShellInit = ''
      gpg-connect-agent /bye
      export SSH_AUTH_SOCK=$(gpgconf --list-dirs agent-ssh-socket)
    '';
  };

  users.defaultUserShell = pkgs.zsh;
  programs.zsh = {
    enable = true;

    # Enable starship
    promptInit = ''
      eval "$(${pkgs.starship}/bin/starship init zsh)"
    '';

    # Enable direnv
    interactiveShellInit = ''
      eval "$(${pkgs.direnv}/bin/direnv hook zsh)"
    '';

    ohMyZsh = {
      enable = true;
      plugins = [ "vi-mode" "z" ];
    };
  };
}

[TLATER]

# Certain programs are started with /bin/bash program, which means if I only have ZSH setup, # these programs won't have the correct sessionVariables present programs.bash.enable = true;

I dug into this a bit, seeing the same problem. It turns out that the ~/.profile that should contain the hm-session-vars source is only created if programs.bash.enable is set; i.e., you can fix this without setting up bash by simply adding:

home.file.".profile".text = ''
  . "${config.home.profileDirectory}/etc/profile.d/hm-session-vars.sh"
'';

This will make all the systemd services that launch their processes through bash actually source the session vars.

It's super awkward though, why is this done this way? .profile should never contain anything other than variable assignments, as it is intended to be shell agnostic.

[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.

[avitex]

I posted a while ago about what I suspected to be part of the issue for me in this comment: https://github.com/NixOS/nixpkgs/issues/101616#issuecomment-915872352

The gnome-keyring PAM module gets enabled when the associated gnome-keyring service is by one of the many dependents that enable it. This starts the gnome-keyring-daemon which by default has the internal SSH component enabled. That component sets the SSH_AUTH_SOCK environment variable by both pushing it over DBUS to gnome-session[1] and via g_setenv.

I have submitted a PR to gnome-keyring to allow specifying the components that should be started in the daemon from the PAM module[2]. This will allow omitting the SSH component.

I think this could be part of the solution going forward without completely breaking things

[1] org.gnome.SessionManager.Setenv [2] This configuration was just for testing

In respect to fixing this issue I've drafted a PR to disable the SSH component that's enabled in the gnome-keyring PAM module if programs.gnupg.agent.enableSSHSupport is true. See https://github.com/NixOS/nixpkgs/pull/284173. It's yet to be fully tested, and will probably need some level of home-manager integration, but just posting for visibility

[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.