sshfs and autofs

sshfs and autofs

[Marc Weber]

If you google for sshfs and autofs you'll find many howtos telling you
to create a private key without passwords because this works.
Most of of those Howtos tell you as well that you should not be doing
this for security reasons..

I've found another solution:
It tries connecting to each running ssh-agent. The first being able to
connect to the ssh location will be used. This way you can keep using
passwords and still use autofs.

  #!/bin/sh -e
  # PATH must contains openssh, sed, sshfs lsof and pgrep
  pids=`pgrep ssh-agent`
  if [ -z "$pids" ]; then
    # no ssh-agent found. Maybe there is a key without password ? You should not be using this!
    sshfs -o ssh_command="ssh -o NumberOfPasswordPrompts=0" "$@"
  else
  for p in $pids; do
    export SSH_AGENT_PID=$p
    export SSH_AUTH_SOCK=$(lsof -p $p -a -U  -Fn | sed -n 's/^n//p')
    echo "trying to connect using ssh-agent $p $SSH_AUTH_SOCK" 1>&2
      sshfs -o ssh_command="ssh -o NumberOfPasswordPrompts=0" "$@" && exit 0 || true
  done
  exit 1
  fi

Of course it is just a dirty script. However it does a much better job
than using no password.

Do you host such examples somewhere as well?

Marc Weber

Re: sshfs and autofs

[Marc Weber]

The script I posted last let's still other users access your mounts
which is bad.
This script only queries the ssh-agents run by the uid specified in
mount options (uid=..)
It also uses sudo -u#uid to run ssfs causing a user mount.
So other causes can still cause the mount. But they can't access the
filesystem contents:

# ls -l /auto/mlin;
ls: cannot open directory /auto/mlin: Permission denied

#  ls -l /auto
ls: cannot access /auto/mlin: Permission denied
total 0
d????????? ? ? ? ?                ? mlin

Whatever those question marks mean?


Updated script

    # setuid-wrappers for fusermount
    export PATH=/var/setuid-wrappers:${pkgs.coreutils}/bin:${pkgs.sshfsFuse}/bin:${pkgs.openssh}/bin:${pkgs.procps}/bin:${pkgs.lsof}/bin:${pkgs.gnused}/bin/:${pkgs.sudo}/bin
    pids=`pgrep ssh-agent`
    # get uid=nr from arguments
    uid=$(echo "$@"| sed -n 's@.*uid=\([0123456789]\+\).*@\1@p')
    connect(){
      sudo=$1; shift
      $sudo sshfs -o ssh_command="ssh -o NumberOfPasswordPrompts=0" "$@" \
       && exit 0 || true
    }
    # Change ownership of mountpoint. Ownership will be overridden when mount suceeds.
    # Otherwise fusermount can't access it (?!)
    chown $uid "$2"
    chmod u+w "$2"
    for p in $pids; do
      res="$(lsof -p $p -a -U  -Fnu)"
      user_id=$(echo "$res"| sed -n 's/^u//p')
      if [ "$user_id" == "$uid" ]; then
        export SSH_AUTH_SOCK=$(echo "$res"| sed -n 's/^n//p')
        export SSH_AGENT_PID=$p
        echo "trying to connect using ssh-agent $p $SSH_AUTH_SOCK" 1>&2
        # by using sudo -u allow accessing mount by target user - Is there a better way to achieve this??
        connect "sudo -E -u#$user_id" "$@"
        echo -n " .. failed" 1>&2
      fi
    done
    unset SSH_AGENT_PID; unset SSH_AUTH_SOCK

    # no ssh-agent found or they all belong to different users..
    # Try again. Maybe there is a key without password ?
    # You should not be using this!
    connect "" "$@"
    exit 1


Can I make automount create those key directories with user permissions
as well so that other users can't even cause a mount?

Is there a better way to restrict acess to a user only compared to using
sudo?

Marc Weber

Re: sshfs and autofs

[Stef Bon]

Marc Weber wrote:
> The script I posted last let's still other users access your mounts
> which is bad.
> This script only queries the ssh-agents run by the uid specified in
> mount options (uid=..)
> It also uses sudo -u#uid to run ssfs causing a user mount.
> So other causes can still cause the mount. But they can't access the
> filesystem contents:
>
> # ls -l /auto/mlin;
> ls: cannot open directory /auto/mlin: Permission denied
>
> #  ls -l /auto
> ls: cannot access /auto/mlin: Permission denied
> total 0
> d????????? ? ? ? ?                ? mlin
>   
Well the question marks mean that glibc cannot figure out the 
permissions. This means probably
that the mount has not been succesfull.

