mac - Why does directory vanish when I do SSHFS? How to setup SSHFS share on Max OSX 10.9?

08
2014-07
  • Saqib Ali

    I'm running Max OSX 10.9.3 and I'm trying to setup an SSHFS file-share between my MacBook Pro and a remote file system. However, when I try to do it, it doesn't work.

    Strangely enough, it makes the target directory disappear. Has anyone else seen this happen? Is it a bug?

    First see that I can ssh normally into the target machine:

    % ssh [email protected]            # <--- SSH to remote system works! See below.
[email protected] % ls -altr remoteDir
total 8
drwxr-xr-x 26 remoteuser remoteuser 4096 Jun 22 01:00 ..
drwxrwxrwx  2 remoteuser remoteuser 4096 Jun 22 01:08 .
[email protected] % exit
%                                           # <--- Logged out of remote system

    Next, I create a directory locally and verify it was created: 

    % pwd
/mnt

% ls
total 0
drwxr-xr-x  31 root  admin  1122 Jun 18 18:34 ../
drwxr-xr-x   2 root  admin    68 Jun 23 08:11 ./

% sudo mkdir share1 
% ls
drwxr-xr-x  31 root  admin  1122 Jun 18 18:34 ../
drwxr-xr-x   4 root  admin   136 Jun 23 08:50 ./
drwxr-xr-x   2 root  admin    68 Jun 23 08:50 share/

    Now I try to setup the SSHFS share:

    % sudo sshfs [email protected]:remoteDir /mnt/share1
[email protected]'s password:
%

    Ok. It seems to have worked. No errors. So let's see the share we created, shall we?

    % ls
ls: share1: No such file or directory
total 0
drwxr-xr-x  31 root  admin  1122 Jun 18 18:34 ../
drwxr-xr-x   3 root  admin   102 Jun 23 08:12 ./

    What? Not only is the File Sharing not working, but the share1 directory seems to have vanished! (Although the file system seems to know it is missing, which is weird).

    Where did /mnt/share1 go and how do I setup this SSHFS?

    • Answers
  • TommyD

    Check out the config options https://code.google.com/p/macfuse/wiki/OPTIONS

    I added 'allow_other' and it worked for me. Here is my connect string:

    sshfs -p 22 [email protected]:/home/user/ ~/RemoteHome -oauto_cache,reconnect,defer_permissions,negative_vncache,allow_other,volname=RemoteHome


    • Related Question

    how to setup .ssh directory inside an encrypted volume on Mac OSX and still have public key logins?
  • Vitaly Kushner

    I have my .ssh directory inside an encrypted sparse image. i.e. ~/.ssh is a symlink to /Volumes/VolumeName/.ssh

    The problem is that when I try to ssh into that machine using a public key I see the following error message in /var/log/secure.log:

    Authentication refused: bad ownership or modes for directory /Volumes

    Any way to solve this in a clean way?

    Update:

    The permissions on ~/.ssh and authorized_keys are right:

    > ls -ld ~
drwxr-xr-x+ 77 vitaly  staff  2618 Mar 16 08:22 /Users/vitaly/
> ls -l ~/.ssh
lrwxr-xr-x  1 vitaly  staff  22 Mar 15 23:48 /Users/vitaly/.ssh@ -> /Volumes/Astrails/.ssh
> ls -ld /Volumes/Astrails/.ssh 
drwx------  3 vitaly  staff  646 Mar 15 23:46 /Volumes/Astrails/.ssh/
> ls -ld /Volumes/Astrails/
drwx--x--x@ 18 vitaly  staff  1360 Jan 12 22:05 /Volumes/Astrails//
> ls -ld /Volumes/
drwxrwxrwt@ 5 root  admin  170 Mar 15 20:38 /Volumes//

    error message sats the problem is with /Volumes, but I don't see the problem.

    Yes it is o+w but it is also +t which should be ok but apparently isn't.

    The problem is I can't change /Volumes permissions (or rather shouldn't) but I do want public key login to work.

    First I thought of mounting the image on other place then /Volumes, but it is automaunted on login by standard OSX mounting. I asked about it here: How to change disk image's default mount directory on osx The only answer I got is "you can't" ;)

    I could hack my way around, by writing some shellscript that will manually mounting volume at a non-standard location but it would be a gross hack, I'm still looking for a cleaner way to do what I need.


    • Related Answers
  • Andy

    $ man sshd_config ; the answer is here

     StrictModes
         Specifies whether sshd(8) should check file modes and
         ownership of the user's files and home directory before
         accepting login.  This is normally desirable because
         novices sometimes accidentally leave their directory or
         files world-writable.  The default is ``yes''.

    $ sudo emacs /etc/sshd_config ; turn off mode checking

    -   #StrictModes yes
+   StrictModes no

    $ /usr/sbin/sshd ; restart sshd

    Just don't forget to keep your .ssh file permissions correct.

  • Majenko

    Now, I am not sure how to do it specifically on OS/X, but as OS/X is a BSD system, it should be similar to FreeBSD.

    Here's how you do it on FreeBSD.

    sshd won't follow symlinks for its key files. That is done on purpose for security. So, you need to change where sshd is trying to look for the key files.

    You will need to modify the /etc/ssh/sshd_config file and look for the AuthorizedKeysFile entry. That defaults to .ssh/authorized_keys (which is relative to the user's home directory).

    Change the entry to be the full (absolute) path of the actual location of the authorized_keys file. There is a certain amount of token replacement available - the most useful is %u which gets replaced with the username of the user logging in.

    For example: 

    AuthorizedKeysFile /Volumes/EncryptedData/%u/.ssh/authorized_keys

    would give you /Volumes/EncryptedData/vitaly/.ssh/authorized_keys

    If it's only ever going to be the one user using the system then it is fairly safe to omit the %u expansion and just use a single path - but be warned: if you add more users they will all use the same key file so it's a good idea to use username expansion right from the start just incase (you don't want to add a user 6 months down the line and forget that you had done this)

    So, if you have a /etc/ssh/sshd_config file on your system, then this method should work.

  • anazimok

    Make sure permissions are right. See here