Mau proprietário ou permissões em /root/.ssh/config em uma máquina virtual

Question

Estou usando uma VM do VirtualBox com o Debian como sistema operacional convidado. Para compartilhar chaves SSH entre o host do Windows e o sistema convidado do Linux, defini a pasta ~/.ssh como uma pasta compartilhada. Bun agora estou recebendo um erro:

# git clone [email protected]:user/project.git
Cloning into project...
Bad owner or permissions on /root/.ssh/config
fatal: The remote end hung up unexpectedly

Normalmente, para resolver este problema, é necessário apenas definir permissões mais estritas para ~/.ssh . Mas neste caso não é possível, já que é uma pasta compartilhada.

Existe outra solução / solução alternativa para esse problema?

Thx

    

Answer 1

Eu tinha montado minha pasta compartilhada com este comando (salvo em /etc/rc.local para montar a pasta no sistema automaticamente):

mount -t vboxsf -o uid=1000,gid=1000 sshkeys /root/.ssh

Agora alterei o usuário , o usergroup e os direitos de acesso da pasta montada no comando mount:

mount -t vboxsf -o uid=0,gid=0,umask=077 sshkeys /root/.ssh

Funciona.

P.S. Para todos, quem participou desta discussão:

Como o segmento se tornou um pouco caótico, gostaria de resumir:

Primeiro, tive o problema de não poder usar minhas chaves quando elas vinham de uma pasta compartilhada ( Bad owner or permissions... error). O corolário para mim era que havia duas maneiras: (a) definir o usuário, grupo e os direitos de acesso para a pasta como o cliente SSH (?) Precisava ou (b) fazer com que ele ignorasse suas restrições de direitos de acesso. Como não pude aplicar chown / chmod à minha pasta compartilhada e pensei, não foi possível alterar os direitos de acesso para ela, vi (b) como a última possibilidade de resolver o problema - e mudei a pergunta /título. Foi um erro e eu acabei de fazer essa mudança de volta.

Para a discussão sobre a segurança: Estou trabalhando como root (no meu dev VM!) e é um pecado mortal para todos os usuários conscientes da segurança. Na verdade eu também acho que normalmente não se deve logar como root. Mas eu tenho a opinião de que isso não se aplica ao caso de uma máquina virtual de desenvolvimento. De qualquer forma - é um offtopic, uma vez que não tem nada a ver com o problema, eu descrevi. Esse problema pode ocorrer para todos os usuários de todos os grupos de usuários.

    

Answer 2

A solução apropriada é parar de usar root para verificar um repositório git. Dê a cada usuário sua própria conta e mantenha as permissões apertadas o suficiente para que a segurança não seja comprometida.

Uma solução diferente seria usar um dos servidores git baseados na web em vez de um baseado em SSH. Eu nunca usei nenhum desses, então eu não posso te dar muitos conselhos.

    

Answer 3

Disclaimer: Eu agora acredito que esta é uma verificação de permissões pelo cliente git, não o servidor ssh. Isso tornaria essa resposta incorreta. Estou deixando minha resposta aqui para que não tenhamos que revisar o assunto novamente.

Eu realmente não quero responder isso, mas alguém vai postar a resposta que você está procurando, eventualmente, e também pode ser com as devidas renúncias.

1. Não faça isso. Todos os outros o afastaram dessa resposta por um motivo. É uma segurança terrível.
2. Não, realmente. Não faça isso. Não importa o quão conveniente pareça, isso vai contra algumas das convenções de segurança mais básicas que são tomadas como garantidas na indústria Unix. Você perderá um grande respeito daqueles que estão em sua vida profissional se descobrirem que você fez isso, mesmo que seja casualmente em seu próprio sistema.
3. Você está pedindo para ser propriedade.
4. Se você ainda está determinado em fazer isso ...

A resposta está em man sshd_config , você está procurando por StrictModes . Não pode ser configurado por usuário; isso é muito deliberado.

    

Answer 4

Uma solução que permite que você ainda tenha /root como uma 'pasta compartilhada' seria usar o AuthorizedKeysFile no seu arquivo sshd_config e configurá-lo para extrair suas chaves autorizadas de algum outro diretório .