7

I got an .xinitrc file with the following line:

# it will start my window manager
ssh-agent dwm

After that I got an ssh-agent process, but environment variables like $SSH_AGENT_PID and $SSH_AUTH_SOCK does not exists when I start a terminal from dwm. Any ideas why?

I wish there was only one ssh-agent process. Each call to ssh-add should connect to the agent that started dwm.

Kusalananda
  • 333,661
Wojciech
  • 71

2 Answers2

-1

ssh-agent outputs the environment variables you need to have to connect to it, by calling eval you immediately load those variables into your environment.

Why ssh-agent can't do that itself?

In Unix, a process can only modify its own environment variables, and pass them on to children. It can not modify its parent process' environment because the system won't allow it. This is pretty basic security design.

In relation to it read this.

Therefore, leave your `.xinitrc as:

eval $(ssh-agent) &
exec dwm
Fco Javier Balón
  • 1,173
  • 1
    You should check man ssh-agent. The agent can act as a wrapper to other programs and exports the right variables to them, no need for eval in that case. If you don't believe me, make sure you don't have an agent running and then run ssh-agent bash. You'll find that the bash session has a running agent. – cryptarch Jan 13 '23 at 03:21
-1

In your .xinitrc, dwm should be called with exec. The following sets up an agent for dwm for me:

exec ssh-agent dwm

Running startx and then opening a terminal shows the agent loaded.

cryptarch
  • 1,270
  • The only reason to use exec here is that it's unnecessary to have the shell hang around waiting for dwm to exit. There is no requirement to use exec for ssh-agent to do the right thing. This answer points out how one usually writes the .xinitrc file, but it does not explain why the dwm process does not propagate the correct environment variables to e.g. terminals etc. started as child processes from the window manager. – Kusalananda Mar 11 '24 at 09:22
  • @Kusalananda Why would I explain that dwm fails to propagate env, when it's my claim that in fact the env is correctly propagated using my method? If the person asking the question launched dwm in the way it is meant to be launched, they wouldn't have the problem, right? Of course, feel free to post the true answer, if you know a better way. – cryptarch Mar 12 '24 at 00:35
  • Since both ssh-agent util and exec ssh-agent util sets the appropriate ssh-related environment variables for util (the latter, with exec, only replaces the calling shell, there is no other difference), and since ssh-agent util does not seem to work for the user in this question when util is dwm, we must conclude that there is something that removes the environment variables between the execution of the SSH agent and whatever command they use to look at the environment in dwm. No manner of adding exec or not adding exec to the ssh-agent command will change that. – Kusalananda Mar 12 '24 at 07:20
  • In other words: You seem to be saying that exec ssh-agent dwn will work when ssh-agent dwm (without exec) evidently does not work. Such a claim would need to be explained as exec in itself does not change the way that the ssh-related variables are propagated into the environment of dwm. – Kusalananda Mar 12 '24 at 07:25