Hello, from time to time I must connect through ssh to mu work desktop and make some synchronization, which requires ssh key-based authentication (so ssh from home to work desktop, followed by ssh from desktop to another server, e.g. svn).
What I was faced is the inability to use ssh-agent when logged through ssh,
since the SSH_AUTH_SOCK is not defined, and thus I must re-type the password
several times, which is really annoying ...
The problem is that ssh-agent must be started in user-session in place where
SSH_AUTH_SOCK env variable is exported to all child processes (in ARCH case it
is /etc/kde/env/ssh-agent-startup.sh script called somewhere during KDE
start). And of course, the ssh daemon is not started as the part of this
startup, so the env variable is not defined ...
So I have made the following hack:
1)
define SSH_AUTH_SOCK DEFAULT=\${HOME}/.ssh/ssh-agent
in /etc/security/pam_env.conf file
2)
modify /etc/kde/startup/agent-startup.sh/ to start ssh-agent like:
if [ -x /usr/bin/ssh-agent ]; then
/usr/bin/ssh-agent -s -a $(eval echo $SSH_AUTH_SOCK)
fi
3)
modify ~/.bashrc to resolve the variable:
export SSH_AUTH_SOCK=$(eval echo $SSH_AUTH_SOCK)
In this way, the ssh-agent is started during KDE startup, listening on the
required socket, and the socket is defined for ssh sessions as well, tanks to
pam_env module.
I think that now it should be rather easy to create the user-specific systemd
service joined with socket-based authentication to stat ssh-agent
automatically on demand, no matter if invoked from ssh session or from desktop
itself (however I did not try it yet ...).
BUT.
Although this solution is working, it is not very easy to configure it. Also,
there is a "danger" that if the ssh-agent startup fail, the SSH_AUTH_SOCK env
will be defined anyway - this is also not very nice ...
And of course, the same (similar) is valid for gpg-agent ...
So I would like to ask, if this situation has been thought about and if here
is an easier and more straightforward solution to achieve it. I think that the
main problem is in passing env variables (or any other kind of setting ??)
through various services of the same user, but not having the same parent
(except init itself). It would be great to hear that you have an idea of
making this work in easy-to-configure and reliable way, while allowing to use
all the cool systemd abilities :-).
Thank you very much,
Dan T.
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
