como configurar o diretório .ssh dentro de um volume criptografado no Mac OSX e ainda ter logins de chave pública?

3

Eu tenho meu diretório .ssh dentro de uma imagem esparsa e criptografada. Ou seja, ~ / .ssh é um link simbólico para /Volumes/VolumeName/.ssh

O problema é que, quando tento ssh nessa máquina usando uma chave pública, vejo a seguinte mensagem de erro em /var/log/secure.log:

Authentication refused: bad ownership or modes for directory /Volumes

Qualquer maneira de resolver isso de uma maneira limpa?

Atualização:

As permissões em ~ / .ssh e authorized_keys estão corretas:

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

mensagem de erro sats o problema é com / Volumes, mas não vejo o problema.

Sim, é o + w, mas também é + t, o que deve ser ok, mas aparentemente não é.

O problema é que não posso alterar / Permissões de volumes (ou melhor, não devo) mas quero que o login de chave pública funcione.

Primeiro, pensei em montar a imagem em outro local, em seguida, / Volumes, mas ela é automatizada no login pela montagem padrão do OSX. Eu perguntei sobre isso aqui: Como alterar o padrão da imagem de disco diretório de montagem no osx A única resposta que recebi é "você não pode";)

Eu poderia hackear meu caminho, escrevendo algum shellscript que montaria manualmente o volume em um local fora do padrão, mas seria um hack bruto, ainda estou procurando uma maneira mais limpa de fazer o que eu preciso.

    
por Vitaly Kushner 15.03.2011 / 22:50

3 respostas

3

$ man sshd_config ; a resposta é aqui

 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 ; desligar a verificação de modo

-   #StrictModes yes
+   StrictModes no

$ /usr/sbin/sshd ; reinicie o sshd

Apenas não se esqueça de manter suas permissões de arquivo .ssh corretas.

    
por 05.04.2011 / 17:32
0

Agora, não sei como fazê-lo especificamente no OS / X, mas como o OS / X é um sistema BSD, ele deve ser semelhante ao FreeBSD.

Veja como você faz isso no FreeBSD.

sshd não seguirá links simbólicos para seus arquivos principais. Isso é feito de propósito para segurança. Então, você precisa mudar onde sshd está tentando procurar pelos arquivos-chave.

Você precisará modificar o arquivo /etc/ssh/sshd_config e procurar a entrada AuthorizedKeysFile . Esse padrão é .ssh/authorized_keys (que é relativo ao diretório pessoal do usuário).

Altere a entrada para ser o caminho completo (absoluto) do local real do arquivo authorized_keys. Há uma certa quantidade de substituição de token disponível - o mais útil é %u , que é substituído pelo nome de usuário do usuário que faz o login.

Por exemplo:

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

daria a você /Volumes/EncryptedData/vitaly/.ssh/authorized_keys

Se for o único usuário a usar o sistema, é bastante seguro omitir a expansão% u e usar um único caminho, mas esteja avisado: se você adicionar mais usuários, eles > todos usam o mesmo arquivo de chave por isso é uma boa idéia usar a expansão de nome de usuário desde o início, basta inserir (você não deseja adicionar um usuário 6 meses e esquecer que teve feito isso)

Portanto, se você tiver um arquivo / etc / ssh / sshd_config em seu sistema, esse método deve funcionar.

    
por 16.03.2011 / 00:12
0

Certifique-se de que as permissões estejam corretas. Consulte aqui

    
por 16.03.2011 / 01:57

Tags