> Whatever those question marks mean?
>
>
> Updated script
>
>     # setuid-wrappers for fusermount
>     export PATH=/var/setuid-wrappers:${pkgs.coreutils}/bin:${pkgs.sshfsFuse}/bin:${pkgs.openssh}/bin:${pkgs.procps}/bin:${pkgs.lsof}/bin:${pkgs.gnused}/bin/:${pkgs.sudo}/bin
>     pids=`pgrep ssh-agent`
>     # get uid=nr from arguments
>     uid=$(echo "$@"| sed -n 's@.*uid=\([0123456789]\+\).*@\1@p')
>     connect(){
>       sudo=$1; shift
>       $sudo sshfs -o ssh_command="ssh -o NumberOfPasswordPrompts=0" "$@" \
>        && exit 0 || true
>     }
>     # Change ownership of mountpoint. Ownership will be overridden when mount suceeds.
>     # Otherwise fusermount can't access it (?!)
>     chown $uid "$2"
>     chmod u+w "$2"
>     for p in $pids; do
>       res="$(lsof -p $p -a -U  -Fnu)"
>       user_id=$(echo "$res"| sed -n 's/^u//p')
>       if [ "$user_id" == "$uid" ]; then
>         export SSH_AUTH_SOCK=$(echo "$res"| sed -n 's/^n//p')
>         export SSH_AGENT_PID=$p
>         echo "trying to connect using ssh-agent $p $SSH_AUTH_SOCK" 1>&2
>         # by using sudo -u allow accessing mount by target user - Is there a better way to achieve this??
>         connect "sudo -E -u#$user_id" "$@"
>         echo -n " .. failed" 1>&2
>       fi
>     done
>     unset SSH_AGENT_PID; unset SSH_AUTH_SOCK
>
>     # no ssh-agent found or they all belong to different users..
>     # Try again. Maybe there is a key without password ?
>     # You should not be using this!
>     connect "" "$@"
>     exit 1
>
>   
Does this work. I do not know anything about ssh agents.

I n my construction I'm using the following command:

sshfs "$unc_address" "$mountpoint" -o allow_other -o 
PasswordAuthentication='no' -o IdentityFile="$homedir/.ssh/id_dsa" -o 
UserKnownHostsFile="$homedir/.ssh/known_hosts" -o Compression='yes'

where unc_address is of the form %USER%@192.168.0.1:

where user is like sbon (me) or root.
$homedir is the homedirectory of this user, and there has been a check 
the files like $homedir/.ssh/id_dsa are present.


This works. There is no construction to prevent other users to activate 
the mount.

I've created earlier a constrcution to mount ssh, and this was working 
with a mount.sshfs wrapper, which on his turn
called sshfs through above commands. This was working.

Now I'm working on a new construction which creates an seperate 
mountpoint for every user:

/mnt/mount.md5key/%USER%/mount

wher USER is again the user like sbon.

the directory /mnt/mount.md5key/%USER%
is owned by the user and has permissions 700, so no other user except 
root can access (and also activate) any mount.

Hope this helps.

Stef Bon



> Can I make automount create those key directories with user permissions
> as well so that other users can't even cause a mount?
>
> Is there a better way to restrict acess to a user only compared to using
> sudo?
>
> Marc Weber
>
> _______________________________________________
> autofs mailing list
> autofs@linux.kernel.org
> http://linux.kernel.org/mailman/listinfo/autofs
>
>   

Re: sshfs and autofs

[Marc Weber]

> > #  ls -l /auto
> > ls: cannot access /auto/mlin: Permission denied
> > total 0
> > d????????? ? ? ? ?                ? mlin
> >   
> Well the question marks mean that glibc cannot figure out the 
> permissions. This means probably
> that the mount has not been succesfull.
It was. The user can access it. But root can't.

> Does this work. I do not know anything about ssh agents.
Than you should start to learn at least some basics.
An ssh-agent is a process which keeps your "passwords" in memory to
unlock the .ssh/id_* keys.
Of course it works. I'm using it.
 
> I n my construction I'm using the following command:
> PasswordAuthentication='no' -o IdentityFile="$homedir/.ssh/id_dsa" -o 
This id_dsa, is it protected by password?
If you use google to find out how to use automount and sshfs you'll find
many instructions about how to generate a key with empty password and
how to configure automount. However using an empty password is not an
option for me.

> the directory /mnt/mount.md5key/%USER%
> is owned by the user and has permissions 700, so no other user except 
How do you assign these permissions 700 ?
I didn't suceed

Marc Weber

Re: sshfs and autofs

[Stef Bon]

Marc Weber wrote:
>>> #  ls -l /auto
>>> ls: cannot access /auto/mlin: Permission denied
>>> total 0
>>> d????????? ? ? ? ?                ? mlin
>>>   
>>>       
>> Well the question marks mean that glibc cannot figure out the 
>> permissions. This means probably
>> that the mount has not been succesfull.
>>     
> It was. The user can access it. But root can't.
>
>   
>> Does this work. I do not know anything about ssh agents.
>>     
> Than you should start to learn at least some basics.
> An ssh-agent is a process which keeps your "passwords" in memory to
> unlock the .ssh/id_* keys.
> Of course it works. I'm using it.
>   
Wow, I'm just making clear that I do not know anything these agents. I'm 
just asking you about it,
but not doubting your abilities.
>  
>   
>> I n my construction I'm using the following command:
>> PasswordAuthentication='no' -o IdentityFile="$homedir/.ssh/id_dsa" -o 
>>     
> This id_dsa, is it protected by password?
> If you use google to find out how to use automount and sshfs you'll find
> many instructions about how to generate a key with empty password and
> how to configure automount. However using an empty password is not an
> option for me.
>   
Here again I'm trying to help here. I'm just trying to figure out (see 
above) how your setup works,
and I try to be of some help here. But it looks if you already know 
everything, and it looks as you
don't want to be helped. Be a little bit more specific and understand 
that somebody else does not
understand your setup immediatly,

