Qual é a melhor maneira de armazenar uma senha svn criptografada no Ubuntu Server?


8

Hullo,

Eu tenho o Ubuntu Server executando um servidor subversion. Estou executando o cliente na mesma máquina através do SSH e gostaria que o cliente svn se lembrasse da minha senha, mas não a armazenasse como texto sem formatação. Olhando aqui , vejo dois métodos: gnome-keyring e kwallet. Como não estou usando um gerenciador de desktop, sou um pouco cauteloso ao tentar usar um desses. Alguma sugestão? Seria bom (ou até funcionaria) usar um dos dois aplicativos que mencionei?

TIA

Respostas:


9
  1. Você pode executar o Gnome-keyring ou o Kwallet na máquina remota. Cada um vem em dois componentes, um daemon e uma GUI.

    • Você pode executar o aplicativo GUI na máquina remota se executar o ssh com o encaminhamento do X. Só porque é uma máquina “servidor” não significa que você não pode instalar aplicativos GUI nela. Não importa se você está executando o ambiente de área de trabalho correspondente ou não, os aplicativos não precisam de um ambiente de área de trabalho específico para serem executados.

    • Você pode controlar o Kwallet na linha de comando qdbus, embora não seja uma boa ideia nesse caso específico, porque você teria que escrever sua senha em texto não criptografado em uma linha de comando, e isso pode ser espionado por outros usuários. Veja também esta resposta SU .

    • Existe uma ligação python para o Gnome-keyring e o Kwallet (packages python-keyring-gnomee python-keyring-kwallet); você pode escrever um pequeno script python para controlá-los. De fato, já existe um para o chaveiro Gnome: gkeyring .

    • Se a senha do seu chaveiro for igual à sua senha de login, você poderá instalar o libpam-keyringe seu chaveiro será desbloqueado automaticamente quando você efetuar login. No entanto, isso exige que você faça login com uma senha em vez de um par de chaves.

  2. Se você estiver executando o Gnome-keyring ou o Kwallet localmente, poderá enviá-los através do ssh, com um pouco de trabalho. Eles usam soquetes Unix, que o ssh não pode encaminhar. Mas você pode usar a socatretransmissão dos soquetes Unix para soquetes TCP localmente e vice-versa na máquina remota:

    while true; do socat TCP-LISTEN:22007 UNIX-CONNECT:"$GNOME_KEYRING_SOCKET"; done &
    ssh -R22007:localhost:22007 remote.example.com
    export GNOME_KEYRING_SOCKET="$HOME/.gnome-keyring-socket"
    while true; do socat UNIX-LISTEN:"$GNOME_KEYRING_SOCKET" TCP4:localhost:22007; done &
    

    Isso pode ser automatizado com pequenos scripts de shell em cada lado e uma entrada de RemoteForwardlinha ~/.ssh/config. Em teoria, você poderá acessar o chaveiro do gnome na máquina remota. No entanto, tentei acessá-lo com cavalos-marinhos, e ele nem tentou se conectar $GNOME_KEYRING_SOCKET; Não sei por que e não sei se o svn seria capaz de acessar o chaveiro.

  3. Você pode armazenar sua senha svn em um sistema de arquivos criptografado. Existem várias opções ; Eu acho que a maneira mais simples de ir é encfs. Configuração inicial:

    sudo aptitude install encfs
    encfs ~/.passwords.encrypted ~/.passwords
    mv ~/.subversion/auth ~/.passwords/svn-auth
    ln -s ../.passwords/svn-auth ~/.subversion/auth
    

    Fluxo de trabalho normal:

    encfs ~/.passwords.encrypted ~/.passwords
    ... work ...
    fusermount -u ~/.passwords
    

    Este método tem minha preferência por vários motivos:

    • A configuração inicial e o fluxo de trabalho normal são muito simples.
    • Não importa de onde você efetua login, em particular você não precisa de um servidor X local e usa o encaminhamento do X pelo ssh.
    • Um sistema de arquivos criptografado é mais versátil que um chaveiro (embora seja menos conveniente para o uso do chaveiro, mas no caso do svn isso não importa).
    • A única ferramenta não onipresente de que você precisa é encfs (que requer o FUSE), e está empacotada para o Ubuntu.

Mais do que eu poderia esperar em uma resposta, obrigado! Vou tentar a terceira abordagem e relatar de volta.
Andy

Resposta muito completa.
precisa saber é o seguinte

É possível fazer o resgate do subversion se ~ / .subversion / auth estiver vazio / inexistente? Caso contrário, a terceira abordagem será um pouco perigosa se você esquecer de executar o encfs primeiro.
Unhammer

@unhammer Com essa abordagem, se o sistema de arquivos encfs não estiver montado, haverá ~/.subversion/authum link simbólico danificado . Nesse caso, o subversion diz que ele armazenará sua senha (se você não desativou a notificação), mas na verdade não a armazena em nenhum lugar (testado com o svn 1.6.6). Portanto, não há risco com a terceira abordagem.
Gilles 'SO- stop be evil'

aha, eu primeiro tentou sem o link simbólico, mas agora eu vejo um link simbólico para uma pasta dentro da pasta criptografada funciona, obrigado por esclarecer isso :-)
unhammer

0

O gpg criptografa um arquivo com a senha, - mas você precisará de uma senha para isso (e não perca a chave privada!).

Eu acho que você pode verificar o svn na chave privada e ainda precisará da frase secreta para usá-la, mas toda essa configuração parece um pouco estranha.

por que você precisa fazer isso?


Não estou procurando uma maneira geral de criptografar, mas uma que se conecte perfeitamente ao SVN. Quando usei o SVN no Ubuntu dekstop, não houve um problema, então presumo que ele esteja usando o gnome-keyring. Presumo novamente que o gnome-keyring não está instalado no servidor Ubuntu, e é por isso que existe o problema. Atualmente, posso fazer o check-in, mas recebo um aviso de que só posso armazenar a senha não criptografada. Veja o link que eu dei para mais detalhes. Obrigado.
Andy

Esclareci a explicação acima, hth.
Andy

Eu amo de usar ~ / .authinfo.gpg com o formato Netrc padrão para SVN, e têm gpg lidar com a criptografia, mas, infelizmente, que parece que iria exigir um pouco mais configuração do que a solução encfs. Não parece que o svn permita armazenamentos arbitrários de senhas definidas pelo usuário.
unhammer 18/09/12
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.