[SOLVED] Mounting sshfs through wicd

choogi · 2009-10-31 16:48:14

I'm trying to mount a directory through sshfs whenever my laptop connects to a wireless network. I'm using wicd to manage my networks and tried dropping the following script into my /etc/wicd/scripts/postconnect/ directory:

#!/bin/bash

sshfs username@host:remote/dir local/dir
echo 'connect' >> tmpfile

Each time I connect to a network, the echo command succeeds and I can see that the scripts are actually running, but for some reason the directory doesn't mount. On the other hand, if I just execute the script by hand, then the directory connects just fine. I'm also using an ssh-key so I don't need to type my password in each time.

Anybody else run into this problem before?

Last edited by choogi (2012-01-17 00:05:53)

.:B:. · 2009-10-31 21:02:12

I don't see how you would get wicd to mount your sshfs export for you, unless wicd documentation explicitly tells you it supports this? I don't think it does.

You'll need something like keychain (in AUR) to get the script to use your cached passphrases (if you cached them, that is). Without caching it won't work, and I think even keys with empty passphrases need caching (but I'm not sure, I don't have any of those).

choogi · 2009-10-31 21:21:36

wicd supports executing preconnect, postconnect, predisconnect, and postdisconnect scripts on each of those events. I saved the above code to a script and set it to execute on postconnect.

I have an empty passphrase so when I execute the script from the terminal, sshfs mounts correctly. It's really just a matter of executing the command so I'm not sure what's going on in wicd that would prevent it from executing it properly.

In either case, how do others on this forum auto-mount sshfs on a wireless network?

tomk · 2009-10-31 23:21:31

I don't have that specific requirement, but I do start a vpn and mount nfs shares using POST_UP in my netcfg profile, which sounds like roughly similar functionality.

R00KIE · 2009-11-01 00:24:11

Maybe the script is being run as root and somehow that breaks things, maybe you are not using absolute paths for either the remote or local directories .... I don't see much else that can go wrong.

.:B:. · 2009-11-01 15:00:29

As I said: you need to look into keychain.

Since you don't seem inclined to do that, let me explain why you'll need something like it. Your script is run as a separate instance and quite probably won't inherit all the variables from your user environment (which, amongst others, has some SSH-specific variables). Keychain should take care of that.

I had a similar problem with a cron job with SSH keys. The script would run fine in a terminal if I launched it but never when run through cron (which has a limited environment).

uwinkelvos · 2009-11-02 17:28:19

If you dont want to setup keychains... i think this should do the trick:

sudo -i {yourscript.sh}

then confirm the host key to be permanently added.

Last edited by uwinkelvos (2009-11-02 17:29:00)

choogi · 2010-06-18 20:26:09

Sorry to resurrect a dead thread but I recently decided that I really wanted to get this working and haven't found anyone else who's been able to get this working either. I've tried using keychain and 'sudo -i' as per the previous two suggestions but neither of those seems to work. Has anyone else been able to connect an ssh filesystem via wicd's post connect scripts?

DarkVenger · 2012-01-16 23:44:26

Since this thread was Google's first hit when I searched for a solution for this very same problem and the scarce information it contains helped me come up with a solution. I decided to invoke the If you have a version-agnostic or corresponding solution, necrobumping can be appropriate. rule and post here the solution.

The problem in "detail"
Wicd runs the scripts as root, but in a very, very restrictive environment. This is cool, because I suppose its aimed to be secure.
In this restrictive environment there's no information about the running ssh-agent process, so the sshfs mounts will fail.

uwinkelvos's solution
I just want to explain why it does not work, because I lost quite some time pursuing this path...
Neither this

 sudo -i {your_script.sh}

nor this

 sudo -u user_name_which_has_ssh-agent -i {your_script.sh}

will work, because the shell wicd spawns to run the your_script.sh does not inherit anything from the users' shell environment and therefore the information that an ssh-agent is running, is simply not there.

A solution/hack
The goal is to make SSH_AUTH_SOCK and SSH_AGENT_PID available inside your_script.sh.

1) Inside your ~/.bash_profile (I use pam_ssh, so my ssh-agent is running after a successful login) add:

echo "SSH_AGENT_PID=$SSH_AGENT_PID; export SSH_AGENT_PID;" >~/.thestuff
echo "SSH_AUTH_SOCK=$SSH_AUTH_SOCK; export SSH_AUTH_SOCK;" >>~/.thestuff

This code creates a hidden file in your home folder that contains the required ssh-agent information, formatted in a ready-to-source manner.

2) In your_script.sh, before the sshfs mount lines you just need to source the created file. After some tests I realized I had to wait for the file to exist, because the wicd daemon runs before I do my login, your_script.sh will run before the ssh-agent is present. So I use this code in my scripts:

THE_FILE=/home/Your_User/.thestuff
# Wait for the ssh-agent info to be available
while [ ! -f $THE_FILE ]; do
  sleep 5;