Stef Bon
>   
>> the directory /mnt/mount.md5key/%USER%
>> is owned by the user and has permissions 700, so no other user except 
>>     
> How do you assign these permissions 700 ?
> I didn't suceed
>
> Marc Weber
>
>   

Re: sshfs and autofs

[Marc Weber]

Excerpts from Stef Bon's message of Tue Dec 22 20:08:24 +0100 2009:
> Marc Weber wrote:
> >>> #  ls -l /auto
> >>> ls: cannot access /auto/mlin: Permission denied
> >>> total 0
> >>> d????????? ? ? ? ?                ? mlin
> >>>   
> >>>       
> >> Well the question marks mean that glibc cannot figure out the 
> >> permissions. This means probably
> >> that the mount has not been succesfull.
> >>     
> > It was. The user can access it. But root can't.
> >
> >   
> >> Does this work. I do not know anything about ssh agents.
> >>     
> > Than you should start to learn at least some basics.
Sorry. I should have been more specific.
I tried saying: If you have to login to multiple locations very often
you should learn about ssh-agents because you'll benefit doing so.

That's one point. The second point is if you still don't know about them
and you're not going to read up what they are and why they are exist
there is indeed no point you helping me because the reason I wrote that
script was using ssh-agents.

Anyway I think we can meet. You didn't reply to my question whether
you're using empty passwords. So it looks to me that you're not aware
about what I'm talking when saying "empty password". This looks strange
to me because using automount directories per users seems to be
advanced to me.

Let me show you a complete example how to generate a key and use an
ssh-agent:

  # important: enter a passphrase

  ssh-keygen -t rsa -f $HOME/id_rsa_tmp
  Enter passphrase (empty for no passphrase): PASSWORD
  Your identification has been saved in $HOME/id_rsa_tmp.
  Your public key has been saved in $HOME/id_rsa_tmp.pub.
    
  # now you can copy your key to remote machine, you have to enter your
  # remote password once:
  ssh-copy-id -i $HOME/id_rsa_tmp.pub user@remote

  Now you can login using
  ssh -i $HOME/id_rsa_tmp user@remote

  If you didn't use an empty password ssh will ask you for the id_rsa_tmp
  password each time uses the key.
  If you login and out frequently this is tedious. That's why you can do

  tmp=$(ssh-agent)
  echo "$tmp"
  eval "$tmp"
  ssh-add $HOME/id_rsa_tmp # thell the agent enter passphrase
  # no more passwords required:
  ssh user@remote 'echo done'
  ssh user@remote 'echo done'
  # kill agent so that when you leave the pc nobody
  # else can use your key. You can also specify timeouts and such.
  # (-> man ssh-agent)
  pkill -9 ssh-agent 

Of course if you're using an empty passphrase you don't need the
ssh-agent at all.
However if someone get's access to your private key he can login.
If you use a passphrase he can't because he still has to know your
passphrase.

Now you've been using this line without ssh-agent:
> >> PasswordAuthentication='no' -o IdentityFile="$homedir/.ssh/id_dsa" -o 

What would happen if you replaced .ssh/id_dsa with $HOME/id_rsa_tmp
assuming you entered a passphrase?
automount is running mount running sshfs running ssh
which will find your password protected key. It doesn't know about any
agents so it will try to ask you for the password by printing a
"password:" prompt. But automount has no shell thus no prompt thus the
mount will fail.

For this reason you find many howtos when googling telling you how to
setup keys with empty passwords because this just works.

I have two goals:
a) figuring out whether there are even nicer solutions
b) telling people that they can use password protected private keys and
automount using my script.

> Here again I'm trying to help here.
Thanks for doing so.

I hope that this mail showing you how to use ssh-agents does help you a
little bit understanding my configuration.

Marc Weber

Re: sshfs and autofs

[Stef Bon]

