1

I've setup ssh-agent as a systemd service on my Manjaro (following directions from here). Along with the service itself, the SSH_AUTH_SOCK environment variable needs to be set to ${XDG_RUNTIME_DIR}/ssh-agent.socket. The above mentioned directions say to put this in .zshrc or equivalent. This works perfectly fine for most applications, as I primarily use commandline when needing to use ssh-agent.

However, when launching VSCode from dmenu, it does not run .zshrc and thus does not inherit the $SSH_AUTH_SOCK environment variable. Thus to get it to work, I need to set the variable globally. Looking at the arch wiki, the only way to do it (that I can see) is through pam_env. However, this did not work for me; I put

SSH_AUTH_SOCK         DEFAULT=${XDG_RUNTIME_DIR}/ssh-agent.socket

in /etc/environment, but VSCode's process.env still does not have the variable defined. I also tried with

SSH_AUTH_SOCK           DEFAULT=/run/user/1000/ssh-agent.socket 

and it still didn't set.

Note that this is definitely an environment issue as if I launch VSCode from a shell (when .zshrc is run), it does inherit $SSH_AUTH_SOCK. A very similar issue is reported here, but does not actually have a solution.

8
  • Does it work if you hardcode the path instead of using the $XDG_RUNTIME_DIR variable? I doubt that will be set when the pam_env file is read. You can also try setting the variable in /etc/environment. Does that help? (should we assume you're using Arch?)
    – terdon
    Mar 5 '21 at 18:57
  • Yes, I'm using Arch (Manjaro). I can give hard coding the path a shot. Ideally I wouldn't, but ideal isn't always possible I suppose. Mar 5 '21 at 19:39
  • No, of course, but if it works if hard coded, we have a better idea of what a permanent solution would require.
    – terdon
    Mar 5 '21 at 19:50
  • Just tried it with DEFAULT=/run/user/1000/ssh-agent.socket and it still didn't set. Mar 5 '21 at 21:12
  • @fra-san Hmmm. It doesn't work for me for whatever reason. Is there some additional configuration that I'd need to do other than literally just create the files? I see the manpage shows options and flags, but I can't actually run pam_env.so. Mar 6 '21 at 0:42
2

In my system /usr/bin/code is nothing more than a shell script. You can modify it by putting additional export statements or call it from another script exporting required env vars first. For example:

#!/bin/zsh

export SSH_AUTH_SOCK="$XDG_RUNTIME_DIR/ssh-agent.socket"

/usr/bin/code #path to your executable for VSCode

If we discuss X11 in Linux environment - the global environment settings for X11 session can be set in /etc/X11/Xsession or better in file put into directory /etc/X11/Xsession.d.

For the user settings use $HOME/.xsession or alternative $HOME/.Xsession, $HOME/.xsessionrc.

Usage of that files is included in main /etc/X11/Xsession (at least in my Debian system).

4
  • True. That might be the solution I end up going with, but I'd still be curious to know how to get an environment variable to be globally available. Mar 5 '21 at 21:15
  • Please see my proposal in edited answer.
    – nutilius
    Mar 5 '21 at 22:21
  • 1
    ~/.xsession didn't work either. To confirm, the script above does work for me. So I do at least have a work around now. Mar 6 '21 at 0:39
  • 1
    @JamesWright great! If this helps you, please remember to upvote it even if you don't accept this as the solution since it is only a workaround. Upvoting useful answers is essential.
    – terdon
    Mar 6 '21 at 13:41
1

Solution:

In /etc/security/pam_env.conf add:

SSH_AUTH_SOCK  DEFAULT=${XDG_RUNTIME_DIR}/ssh-agent.socket

Other useful tidbits:

Why didn't /etc/environment work originally?:

/etc/environment follows a different format than either ~/.pam_environment or /etc/security/pam_env.conf, as documented here:

/etc/environment:

VARIABLE=value

~/.pam_environment and /etc/security/pam_env.conf:

VARIABLE [DEFAULT=value] [OVERRIDE=value]

So I just had it in the wrong format.

Why use /etc/security/pam_env.conf instead of the other two?:

Because it was the only option that fully works now and will work in the future.

/etc/environment does not read environment variables in, thus ${XDG_RUNTIME_DIR} does not work. You could hardcode the contents of $XDG_RUNTIME_DIR, but the variable (and it's directory) are set by pam_systemd dynamically on a per-user basis. Thus, it's not a great option.

~/.pam_environment will successfully accomplish the same task that /etc/security/pam_env.conf does, but it "is deprecated and will be removed at some point in the future" (commit). So for future-proofing, it shouldn't be used.

And thus that leaves /etc/security/pam_env.conf. It works now with ${XDG_RUNTIME_DIR} and isn't deprecated.

0

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.