Como posso armazenar em cache uma senha do Subversion em um servidor, sem armazená-la em um formato não criptografado?

Question

Meu servidor Subversion apenas fornece acesso via HTTPS; o suporte para svn + ssh foi descartado porque queríamos evitar a criação de usuários do sistema naquela máquina apenas para o acesso ao SVN. Agora estou tentando fornecer uma maneira de os usuários armazenarem em cache suas senhas por um tempo, sem deixá-las armazenadas no sistema de arquivos em forma não criptografada.

Isso não é problema para os usuários do Gnome ou do KDE, porque eles podem usar gnome-keyring e kwallet, respectivamente. O IIRC, o TortoiseSVN também possui um mecanismo de cache similar. Mas e os usuários em um sistema não-GUI?

Algum contexto: neste caso, temos um servidor de desenvolvimento / teste em que um projeto foi registrado no diretório htdocs do Apache. O desenvolvimento para este projeto está quase concluído e apenas pequenas alterações de texto / layout são executadas diretamente neste servidor. No entanto, as mudanças devem ser verificadas no repositório. Não há kwallet e nenhum gnome-keyring neste sistema, e o ssh-agent não pode ajudar porque o repositório é acessado via https em vez de svn + ssh.

Até onde eu sei, isso deixa a opção de digitar a senha toda vez que eles conversam com o servidor SVN ou o armazenam de maneira insegura.

Existe alguma maneira de obter algo como o que o gnome-keyring e o kwallet fornecem em um ambiente não-GUI?

    

Answer 1

Não, você não pode.

O HTTPS não suporta nenhum tipo de hashing unidirecional em senhas. Em algum momento do processo, você precisa da senha em texto simples disponível. Pode ser possível criptografá-lo até este ponto, no entanto, dado que você precisaria da chave de descriptografia no servidor também, não há muito sentido.

Mesmo se o HTTPS suportasse uma forma de hashing de senhas, você não poderia fazer isso (ele precisaria ter alguma proteção contra ataques de repetição, caso contrário, seu hash de senha se tornaria a senha!)

Não é uma solução real, mas mudar para algo distribuído, como o Git, resolveria bem esse problema. Você faria com que os usuários configurassem o encaminhamento do agente SSH para a máquina à qual estavam se conectando e a autenticação seria baseada nisso.

    

Answer 2

Não sei o que os caras de TI fizeram com o nosso servidor SVN para causar isso, mas cansei-me do prompt de senha da GUI, então eu ajustei ~/.subversion/config file para remover o [gui] kwallet e use somente o prompt de modo de texto :

password-stores = gnome-keyring

Mas mesmo isso ainda era meio chato, então fiz isso algumas vezes na minha árvore de código:

vi +/http .svn/entries

e alterou o http: para https: um par de vezes e, em seguida, não fui mais solicitado.

Estranhamente, eu não precisei alterá-lo em todos os lugares ... ou talvez em qualquer lugar ... em algum momento, um daemon morreu ou um SIGHUP foi enviado ou algo assim ... Eu notei que um dos arquivos sob este diretório atualizado:

~/.subversion/auth/svn.simple/

Parece bom para como. Ah, a solução alternativa.

    

Answer 3

Como @devicenull disse, a senha real precisa eventualmente estar disponível. No entanto, uma opção seria usar algo como encfs ou ecryptfs para criptografar toda ou parte dos [0] diretórios home dos usuários, o que significaria que a senha seria armazenada criptografada no disco. Isso ainda precisa ser desbloqueado quando eles fizerem login (embora isso possa ser feito com o PAM, se eles estiverem usando a autenticação de senha), e os usuários teriam que garantir que ele seja desmontado quando estiverem prontos.

[0] Obviamente, você quer que o ~ / .ssh / esteja na parte criptografada.