Marc Weber wrote:
> Excerpts from Stef Bon's message of Tue Dec 22 20:08:24 +0100 2009:
>   
>> Marc Weber wrote:
>>     
>>>>> #  ls -l /auto
>>>>> ls: cannot access /auto/mlin: Permission denied
>>>>> total 0
>>>>> d????????? ? ? ? ?                ? mlin
>>>>>   
>>>>>       
>>>>>           
>>>> Well the question marks mean that glibc cannot figure out the 
>>>> permissions. This means probably
>>>> that the mount has not been succesfull.
>>>>     
>>>>         
>>> It was. The user can access it. But root can't.
>>>
>>>   
>>>       
>>>> Does this work. I do not know anything about ssh agents.
>>>>     
>>>>         
>>> Than you should start to learn at least some basics.
>>>       
> Sorry. I should have been more specific.
> I tried saying: If you have to login to multiple locations very often
> you should learn about ssh-agents because you'll benefit doing so.
>
> That's one point. The second point is if you still don't know about them
> and you're not going to read up what they are and why they are exist
> there is indeed no point you helping me because the reason I wrote that
> script was using ssh-agents.
>
> Anyway I think we can meet. You didn't reply to my question whether
> you're using empty passwords. So it looks to me that you're not aware
> about what I'm talking when saying "empty password". This looks strange
> to me because using automount directories per users seems to be
> advanced to me.
>
> Let me show you a complete example how to generate a key and use an
> ssh-agent:
>
>   # important: enter a passphrase
>
>   ssh-keygen -t rsa -f $HOME/id_rsa_tmp
>   Enter passphrase (empty for no passphrase): PASSWORD
>   Your identification has been saved in $HOME/id_rsa_tmp.
>   Your public key has been saved in $HOME/id_rsa_tmp.pub.
>     
>   # now you can copy your key to remote machine, you have to enter your
>   # remote password once:
>   ssh-copy-id -i $HOME/id_rsa_tmp.pub user@remote
>
>   Now you can login using
>   ssh -i $HOME/id_rsa_tmp user@remote
>
>   If you didn't use an empty password ssh will ask you for the id_rsa_tmp
>   password each time uses the key.
>   If you login and out frequently this is tedious. That's why you can do
>
>   tmp=$(ssh-agent)
>   echo "$tmp"
>   eval "$tmp"
>   ssh-add $HOME/id_rsa_tmp # thell the agent enter passphrase
>   # no more passwords required:
>   ssh user@remote 'echo done'
>   ssh user@remote 'echo done'
>   # kill agent so that when you leave the pc nobody
>   # else can use your key. You can also specify timeouts and such.
>   # (-> man ssh-agent)
>   pkill -9 ssh-agent 
>
> Of course if you're using an empty passphrase you don't need the
> ssh-agent at all.
> However if someone get's access to your private key he can login.
> If you use a passphrase he can't because he still has to know your
> passphrase.
>
> Now you've been using this line without ssh-agent:
>   
>>>> PasswordAuthentication='no' -o IdentityFile="$homedir/.ssh/id_dsa" -o 
>>>>         
>
> What would happen if you replaced .ssh/id_dsa with $HOME/id_rsa_tmp
> assuming you entered a passphrase?
> automount is running mount running sshfs running ssh
> which will find your password protected key. It doesn't know about any
> agents so it will try to ask you for the password by printing a
> "password:" prompt. But automount has no shell thus no prompt thus the
> mount will fail.
>   

Ok thanks for the explenation. This makes much more clear what the 
problem is. Let me explain my construction.
When a session begins, an autofs managed mountpoint is added to a 
seperate auto.master file, located in /var/run/autofs.
If a seperate automounter is not already running, it is started, with 
this auto.master file as paramter.
After login of root for example(on the login or via ssh - this is not 
really important how) this file looks like:

/mnt/mount.md5key/root/mount   /etc/autofs/auto.md5key   AUTOFS_USER=root

(this whole adding thing when a session  starts is done with help of 
ConsoleKit... in future I'll try Upstart)

Of course the directory /mnt/mount.md5key/root/mount is created first, 
and the directory /mnt/mount.md5key/root
has permissions 700  and is owned by the user for which this mountpoint 
is, in this case root.
But in any case no other user (except root, but in this case this is the 
same user) can enter the mountpoint and/or activate
it.

The file /etc/autofs/auto.md5key is the most simple map file:

*   -fstype=md5key   :/&

And this is a great feature of the automounter, the filesystem md5key 
does not have to be a "real" filesystem.
It just passes the filesystem type (md5key) to the mount command, which 
on his turn looks for the mount.md5key command,
which I've created, and is actually a wrapper to run the right mount 
command (mount.cifs, curlftpfs, sshs, .....or even mounting of USB).

Basicin this constrcution are "connection" records, where the 
information is stored about the remote or local address.
For samba shares, such a record is like:

cd /var/cache/mount.md5key/1bf8a01af6d3eb08ffa08b9b6578f514
/var/cache/mount.md5key/1bf8a01af6d3eb08ffa08b9b6578f514 ]# cat config
NET_service=smb
LOCAL_user=root
SMB_workgroup=BONONLINE
SMB_name=LFS20060812
SMB_share=public
SMB_ip=192.168.0.2
SMB_auth_method=guest

The md5key is the md5sum of this config file.

A config file for a SSH address may look like (I'm not using it at this 
moment so I may forget something):

