Como salvar a senha ao usar o Subversion a partir do console

106

Eu queria saber se existe uma maneira de salvar minha senha do Subversion ao fazer svnoperações no console. O console é a única opção que tenho. Quando tento realizar qualquer ação do Subversion, por exemplo svn commit, ele sempre solicita a senha da conta. Existe uma maneira de salvar essa senha de alguma forma para que eu não tenha que digitá-la novamente?

svn passwords

— john mcdonald
fonte

Veja também não é possível fazer svn store password, embora a configuração esteja definida para permitir a solução de problemas caso a resposta aceita não funcione.

— maxschlepzig de

110

Em ~/.subversion/config, você provavelmente tem store-passwords = no. Mude para yes(ou apenas comente porque o padrão é sim), e da próxima vez que você fornecer sua senha ao Subversion, ele deverá salvá-la.

Você pode querer garantir que o proprietário e as permissões de ~/.subversion/configestão corretos (sem acesso público ou de grupo; 600).

— Michael Mrozek
fonte

Não consigo encontrar este arquivo em Red Hat Linux 2.6.18. alguma ideia de onde poderia estar?

— Ish

3

@Ish Você pode precisar fazer isso se ainda não existir; Acho que o SVN está lá em todas as distros

— Michael Mrozek

5

+1, depois de criar o /etc/subversion/configsistema de arquivos funcione conforme o esperado. Obrigado

— Ish

Obrigado @IshKumar! Funcionou para mim pela primeira vez!

— Anil

15

@Seven Melhor ainda, basta escrever uma nova resposta mais atualizada. (A store-passwordsopção em configagora está obsoleta, de acordo com alguns comentários padrão que encontrei em meu configarquivo; ela foi substituída pela mesma opção em servers.)

— Kyle Strand

54

Depende do protocolo que você está usando. Se você estiver usando SVN + SSH, o cliente SVN não pode salvar sua senha porque nunca a toca - o cliente SSH solicita a senha diretamente. Nesse caso, você pode usar uma chave SSH e um agente ssh para evitar os prompts constantes. Se você estiver usando o protocolo svnserve ou HTTP (S), então o cliente SSH está controlando sua senha e pode salvá-la.

— ninguém
fonte

4

+1 Eu tenho exatamente este problema - svn + ssh sempre, sempre me pede uma senha. Além de compartilhar uma chave pública, há uma maneira de evitar isso? Eu tentei o ssh-agent, mas sem sorte.

— Michael Mikowski

@MichaelMikowski Parece que a senha SSH não pode ser salva na configuração para login automático. Você pode criar um novo par de chaves para ele, armazenar a localização da chave privada em .ssh/confige anexar a chave pública ao servidor SVN.

— lk_vc

33

Tente limpar sua .subversionpasta em seu diretório pessoal e tente confirmar novamente. Ele deve solicitar sua senha e, em seguida, perguntar se deseja salvá-la.

— Earlz
fonte

Você quer dizer a pasta .subversion!

— khmarbaise

3

Eu tive o mesmo problema. Eu não tinha nenhuma das configurações de senha de armazenamento definidas como "não" em meu arquivo de configuração ou servidores, mas funcionou.

— Bob B de

1

Eu estava tentando mudar todos os tipos de configurações sem sucesso. A única coisa que resolveu esse problema foi, de fato, excluir a pasta .subversion.

— Michael Noyb

Isso funcionou para mim também. Curiosamente, ele armazenou a senha dentro da pasta ~ / .subversion / auth / svn.simple para mim.

— Chetan de

Isso também funcionou para mim, mas observei para ver qual era a diferença - e acabou sendo a propriedade do diretório .subversion e de seus arquivos. Depois de transferir dados de outra máquina, esse diretório de alguma forma acabou sendo propriedade do root, quando deveria ser meu. Remover o diretório e deixar svn recriá-lo corrigiu o problema (mas provavelmente o chown também teria corrigido).

— Joe Strout

19

Eu tive que editar ~/.subversion/servers. Eu defini store-plaintext-passwords = yes(não havia anteriormente). Isso funcionou. Pode ser considerado inseguro.

— hajamie
fonte

3

No mesmo arquivo, eu tive que definir store-passwords = yes. Acredito que foi definido antes, mas não foi definido quando atualizei para o SVN 1.7

— pieman72

9

Observe o seguinte parágrafo do ~/.subversion/serversarquivo:

Tanto 'store-passwords' quanto 'store-auth-creds' agora podem ser especificados no arquivo 'servers' em seu diretório de configuração. Qualquer coisa especificada nesta seção é substituída pelas configurações especificadas no arquivo 'servidores'.

É pelo menos para o SVN versão 1.6.12. Portanto, lembre-se de editar o arquivo de servidores também durante a substituição ~/.subversion/config.

— Rusu Bogdan
fonte

Isso ajudou a ver que havia uma substituição no mesmo arquivo (declaração de dois "armazenamentos de senhas"!). Corrigido isso e o arquivo svn.simple foi criado com a propriedade gnome-keyring.

— Danielson Alves Júnior

5

Se você usar svn + ssh , poderá copiar sua chave ssh pública para a máquina remota:

ssh-copy-id user@remotehost

— Michael Schmid
fonte

5

Para mim (usuário de Mac), o problema era que o keychain já tinha uma entrada armazenada para minhas credenciais, mas os direitos de acesso não estavam corretos.

