Agent forwarding failure when the socketdir was autodeleted

[Stephan Beck]

Oh, just seen Werner's answer :-)

Well, I had a good time reading the mentioned docs ;-)

Cheers,

Stephan

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
> 

-- 
Hinweis: Diese E-Mail enthält vertrauliche Informationen und ist nur für
ihren legitimen Empfänger bestimmt. Ihre Weitergabe oder
Vervielfältigung gleich welcher Art ist nicht gestattet. Sollten Sie
diese E-Mail irrtümlich erhalten haben, löschen Sie sie bitte und
informieren Sie den Absender.