NET_service=ssh
LOCAL_user=root
SSH_server=192.168.0.2
SSH_auth_method=agent

Now the md5sum of this file is 2b2468c31ab6a00a3f47d5df01d7a116, create 
this directory:

install -d /var/cache/mount.md5key/2b2468c31ab6a00a3f47d5df01d7a116

and move this record in it:

mv <from somehere>/config  
/var/cache/mount.md5key/2b2468c31ab6a00a3f47d5df01d7a116

Now to access this resource, direct access is not very userfriendly, the 
md5keys only make sense to the computer, not the user.
I've created a script which scans the cache (in 
/var/cache/mount.md5key/) for available resources for a user, and 
creates a tree in the
homedirectory, which makes sense to the user, with symboliclinks to the 
right md5key entries:

For me still as root this looks like:

~/Network/Windows Network/BONONLINE/LFS20060812/public -> 
/mnt/mount.md5key/root/mount/1bf8a01af6d3eb08ffa08b9b6578f514

and

~/Network/SSH access/192.168.0.2 -> 
/mnt/mount.md5key/root/mount/2b2468c31ab6a00a3f47d5df01d7a116

When entering these directories, (read following the link) the 
mount.md5key command looks for the key in /var/cache/mount.md5key/ 
directory,
finds it, looks for the config file and launches the right mount command 
with the right parameters.

You see the whole intelligent thing is done by the mount.md5key command, 
getting al the right information out off the config file.

Now there are more I can tell you about this. The information about 
remote and local resources is not static. With Samba shares there are some
utilities which cann help you to find out the resources a user logged in 
has access to, like nbtscan, nmblookup and smbclient.
For other resources there might be other utilities.
Futher I do not like these symbolic links. When following them, you as 
user might end up with your
favorite app in /mnt/mount.md5key/%USER%/mount directory, looking to 
strange looking directories on a strange place in the filesystem. Thats 
the reason
I'm working on an fuse modules (fuse-workspace I've called it) which 
mirrors this connections tree, where it's possible to make some symbolic 
links look like directories. It's too complicated, but look at

http://linux.bononline.nl/linux/fuse-workspace/index.php

and

http://linux.bononline.nl/linux/mount.md5key/index.php
http://linux.bononline.nl/linux/runsessionscripts/index.php


Now to get back to your problem, as I understand it, I've read some 
manpages, and yes I'm using private/public keys without
passphrase. I did not know about agents until now. I understand that 
this communication through this agent makes it easier to make a ssh 
connection.
If I'm wrong please correct.
Next add the .ssh/id_dsa and .ssh/id_rsa and .ssh/identity files with 
ssh-add. If this is done, other applications do not have to enter the 
passphrase
anymore, if they make use of this agent, which they can find though the 
environment variables.

But the ssh-add command asks for the passphrase, and if done in an 
environment with the automounter you have a problem here, I understand.
In my setup the mount.md5key command has to find out who is activating 
the mount, and what the evironment is (simple terminal or X) and present
a "passphrase" dialog. Apart problem: how to store the information about 
the agent for other apps.

This is the whole problem, because this is not easy. The automounter 
(read man 5 autofs) can offer variables like USER, UID, etc,HOST
of the user requesting the mount (according to the manpage). Then to 
present this user a suitable dialog... maybe via dbus???

I do not have a sollution for you here, sorry, I can ony analyze it's 
difficult.
I think that your script tries to offer a dialog somehere, but that it 
does not reach you as user...
Earlier I've thought about this when entering a Windows/Samba share, but 
I left it for exact these reasons.


Somebody else??


Stef Bon










> For this reason you find many howtos when googling telling you how to
> setup keys with empty passwords because this just works.
>
> I have two goals:
> a) figuring out whether there are even nicer solutions
> b) telling people that they can use password protected private keys and
> automount using my script.
>
>   
>> Here again I'm trying to help here.
>>     
> Thanks for doing so.
>
> I hope that this mail showing you how to use ssh-agents does help you a
> little bit understanding my configuration.
>
> Marc Weber
>
>   

Re: sshfs and autofs

[Stef Bon]

Stef Bon wrote:
>
>
> This is the whole problem, because this is not easy. The automounter 
> (read man 5 autofs) can offer variables like USER, UID, etc,HOST
> of the user requesting the mount (according to the manpage). Then to 
> present this user a suitable dialog... maybe via dbus???

I'm silly here, the user is not the problem, this is already available, 
in the options, or - in my construction - in the config file, in the 
parameter AUTOFS_USER
and in the mountpath, but the environment this user is using! A pid of 
the process would be very usefull, for example.
But this is not easy. When I'm logged in twice with the same account, 
which session should get the question for the passphrase?

Stef

Re: sshfs and autofs

[Marc Weber]