done
source ${THE_FILE} # source the required ssh-agent stuff
rm ${THE_FILE}  # deleted because it's not needed anymore and I'm a little paranoid

A solution/hack (the same but with keychain)
1) Inside your ~/-bash_profile add:

keychain --agents ssh --quick --quiet --noask $HOME/.ssh/your_key_file

this creates files in your home folder under the .keychain directory.

2) The name of the file keychain creates, is a concatenation of your hostname and shell so:

source /home/Your_User/.keychain/${HOSTNAME}-$(basename $SHELL) # source the required ssh-agent stuff

Remember HOSTNAME and SHELL will be defined, but HOME will not...

PS: If the original thread author, choogi, is still checking this. Please mark the thread as [SOLVED].

choogi · 2012-01-17 00:05:34

DarkVenger, you are a freaking god. Thanks for posting a solution to my 2+ year old problem. This thread has officially been marked SOLVED!

DarkVenger · 2012-01-17 10:56:19

choogi wrote:

DarkVenger, you are a freaking god. Thanks for posting a solution to my 2+ year old problem. This thread has officially been marked SOLVED!

Better late than never .

hokasch · 2012-02-26 18:00:52

DarkVenger, another big thank you from me - this problem was driving me nuts. I tried to mount sshfs with a networkmanager dispatcher script using gnome keyring. Your solution didn't quite work for me, but it brought me on the right track. As this is really not very well documented in the internetz, I'll ad my solution here.

Hacks for gnome keyring
I found exporting SSH_AUTH_SOCK to be sufficient. The socket takes the form of "/tmp/keyring-randomstring/ssh".
Here are two ways to make this string directly available in the dispatcher script (without saving it first from your normal session).

Method 1: Use find (via antrix.net)
Search for the socket directory by simply checking which directory named /tmp/keyring-*/ is owned by the user in question:

export SSH_AUTH_SOCK=`find /tmp/keyring-*/ -type s -user $USER -group $GROUP -name ssh`

Method 2: Interrogate gnome-session (adapted from Craig Phillips)
The idea is to find out the $pid of gnome-session, and then extract the SSH_AUTH_SOCK variable from /cat/proc/$pid/env. However, the socket we need in this case is listed as GNOME_KEYRING_CONTROL (which returns /tmp/keyring-randomstring).
Disclaimer: I have no knowledge of sed/regex,so please excuse the following mess - at least it works.

export gsessionpid=$(ps -C gnome-session -o pid --no-heading)
export SSH_AUTH_SOCK=$(cat /proc/${gsessionpid//[^0-9]/}/environ | sed 's/\x00/\n/g' | grep GNOME_KEYRING_CONTROL | sed 's/.\{22\}//' | sed 's/$/\/ssh/')

Caveats / How to include in Wiki
The above works for me with a single user and gnome-keyring as ssh agent. Method 1 would break if there is more then one keyring directory owned by the same user, no idea if this happens (multiple sessions/same user? uncleaned left-overs?). Method 2 would probably break if more than one user is logged in (multiple gnome-sessions? check for user in ps?). Also I already have multiple pids for gnome-session, but it always picked the "right" one. Without really knowing what is going on with gnome-session, seems a bit shaky to me.

I want to add this in the wiki, but I am not quite sure where/how to add it. As this problem appears in all restricted shells (wicd/networkmanager dispatcher, netcfg?) maybe the best place would be the ssh-keys page. However, I don't quite understand how the different methods apply to the different key managers (above are certainly gnome specific). Also the second method above might be redundant. What do you think?

Last edited by hokasch (2012-02-26 18:11:12)

Arch Linux

#1 2009-10-31 16:48:14

[SOLVED] Mounting sshfs through wicd

#2 2009-10-31 21:02:12

Re: [SOLVED] Mounting sshfs through wicd

#3 2009-10-31 21:21:36

Re: [SOLVED] Mounting sshfs through wicd

#4 2009-10-31 23:21:31

Re: [SOLVED] Mounting sshfs through wicd

#5 2009-11-01 00:24:11

Re: [SOLVED] Mounting sshfs through wicd

#6 2009-11-01 15:00:29

Re: [SOLVED] Mounting sshfs through wicd

#7 2009-11-02 17:28:19

Re: [SOLVED] Mounting sshfs through wicd

#8 2010-06-18 20:26:09

Re: [SOLVED] Mounting sshfs through wicd

#9 2012-01-16 23:44:26

Re: [SOLVED] Mounting sshfs through wicd

#10 2012-01-17 00:05:34

Re: [SOLVED] Mounting sshfs through wicd

#11 2012-01-17 10:56:19

Re: [SOLVED] Mounting sshfs through wicd

#12 2012-02-26 18:00:52

Re: [SOLVED] Mounting sshfs through wicd

Board footer