All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stef Bon <stef@bononline.nl>
To: Marc Weber <marco-oweber@gmx.de>
Cc: autofs <autofs@linux.kernel.org>
Subject: Re: sshfs and autofs
Date: Wed, 23 Dec 2009 22:47:44 +0100	[thread overview]
Message-ID: <4B329000.3060101@bononline.nl> (raw)
In-Reply-To: <1261518309-sup-4721@nixos>

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
>
>   

  reply	other threads:[~2009-12-23 21:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-18  4:08 sshfs and autofs Marc Weber
2009-12-18 22:01 ` Marc Weber
2009-12-20 15:54   ` Stef Bon
2009-12-21 10:32     ` Marc Weber
2009-12-22 19:08       ` Stef Bon
2009-12-22 21:45         ` Marc Weber
2009-12-23 21:47           ` Stef Bon [this message]
2009-12-23 21:59             ` Stef Bon
2009-12-23 22:16               ` Marc Weber
2009-12-23 22:31                 ` Stef Bon
2009-12-23 22:53                   ` Marc Weber
2009-12-24 14:12                     ` Stef Bon
2009-12-24 23:52                       ` Marc Weber
2009-12-23 22:05             ` Marc Weber
2009-12-23 22:19               ` Stef Bon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B329000.3060101@bononline.nl \
    --to=stef@bononline.nl \
    --cc=autofs@linux.kernel.org \
    --cc=marco-oweber@gmx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.