Excerpts from Stef Bon's message of Wed Dec 23 22:59:48 +0100 2009:
> Stef Bon wrote:
> >
> >
> > This is the whole problem, because this is not easy. The automounter 
> > (read man 5 autofs) can offer variables like USER, UID, etc,HOST
> > of the user requesting the mount (according to the manpage). Then to 
> > present this user a suitable dialog... maybe via dbus???
> 
> I'm silly here, the user is not the problem, this is already available, 
> in the options, or - in my construction - in the config file, in the 
> parameter AUTOFS_USER
> and in the mountpath, but the environment this user is using! A pid of 
> the process would be very usefull, for example.
> But this is not easy. When I'm logged in twice with the same account, 
> which session should get the question for the passphrase?

About which session are you talking now? A ssh-agent session determined
by SSH_AGENT_PID and SSH_AUTH_SOCKET ?

Add this to your .bashrc or .zshrc:

reuseSSHAgent () {
        local f=~/.current-ssh-agent
        . $f || true
        ps -p "$SSH_AGENT_PID" &> /dev/null || {
                ssh-agent | grep -v echo > $f
                . $f
                ssh-add
        }
}
reuseSSHAgent

If there is a ssh agent running it will be used if not it will be
started. Then ssh-add will be run (I use only one key so this is
comfortable to me ..)

Maybe I should check that the socket file exists then I would'nt have to
run ps.

Gentoo has a nice script called "keychain" which provides this and more
for ssh-agent and the gnu-gpg agent. However I felt it was too bloated
and replaced it by this function.

You really don't want to type your password twice, do you ? :)

Marc Weber

Re: sshfs and autofs

[Stef Bon]

Marc Weber wrote:
> Excerpts from Stef Bon's message of Wed Dec 23 22:59:48 +0100 2009:
>   
>> Stef Bon wrote:
>>     
>>> This is the whole problem, because this is not easy. The automounter 
>>> (read man 5 autofs) can offer variables like USER, UID, etc,HOST
>>> of the user requesting the mount (according to the manpage). Then to 
>>> present this user a suitable dialog... maybe via dbus???
>>>       
>> I'm silly here, the user is not the problem, this is already available, 
>> in the options, or - in my construction - in the config file, in the 
>> parameter AUTOFS_USER
>> and in the mountpath, but the environment this user is using! A pid of 
>> the process would be very usefull, for example.
>> But this is not easy. When I'm logged in twice with the same account, 
>> which session should get the question for the passphrase?
>>     
>
> About which session are you talking now? A ssh-agent session determined
> by SSH_AGENT_PID and SSH_AUTH_SOCKET ?
>
> Add this to your .bashrc or .zshrc:
>
> reuseSSHAgent () {
>         local f=~/.current-ssh-agent
>         . $f || true
>         ps -p "$SSH_AGENT_PID" &> /dev/null || {
>                 ssh-agent | grep -v echo > $f
>                 . $f
>                 ssh-add
>         }
> }
> reuseSSHAgent
>
> If there is a ssh agent running it will be used if not it will be
> started. Then ssh-add will be run (I use only one key so this is
> comfortable to me ..)
>
> Maybe I should check that the socket file exists then I would'nt have to
> run ps.
>
> Gentoo has a nice script called "keychain" which provides this and more
> for ssh-agent and the gnu-gpg agent. However I felt it was too bloated
> and replaced it by this function.
>
> You really don't want to type your password twice, do you ? :)
>   
No, but sometimes inevitable.

I'm talking about the usersession. When logged in twice, and I'm 
activating the mount at the second session (or login)
how does the automounter and the mount script know which usersession to 
present a dialog.

This is no issue when you first enter the passphrase manually in the 
first session, make use of it and reuse it on the second.

Stef

Re: sshfs and autofs

[Marc Weber]

Excerpts from Stef Bon's message of Wed Dec 23 23:31:15 +0100 2009:
> Marc Weber wrote:
> > Excerpts from Stef Bon's message of Wed Dec 23 22:59:48 +0100 2009:
> >   
> >> Stef Bon wrote:
> >>     
> >>> This is the whole problem, because this is not easy. The automounter 
> >>> (read man 5 autofs) can offer variables like USER, UID, etc,HOST
> >>> of the user requesting the mount (according to the manpage). Then to 
> >>> present this user a suitable dialog... maybe via dbus???
> >>>       
> >> I'm silly here, the user is not the problem, this is already available, 
> >> in the options, or - in my construction - in the config file, in the 
> >> parameter AUTOFS_USER
> >> and in the mountpath, but the environment this user is using! A pid of 
> >> the process would be very usefull, for example.
> >> But this is not easy. When I'm logged in twice with the same account, 
> >> which session should get the question for the passphrase?
> >>     
> >
> > About which session are you talking now? A ssh-agent session determined
> > by SSH_AGENT_PID and SSH_AUTH_SOCKET ?
> >
> > Add this to your .bashrc or .zshrc:
> >
> > reuseSSHAgent () {
> >         local f=~/.current-ssh-agent
> >         . $f || true
> >         ps -p "$SSH_AGENT_PID" &> /dev/null || {
> >                 ssh-agent | grep -v echo > $f
> >                 . $f
> >                 ssh-add
> >         }
> > }
> > reuseSSHAgent
> >
> > If there is a ssh agent running it will be used if not it will be
> > started. Then ssh-add will be run (I use only one key so this is
> > comfortable to me ..)
> >
> > Maybe I should check that the socket file exists then I would'nt have to
> > run ps.
> >
> > Gentoo has a nice script called "keychain" which provides this and more
> > for ssh-agent and the gnu-gpg agent. However I felt it was too bloated
> > and replaced it by this function.
> >
> > You really don't want to type your password twice, do you ? :)
> >   
> No, but sometimes inevitable.
> 
> I'm talking about the usersession. When logged in twice, and I'm 
> activating the mount at the second session (or login)
> how does the automounter and the mount script know which usersession to 
> present a dialog.
> 
> This is no issue when you first enter the passphrase manually in the 
> first session, make use of it and reuse it on the second.
> 
> Stef

