Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

Hullo,

I have Ubuntu Server running a subversion server. I'm running the client on the same machine through SSH, and I'd like the svn client to remember my password, but not to store it as plaintext. Looking here I see two methods: gnome-keyring and kwallet. As I'm not using a desktop manager I'm a bit wary about trying to use one of these. Any suggestions? Would it be ok (or even work) to use one of the two apps I mentioned?

TIA

share|improve this question

2 Answers 2

up vote 7 down vote accepted
  1. You can run Gnome-keyring or Kwallet on the remote machine. Each comes in two components, a daemon and a GUI.

    • You can run the GUI application on the remote machine if you run ssh with X forwarding. Just because it's a “server” machine doesn't mean you can't install GUI applications on it. It doesn't matter whether you're running the corresponding desktop environment or not, applications don't need a specific desktop environment to run.

    • You can control Kwallet on the command line through qdbus, though it's not a good idea in this specific case because you'd have to write your password in cleartext on a command line, and this can be snooped by other users. See also this SU answer.

    • There's a python binding for both Gnome-keyring and Kwallet (packages python-keyring-gnome and python-keyring-kwallet); you could write a tiny python script to control them. In fact there's already one for Gnome-keyring: gkeyring.

    • If your keyring password is the same as your login password, you can install the libpam-keyring and your keyring will be automatically unlocked when you log in. However this requires logging in with a password rather than a key pair.

  2. If you're running Gnome-keyring or Kwallet locally, you can forward them through ssh, with a bit of work. They use Unix sockets, which ssh can't forward. But you can use socat relay the Unix sockets to TCP sockets locally and the other way round on the remote machine:

    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 &
    

    This can be automated with small shell scripts on each side and a RemoteForward line in ~/.ssh/config. In theory, you should then be able to access the gnome keyring from the remote machine. However, I tried to access it with seahorse, and it didn't even try to connect to $GNOME_KEYRING_SOCKET; I don't know why, and I don't know if svn would be able to access the keyring.

  3. You can store your svn password on an encrypted filesystem. There are several options; I think the simplest way to get going is encfs. Initial setup:

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

    Normal workflow:

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

    This method has my preference for several reasons:

    • Both the initial setup and the normal workflow are very simple.
    • It doesn't matter where you log in from, in particular you don't need have a local X server and use X forwarding over ssh.
    • An encrypted filesystem is more versatile than a keyring (though it's less convenient for keyring use, but in the svn case that doesn't matter).
    • The only non-ubiquitous tool you need is encfs (which requires FUSE), and it is packaged for Ubuntu.
share|improve this answer
    
More than I could've hope for in an answer, thanks! I'll try the 3rd approach and report back. –  Andy Sep 10 '10 at 12:32
    
Very complete answer. –  this.josh Jan 27 '12 at 17:35
    
Is it possible to make subversion bail out if ~/.subversion/auth is empty/non-existent? Otherwise, 3rd approach is a bit dangerous if you forget to run encfs first. –  unhammer Sep 18 '12 at 11:31
    
@unhammer With this approach, if the encfs filesystem isn't mounted, then ~/.subversion/auth is a dangling symbolic link. In that case subversion tells you that it's going to store your password (if you haven't turned off that notification) but does not in fact store it anywhere (tested with svn 1.6.6). So there is no risk with the third approach. –  Gilles Sep 18 '12 at 12:16
    
aha, I first tried without the symlink, but now I see a symlink to a folder inside the encrypted folder does work, thank you for clearing that up :-) –  unhammer Sep 19 '12 at 11:32

gpg encrypt a file with the password in, - but then you'll need a passphrase for that (and dont lose the private key!).

I guess you could check into svn the private key as well as youll still need the passphrase to use it, but this whole setup seems a bit odd.

why are you needing to do this ?

share|improve this answer
    
I'm not looking for a general purpose way to encrypt, but a way that plugs in nicely with SVN. When I've used SVN on Ubuntu dekstop there's not been a problem, so I presume it's been using gnome-keyring. I presume again that gnome-keyring's not installed on Ubuntu server, and that's why there's the issue. Currently I can check stuff in, but I get a warning that I can only store the password unencrypted. See the link I gave for more details. Thanks. –  Andy Sep 9 '10 at 14:48
    
I've clarified the explanation above, hth. –  Andy Sep 9 '10 at 14:51
    
I'd love to use ~/.authinfo.gpg with the standard netrc format for SVN, and have gpg handle the encryption, but unfortunately it that seems like it'd require a bit more setup than the encfs solution. It doesn't seem like svn allows arbitrary user-defined password stores. –  unhammer Sep 18 '12 at 11:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.