Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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.

share|improve this question

3 Answers 3

up vote 3 down vote accepted

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

share|improve this answer

Make sure permissions are right. See here

share|improve this answer
    
permissions of ~/.ssh and authorized_keys are correct. The problem seems to be with /Volumes but the permissions seem to be right too. –  Vitaly Kushner Mar 16 '11 at 6:24

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.

share|improve this answer
    
tried that. The problem is not with the symlink, apparently it does follow it, the problem is with /Volumes permissions, for some reason 1777 is not ok (I think it should be, but thats not relevant) –  Vitaly Kushner Mar 16 '11 at 7:04
1  
Oh, no, sshd is very very very fussy about the directory permissions. It doesn't want you to even remotely think about letting anyone else even near the .ssh directory. Try playing with those permissions (My home dir is 0755 and my .ssh dir is 0700) –  Majenko Mar 16 '11 at 9:29
    
my home can be even 700, I don't need any daemons snooping in there, but you kind of can't change /Volumes (or at least shouldn't) and 1777 means that anyone can create a dir in there, but you can't touch other people's stuff. it should be perfectly secure. –  Vitaly Kushner Mar 17 '11 at 18:00

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.