How does wall work ?
Maybe it should be asked on all terminals.
This would work.
But that's the reason why I didn't even try to find a solution.

If automount knew about the process id there might be a chance figuring
out about the tty being used..

But it's not a problem for me so I won't fix it unless you have an idea
which can be implemented fast.

Marc Weber

Re: sshfs and autofs

[Stef Bon]

Marc Weber wrote:
> Excerpts from Stef Bon's message of Wed Dec 23 23:31:15 +0100 2009:
>   
>> Marc Weber wrote:
>>     
>>> Excerpts from Stef Bon's message of Wed Dec 23 22:59:48 +0100 2009:
>>>   
>>>       
>>>> Stef Bon wrote:
>>>>     
>>>>         
>>>>> This is the whole problem, because this is not easy. The automounter 
>>>>> (read man 5 autofs) can offer variables like USER, UID, etc,HOST
>>>>> of the user requesting the mount (according to the manpage). Then to 
>>>>> present this user a suitable dialog... maybe via dbus???
>>>>>       
>>>>>           
>>>> I'm silly here, the user is not the problem, this is already available, 
>>>> in the options, or - in my construction - in the config file, in the 
>>>> parameter AUTOFS_USER
>>>> and in the mountpath, but the environment this user is using! A pid of 
>>>> the process would be very usefull, for example.
>>>> But this is not easy. When I'm logged in twice with the same account, 
>>>> which session should get the question for the passphrase?
>>>>     
>>>>         
>>> About which session are you talking now? A ssh-agent session determined
>>> by SSH_AGENT_PID and SSH_AUTH_SOCKET ?
>>>
>>> Add this to your .bashrc or .zshrc:
>>>
>>> reuseSSHAgent () {
>>>         local f=~/.current-ssh-agent
>>>         . $f || true
>>>         ps -p "$SSH_AGENT_PID" &> /dev/null || {
>>>                 ssh-agent | grep -v echo > $f
>>>                 . $f
>>>                 ssh-add
>>>         }
>>> }
>>> reuseSSHAgent
>>>
>>> If there is a ssh agent running it will be used if not it will be
>>> started. Then ssh-add will be run (I use only one key so this is
>>> comfortable to me ..)
>>>
>>> Maybe I should check that the socket file exists then I would'nt have to
>>> run ps.
>>>
>>> Gentoo has a nice script called "keychain" which provides this and more
>>> for ssh-agent and the gnu-gpg agent. However I felt it was too bloated
>>> and replaced it by this function.
>>>
>>> You really don't want to type your password twice, do you ? :)
>>>   
>>>       
>> No, but sometimes inevitable.
>>
>> I'm talking about the usersession. When logged in twice, and I'm 
>> activating the mount at the second session (or login)
>> how does the automounter and the mount script know which usersession to 
>> present a dialog.
>>
>> This is no issue when you first enter the passphrase manually in the 
>> first session, make use of it and reuse it on the second.
>>
>> Stef
>>     
>
> How does wall work ?
> Maybe it should be asked on all terminals.
> This would work.
> But that's the reason why I didn't even try to find a solution.
>
> If automount knew about the process id there might be a chance figuring
> out about the tty being used..
>
> But it's not a problem for me so I won't fix it unless you have an idea
> which can be implemented fast.
>
> Marc Weber
>
>   

Well maybe PAM can help you here.

If you login with a password through pam, there are pammodules which can 
do something with
the authentication. Long time ago I've setup a pam constrcution which 
stores the username and the
password in a file. The module I used was pam_script.so, which is 
developed not by the PAM team,
but since some time there is pam_exec.so, which does the same.

My login file in /etc/pam.d looks like:


#%PAM-1.0
auth            required        pam_shells.so
#auth           required        pam_env.so readenv=0
auth            required        pam_script.so 
onauth=/etc/security/onauth.ldap expose=authtok       (A)
auth            sufficient      pam_ldap.so use_first_pass
auth            required        pam_script.so expose=authtok   (B)
auth            required        pam_unix.so audit md5 shadow try_first_pass

