Como salvar a senha ao usar o Subversion a partir do console
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?
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
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).
Não consigo encontrar este arquivo em Red Hat Linux 2.6.18. alguma ideia de onde poderia estar?
@Ish Você pode precisar fazer isso se ainda não existir; Acho que o SVN está lá em todas as distros
+1, depois de criar o /etc/subversion/configsistema de arquivos funcione conforme o esperado. Obrigado
Obrigado @IshKumar! Funcionou para mim pela primeira vez!
@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.)
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.
+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.
@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.
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.
Você quer dizer a pasta .subversion!
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
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).
Eu tive que editar ~/.subversion/servers. Eu defini store-plaintext-passwords = yes(não havia anteriormente). Isso funcionou. Pode ser considerado inseguro.
— hajamie
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
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
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
Se você usar svn + ssh , poderá copiar sua chave ssh pública para a máquina remota:
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
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:
Não havia configuração existente, portanto, estar vazio é significativo.
Isso foi além de:
no ~/.subversion/servers.
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 :(
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:
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:
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;)
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
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.
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
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:
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.
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):
— Anton Arkhipkin
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:
utilitário se você tiver um computador Linux. Certifique-se de ter suas chaves armazenadas /home/username/.ssh/e digite este comando no Terminal.