3

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.

Improve this question
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?) Commented Mar 5, 2021 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. Commented Mar 5, 2021 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. Commented Mar 5, 2021 at 19:50
  • Just tried it with DEFAULT=/run/user/1000/ssh-agent.socket and it still didn't set. Commented Mar 5, 2021 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. Commented Mar 6, 2021 at 0:42

2 Answers 2

Reset to default
3

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

Improve this answer
0
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).

Improve this answer
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. Commented Mar 5, 2021 at 21:15
  • Please see my proposal in edited answer. Commented Mar 5, 2021 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. Commented Mar 6, 2021 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. Commented Mar 6, 2021 at 13:41

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.