<div dir="ltr"><div dir="ltr"><div>Ok, can we talk about how much of a pain it is to forward the extra socket as a result of putting it in /run?</div><div><br></div><div>Like... "Note: On Systems where systemd controls the directories under /var/run/user/<uid> it may be that the socket forwarding fails because /var/run/user/<uid>/gnupg is deleted on logout. To workaround this you can put gpgconf --create-socketdir in the startup script of your shell e.g. ~/.bashrc or ~/.zshrc." (<a href="https://wiki.gnupg.org/AgentForwarding" target="_blank">https://wiki.gnupg.org/AgentForwarding</a>)</div><div>Ok, this is just plain WRONG:</div><div>- Nothing relevant to systemd here. Nor is /var/ relevant. I don't even use systemd. But, /run is *meant* to be cleared of files regularly, systemd or not. (In fact, mine is a tmpfs.)</div><div>- The shell startup files are not run until AFTER the forwarding is attempted (and FAILS). So you have to connect twice for this to actually work.</div><div><br></div><div>As far as I can tell, an actual solution is creating user-tmpfiles.d/gnupg.conf with:</div><div>d /run/user/%U 0700<br>d /run/user/%U/gnupg 0700</div><div><br></div><div>Along with a separate script:</div><div>su -c 'systemd-tmpfiles --user --create --remove' $PAM_USER</div><div><br></div><div>AND a PAM config to run that script (early enough that it happens before SSH tries to create the socket):</div><div>-session        optional    pam_exec.so quiet_log /usr/local/sbin/run-systemd-tmpfiles</div><div><br></div><div>(Of course, this still has the problem that it's reliant on a UID that often changes between systems rather than a username which is, for most people, identical across systems, but oh well)</div><div><br></div><div>Great fun! Good luck!</div></div>
</div>