Excluir a entrada no aplicativo de chaveiro e, em seguida, recriá-la usando svn corrigiu o problema.

— trias
fonte

4

Nenhuma dessas respostas maravilhosas funcionou para mim em uma nova instalação do Ubuntu. Em vez disso, uma pista dessa resposta funcionou para mim.

Tive que permitir o armazenamento de senha "simples" definindo este vazio em ~/.subversion/config:

password-stores =

Não havia configuração existente, portanto, estar vazio é significativo.

Isso foi além de:

store-passwords = yes

no ~/.subversion/servers.

— Heath Raftery
fonte

Isso também me ajudou, pois parece que a opção padrão deve funcionar, mas a menos que seja explicitamente especificado, ela não funciona :(

— Arunas Bartisius

3

Usar texto simples pode não ser a melhor escolha, se a senha for usada para outra coisa.

Apoio a resposta aceita, mas não funcionou para mim - por um motivo muito específico: eu queria usar armazenamento de senhas kwalletou gnome-keyring. Tentei alterar as configurações nos quatro arquivos:

/etc/subversion/config
/etc/subversion/servers
~/.subversion/config
~/.subversion/servers

Mesmo depois de tudo ter sido configurado da mesma forma, com um password-storesnome do KWallet (o padrão pode estar errado, certo?) Ele não funcionou e continuou pedindo a senha para sempre. Os arquivos em ~/.subversiontinham permissões 600.

Bem, nesse ponto, você pode tentar verificar uma coisa simples:

which svn

Se você pegar:

/usr/bin/local/svn

então você pode suspeitar com grande probabilidade de que esse cliente foi criado a partir da fonte, localmente, pelo seu administrador (que pode ser você mesmo, como no meu caso).

O Subversion é uma besta desagradável de compilar , muito fácil de construir acidentalmente sem suporte HTTP, ou - como no meu exemplo - sem suporte para armazenamento de senhas criptografadas (você precisa de arquivos de desenvolvimento Gnome ou KDE, e muitos deles!). Mas o ./configurescript não dirá isso e você apenas obterá um svncomando menos funcional .

Nesse caso, você pode voltar ao cliente que veio com sua distribuição, geralmente em /usr/bin/svn. A desvantagem é - você provavelmente precisará verificar novamente as cópias de trabalho, pois não há svn downgradecomando. Você pode consultar Linus Torvalds sobre o que pensar sobre o Subversion, de qualquer maneira;)

— Tomasz Gandor
fonte

2

Para adicionar à resposta de Heath: Parece que o Subversion 1.6 desabilitou o armazenamento de senhas por padrão se não puder armazená-las na forma criptografada. Você pode permitir o armazenamento de senhas não criptografadas definindo explicitamente password-stores =(ou seja, com o valor vazio) em ~/.subversion/config.

Para verificar qual armazenamento de senhas o Subversion usa, dê uma olhada em ~/.subversion/auth/svn.simple. Ele contém vários arquivos, cada um deles uma tabela hash com uma codificação simples de chave / valor. O svn:realmstringem cada arquivo identifica a qual domínio esse arquivo se destina. Se o arquivo tiver

K 8
passtype
V 6
simple

em seguida, ele armazena a senha em texto simples em algum lugar desse arquivo, em uma K 8 passwordentrada. Caso contrário, ele tenta usar um dos configurados password-stores.

— thakis
fonte

1

Todos os métodos mencionados aqui não estão funcionando para mim. Eu construí o Subversion a partir da fonte e descobri que devo executar o configure com --enable-plaintext-password-storagepara suportar este recurso.

— Domínio
fonte

1

Apenas para enfatizar o que Tomasz Gandor e Domain disseram sobre ter a versão correta do svn e que ela foi compilada para permitir o armazenamento de senhas em texto simples, você precisa verificar o que tem:

svn --version
svn, version 1.9.7 (r1800392)
...
WARNING: Plaintext password storage is enabled!
...

The following authentication credential caches are available:

* Plaintext cache in /gr/home/ffvdqb/.subversion
* GPG-Agent

Versus:

svn --version
svn, version 1.12.2 (r1863366)
...

The following authentication credential caches are available:

* Gnome Keyring
* GPG-Agent
* KWallet (KDE)

Depois de ver que sua versão do svn foi habilitada para armazenamento de senha em texto simples, aplique todo o resto das respostas aqui.

— Jim
fonte

1

Estou usando o cliente TortoiseSVN no Windows e, para mim, definir o parâmetro store-passwords como yes em %USERPROFILE%\AppData\Roaming\Subversion\confignão ajuda a armazenar a senha.

A senha foi salva com sucesso após a remoção desta pasta (apenas no caso de renomear):

%USERPROFILE%\AppData\Roaming\Subversion\auth

Meio Ambiente:

Windows 7, TortoiseSVN 1.7.11 (Build 23600 - 64 bit, 2012-12-12T19:08:52), Subversion 1.7.8.

— Anton Arkhipkin
fonte

0

Infelizmente, as respostas não resolveram o problema de pedir uma senha para ssh + svn com uma chave privada protegida. Depois de algumas pesquisas, descobri:

ssh-add

utilitário se você tiver um computador Linux. Certifique-se de ter suas chaves armazenadas /home/username/.ssh/e digite este comando no Terminal.

— www
fonte