account         required        pam_nologin.so
account         sufficient      pam_unix.so
account         optional        pam_ldap.so

password        sufficient      pam_unix.so try_first_pass use_authtok 
md5 shadow
password        required        pam_ldap.so

session         required        pam_script.so runas=root   (C)
session         optional        pam_limits.so
session         required        pam_ck_connector.so
session         optional        pam_mail.so dir=/var/mail standard
session         required        pam_unix.so shadow md5
session         required        pam_ldap.so


Let me explain what happens here:

at (A) the modules pam_script asks for a password, and exposes to the 
script onauth.ldap. This script is in the /etc/security directory. Of 
this option
is not supplied the default script onauth is run.

The onauth.ldap script is a symlink to onauth. It stores the password, 
in the environment var PAM_AUTHTOK in a file on a temporary drive,
created at boottime, on my system at /var/run/safe:

tmpfs   on     /var/run/safe type tmpfs (rw,size=500k)

It's of course protected that only root can access these passwords, and 
the user self.
Earlier I've also used encryption here, but a temporary drive which does 
not exist when the system is down is sufficient.


Now the onauth.ldap script stores the password the 
/var/run/safe/sbon/ldap dir, in the password.tmp file, and it creates a 
symlink to it like:

/var/run/safe/sbon/latest -> /var/run/safe/sbon/ldap

assuming sbon (me) is trying to login.

I wanted to make it obvious which authentification service has been 
successfull.
Next is the pam_ldap.so module.
Now if succesfull, all futher modules in the auth fase are skipped, and 
it jumps to the session fase, to open a session.

If not successfull, it will go to (B), which runs the onauth script. 
This will create the /var/run/safe/sbon/local directory, also
containing a password.tmp file with the provided password, and removes 
the /var/run/safe/sbon/latest dir, with all the contents,
and recreates the symlink:

/var/run/safe/sbon/latest -> /var/run/safe/sbon/local

If this is still not successfull, nothing happens futher here, login is 
denied. (maybe there should also be a pam_script here: cleaning up)

If successfull it jumps to the session fase.

There is also a pam_script in the session fase, running the 
/etc/security/onsessionopen script.
This looks for a password.tmp file in the /var/run/safe/sbon/latest and 
moves it to the password file.
It's obvious that the password stored in this file is the right one.

Next it runs scripts it find in the 
/etc/session.d/pam/onsessionopen/*.sh directory.
One thing done on my system is done by a create_smb_credentialfile.sh, 
which creates a mount.smb.cred file, also in
/var/run/safe/sbon/latest dir, which is used by other programs later 
like the mounting of SMB shares through cifs. I'm having
a central account database stored in ldap, which is used for my logins 
(through pam_ldap.so) and for the Samba servers. This
way I can login my samba servers with the same credentials I've provided 
at login.


Now to get back to your ssh problem, it is not so hard to make in stead 
of creating a credentialsfile, running ssh-agent, and ssh-add.
The only issue here is that you have to use the same passphrase for your 
ssh id keys as your password you login with (or a converted unique value 
of that,
like the md5key).
Next is to make ssh-add make use of the passphrase in the password file, 
or an environment var, or from stdin like cat password | ssh-add
or something...
(or something like cat password | md5sum | awk '{ print $1 }'  | ssh-add 
....)


This works but is hell to maintain when your password is changed, and 
you are working on more than one machine. The keys are not mainainted 
centrally
on a server (like kerberos) but on every host you work.

Hope this is what you're looking for.

Stef

Re: sshfs and autofs

[Marc Weber]

Hi Stef,

You don't have to put any further effort into this.
The solution I found is working for me.

The keypoint about ssh passwords is that you don't store them on disk.
So if anyone get's access to your filesystem (or disk) he still can't
use the key.

What you describe is used to keep samba passwords up to date AFAIK.

I'd rather spend time on updating the HOWTO or creating a wiki.
But I don't know how to contact the maintainer. I wrote that in another
mail recently..

Marc Weber

Re: sshfs and autofs

[Marc Weber]

> I think that your script tries to offer a dialog somehere, but that it 
> does not reach you as user...

No, it doesn't  because it would have been too much work thinking about
how to present that.
  DISPLAY=:0.0 some_dialog

does work for X and (my) current use case. But it doesn't work for all
use cases.

So my script the user knows about this issue and will run

ssh-add manually before mounting anything.

Marc Weber

Re: sshfs and autofs

[Stef Bon]

Marc Weber wrote:
>> I think that your script tries to offer a dialog somehere, but that it 
>> does not reach you as user...
>>     
>
> No, it doesn't  because it would have been too much work thinking about
> how to present that.
>   DISPLAY=:0.0 some_dialog
>
> does work for X and (my) current use case. But it doesn't work for all
> use cases.
>
> So my script the user knows about this issue and will run
>
> ssh-add manually before mounting anything.
>
> Marc Weber
>
>   

Well exactly!. I get it, this is a way to make this work.

Do you think this is ok, or don't you want this manually thing??

Stef