Agent forwarding failure when the socketdir was autodeleted

[Stephan Beck]

Hi,

Daniel Kahn Gillmor:
> Hi Andre--
> 
> On Tue 2016-10-04 14:49:00 -0400, Andre Heinecke wrote:
> 
>> On Tuesday 04 October 2016 11:26:59 Daniel Kahn Gillmor wrote:
>>>> But if I am not logged in or there is no gnupg process running. systemd
>>>> autodeletes /var/run/user/<uid>/gnupg this causes the remote forward of
>>>> the
>>>> Socket to fail because the directory for the socket does not exist and SSH
>>>> won't create it. :-/
>>>
>>> If you're not logged in, then how does the remote forward work?  aren't
>>> you actually still logged in (via ssh) as long as your remote forward is
>>> running?
>>
>> Sorry for not formulating this better. You are of course right If I'm not 
>> logged in the remote forward is not working.
>>
>> That is not what I meant to say. The problem is, that when I disconnect the 
>> /run/.../gnupg dir is deleted and the next time I want to connect and ssh 
>> tries to set up the forwarding this will fail because the /run/.../gnupg 
>> directory in which the forwarded socket should be created does not exist.
> 
> so /run/user/<uid> exists upon ssh connection, but
> /run/user/<uid>/gnupg/  does not, and therefore sshd on the remote side
> of the pipe can't auto-create the remote socket -- is that the concern?
> 
>> My current workaround is to connect first and start dirmngr on the remote 
>> machine (to get the socketdir created and used). And then connect with ssh 
>> socket forwarding. This is a bit clunky to use.
> 
> agreed, that sounds clunky and annoying.
> 
> I wonder whether ssh's remote socket forwarding ought to try to
> automatically create the parent directories if they don't already exist.

So, ssh does not even create the socket if you set
STREAMBINDUNLINK yes
in /etc/ssh/ssh_config (or give the correspondent -o option on the
command line, client-side)?
If this is the case (still no socket/socketdir creation), it may help
adjusting the ~/.profile of the remote account (if permissions allow it)
you log into, adding the following, as seen on (1), provided that you
log in from the console. Quote follows below.

Kyle Amon has provided the following bit for a .bash_profile:

        #
        # setup ssh-agent
        #

# set environment variables if user's agent already exists
[ -z "$SSH_AUTH_SOCK" ] && SSH_AUTH_SOCK=$(ls -l /tmp/ssh-*/agent.* 2>
/dev/null | grep $(whoami) | awk '{print $9}')
[ -z "$SSH_AGENT_PID" -a -z `echo $SSH_AUTH_SOCK | cut -d. -f2` ] &&
SSH_AGENT_PID=$((`echo $SSH_AUTH_SOCK | cut -d. -f2` + 1))
[ -n "$SSH_AUTH_SOCK" ] && export SSH_AUTH_SOCK
[ -n "$SSH_AGENT_PID" ] && export SSH_AGENT_PID

# start agent if necessary
if [ -z $SSH_AGENT_PID ] && [ -z $SSH_TTY ]; then  # if no agent & not
in ssh
    eval `ssh-agent -s` > /dev/null
fi

[Quote end]
If you re-connect to the remote machine and login to the user account
(from the console) an ssh-agent (if not already started) is (hopefully)
being started on the remote machine and creates the directory and socket
in /tmp.
Or, another idea, is to use a specific local script and execute it on
the remote server (or to use COMMAND option from the command line and
execute it on the remote server): Quote from (2)

Executing a Local Script on a Remote Linux Server

$ ssh [user]@[server] 'bash -s' < [local_script]

If all this did not help, and, consequently, systemd (itself) on the
remote machine had to be tricked into preserving (or automatically
recreating) the /gnupg directory, I were a bit lost, but at least I had
read through a bunch of very interesting docs I can make use of myself.

(1) http://mah.everybody.org/docs/ssh
(2)
http://www.shellhacks.com/en/Running-Commands-on-a-Remote-Linux-Server-over-SSH


Cheers,

Stephan

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0x4218732B.asc
Type: application/pgp-keys
Size: 4090 bytes
Desc: not available
URL: </pipermail/attachments/20161005/c67beb52/attachment.key>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: OpenPGP digital signature
URL: </pipermail/attachments/20161005/c67beb52/attachment.sig>