Using Svn client and Gnome keyring in SSH sessions
Subversion client software have traditionally stored (i.e. cached) plaintext user passwords, meaning that you password is accessible by anyone who can access files in your ~/.subversion/auth folder. With Subversion 1.6, however, support for KWallet and GNOME Keyring have been added, allowing for using these to store your subversion password encrypted. Of course it’s possible to turn off password caching, but then you’ll have to type in your password for most svn commands you issue.
As I’m using Gnome based environments, I’ll outline the steps needed to get svn client and Gnome keyring working within a SSH session, without needing to login in using the graphical interface. I’m sure much of it applies to KWallet too, but I haven’t tested this.
To have your svn client use the password stored in GNOME Keyring your svn client must be compiled with this this option. You can compile the svn client yourself, or simply download it from http://www.open.collab.net/downloads/subversion/.
Update 2011-06-01: The package subversion-gnome shipped with RHEL 6 provides a svn client compiled with GNOME keyring support. So for RHEL 6 users you can use this svn client instead of the one from CollabNet. I’ve not yet tested the RHEL 6 subversion-gnome client myself, but my guess it that it works the same way as the CollabNet svn client.
Setting up the svn client and Gnome keyring
After installing the svn client, we’ll need to tell svn that it should use a keyring for storing password. Make sure you have this line in ~/.subversion/config:
|
1 |
password-stores = gnome-keyring |
Then we’ll tell svn to store password, but _not_ cleartext password. Make sure these lines are present in ~/.subversion/servers under the section “global”:
|
1 2 |
store-passwords = yes store-plaintext-passwords = no |
Next, we’ll create a keyring to hold our svn password. It’s probably possible to use the default keyring for this, but in my example we’ll be using a dedicated one. For this task we’ll be using the excellent tool shipped with the OpenCollab svn client – _keyring_tool_ (you’ll be asked to type in a password, which can be any password you’d like to use):
|
1 2 3 |
[root@server ~]# /opt/CollabNet_Subversion/bin/keyring_tool --create=svn Enter password for 'svn' keyring: Created 'svn' keyring. |
To set this new keyring as our default keyring, we’ll issue this command:
|
1 2 |
[root@server ~]# /opt/CollabNet_Subversion/bin/keyring_tool --setdef=svn Set 'svn' keyring as default. |
This completes the inital setup of the svn client and Gnome keyring. Now, let’s see how we can start using it.
Typical workflow
In later SSH sessions, to get things up and running we’ll need to make sure the Gnome keyring daemon is started. We can either issue this command in the shell, or add it to a login script:
|
1 |
[root@server ~]# export `gnome-keyring-daemon` |
That’s all we need to do to get Gnome keyring ready for storing encrypted svn client passwords. So let’s start using svn. Note that it’s important that you use the svn client shipped with the above software, and not the svn client shipped with you distribution (unless it’s compiled to support Gnome keyring):
|
1 2 3 |
[root@server ~]# /opt/CollabNet_Subversion/bin/svn co --username my-username https://subversion.example.com/svn/my-repo/trunk/ /path/to/working-copy Password for 'svn' GNOME keyring: [...] |
That’s it! Now your svn client password should be stored safely by the Gnome keyring.
16 thoughts on “Using Svn client and Gnome keyring in SSH sessions”
This is a very useful blog, Kenneth. The only problem is, I can’t seem to get the GNOME keyring working properly in the first place. I’m attempting your steps on Solaris SPARC. I installed the GNOME Keyring packages from OpenCSW and the latest Subversion client from CollabNet, with keyring support built-in. However, I seem to be tripped up very early in your steps. Here is what I’ve tried so far, any suggestions as to what might be going wrong?
-bash-3.00$ export
gnome-keyring-daemongnome-keyring-daemon: couldn’t lookup ssh component setting: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details – 1: Not running within active session)gnome-keyring-daemon: couldn’t lookup pkcs11 component setting: Failed to contact configuration server; some possible causes are that you need to enable TCP/IP networking for ORBit, or you have stale NFS locks due to a system crash. See http://projects.gnome.org/gconf/ for information. (Details – 1: Not running within active session)-bash-3.00$
Hmmm, not a great start. Let’s see what happens next:
-bash-3.00$ keyring_tool –create=svn
Enter password for ‘svn’ keyring:
ERROR: Error communicating with gnome-keyring-daemon
Some extra diags:
-bash-3.00$ which gnome-keyring-daemon
/opt/csw/bin/gnome-keyring-daemon
-bash-3.00$ which keyring_tool
/opt/CollabNet_Subversion/bin/keyring_tool
-bash-3.00$ ldd /opt/CollabNet_Subversion/bin/keyring_tool
libgnome-keyring.so.0 => /opt/csw/lib/libgnome-keyring.so.0
libglib-2.0.so.0 => /opt/csw/lib/libglib-2.0.so.0
libiconv.so.2 => /opt/CollabNet_Subversion/lib/libiconv.so.2
libc.so.1 => /lib/libc.so.1
libdbus-1.so.3 => /opt/csw/lib/libdbus-1.so.3
libintl.so.8 => /opt/csw/lib/libintl.so.8
libsocket.so.1 => /lib/libsocket.so.1
libpthread.so.1 => /lib/libpthread.so.1
libbsm.so.1 => /lib/libbsm.so.1
libnsl.so.1 => /lib/libnsl.so.1
libmd.so.1 => /lib/libmd.so.1
libsecdb.so.1 => /lib/libsecdb.so.1
libtsol.so.2 => /lib/libtsol.so.2
libmp.so.2 => /lib/libmp.so.2
libscf.so.1 => /lib/libscf.so.1
libcmd.so.1 => /lib/libcmd.so.1
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Fire-V440/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-V440/lib/libmd_psr.so.1
-bash-3.00$ ldd /opt/csw/bin/gnome-keyring-daemon
libgp11.so.0 => /opt/csw/lib/libgp11.so.0
libgthread-2.0.so.0 => /opt/csw/lib/libgthread-2.0.so.0
libpthread.so.1 => /lib/libpthread.so.1
libthread.so.1 => /lib/libthread.so.1
librt.so.1 => /lib/librt.so.1
libgio-2.0.so.0 => /opt/csw/lib/libgio-2.0.so.0
libgmodule-2.0.so.0 => /opt/csw/lib/libgmodule-2.0.so.0
libgconf-2.so.4 => /opt/csw/lib/libgconf-2.so.4
libdbus-1.so.3 => /opt/csw/lib/libdbus-1.so.3
libgcrypt.so.11 => /opt/csw/lib/libgcrypt.so.11
libgpg-error.so.0 => /opt/csw/lib/libgpg-error.so.0
libtasn1.so.3 => /opt/csw/lib/libtasn1.so.3
libgobject-2.0.so.0 => /opt/csw/lib/libgobject-2.0.so.0
libglib-2.0.so.0 => /opt/csw/lib/libglib-2.0.so.0
libintl.so.8 => /opt/csw/lib/libintl.so.8
libsocket.so.1 => /lib/libsocket.so.1
libc.so.1 => /lib/libc.so.1
libaio.so.1 => /lib/libaio.so.1
libmd.so.1 => /lib/libmd.so.1
libresolv.so.2 => /lib/libresolv.so.2
libz.so.1 => /opt/CollabNet_Subversion/lib/libz.so.1
libdl.so.1 => /lib/libdl.so.1
libORBit-2.so.0 => /opt/csw/lib/libORBit-2.so.0
libdbus-glib-1.so.2 => /opt/csw/lib/libdbus-glib-1.so.2
libbsm.so.1 => /lib/libbsm.so.1
libnsl.so.1 => /lib/libnsl.so.1
libiconv.so.2 => /opt/CollabNet_Subversion/lib/libiconv.so.2
libsecdb.so.1 => /lib/libsecdb.so.1
libtsol.so.2 => /lib/libtsol.so.2
libmp.so.2 => /lib/libmp.so.2
libscf.so.1 => /lib/libscf.so.1
libcmd.so.1 => /lib/libcmd.so.1
libdoor.so.1 => /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 => /lib/libgen.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,Sun-Fire-V440/lib/libc_psr.so.1
/platform/SUNW,Sun-Fire-V440/lib/libmd_psr.so.1
Now I don’t understand the gconf dependency. I’ve looked at http://projects.gnome.org/gconf as suggested by the initial error message, but it doesn’t really help. I have the CSWgconf2 package installed from OpenCSW, but am I supposed to have a running gconf daemon already before gnome-keyring-daemon can start-up? If so, how do I get it running? It doesn’t look like you ever had these problems. This server doesn’t have the GNOME Desktop installed at all, so I’m guessing your server did?
@Mark Bannister:
I agree is not a great start for getting keyring and subversion to play together. 🙂 The setup I described was performed on a RHEL 5 server, and I used the GNOME Keyring shipped with RHEL. Unfortunately, I don’t have any experience with Solaris SPARC, so I don’t have very many tips on how to debug your issue. Did you look into what was mentioned in the debug output from your command, the part about TCP/IP networking for ORBit and stale NFS locks? Maybe there are other GNOME Keyring provides out there (other than the one shipped by OpenCSW) that you can check out?
@Mark Bannister:
The problem I’m having, as described above, is probably not related to the ssh component setting failure, as the daemon continues to run regardless. Starting it up with the ssh component and in foreground mode shows further error messages:
$ gnome-keyring-daemon –components keyring,pkcs11 -f
GNOME_KEYRING_SOCKET=/var/tmp/keyring-vTJviG/socket
GNOME_KEYRING_PID=13541
** Message: couldn’t connect to dbus session bus: /opt/csw/bin/dbus-launch terminated abnormally with the following error: Autolaunch error: X11 initialization failed.
** Message: couldn’t allocate secure memory to keep passwords and or keys from being written to the disk
socket credentials not supported on this OS
$ keyring_tool –create=svn
Enter password for ‘svn’ keyring:
ERROR: Error communicating with gnome-keyring-daemon
Successive attempts to run keyring_tool result in a new error from gnome-keyring-daemon each time that reads:
socket credentials not supported on this OS
I’m using Solaris 10 update 8 without the GNOME Desktop installed. Instead I’ve installed the following packages from OpenCSW (and their dependencies):
CSWgnomekeyring 2.28.2,REV=2010.03.05
CSWgnomekeyringmgr 2.14.0
CSWdbus 1.3.1,REV=2010.07.04
I also needed to run ‘dbus-uuidgen –ensure’ as root before I could get this far.
Any help would be much appreciated. I’ve also dropped a message to the GNOME mailing list asking for help.
@Mark Bannister:
I’ve got it working now by using the gnome-keyring-daemon that comes with Solaris, rather than the OpenCSW one (which doesn’t appear to be compiled properly).
On a Solaris server that did not have the GNOME desktop installed, I had to add the following packages from the Solaris DVD:
SUNWgnome-libs-root
SUNWgnome-libs-share
SUNWgnome-base-libs-root
SUNWgnome-base-libs-share
SUNWxorg-clientlibs
SUNWlibpopt
SUNWpng
SUNWTiff
SUNWjpg
SUNWgnome-base-libs
SUNWgnome-a11y-base-libs
SUNWgnome-vfs-root
SUNWgnome-vfs-share
SUNWgnome-config-root
SUNWgnome-config-share
SUNWgnome-component-root
SUNWgnome-component
SUNWgnome-config
SUNWsmbar
SUNWsmbau
SUNWgnome-vfs
SUNWgnome-audio
SUNWlibexif
SUNWgnome-libs
Then to make use of it:
$ export LD_LIBRARY_PATH=/usr/lib:/opt/CollabNet_Subversion/lib:/opt/csw/lib
$ mkdir $HOME/.gnome2
$ chmod 700 $HOME/gnome2
Then following the blog above. Note that you must do this:
export
gnome-keyring-daemonbefore you can do a keyring_tool –create=svn, which is, I think, a correction needed in the above text.
@Mark Bannister:
I’m glad you got it working, and that you posted the steps here so that other Solaris users may get things up and running too.
– Kenneth
I’ve written a script to help with all of this. The script will manage creating a GNOME keyring for you and starting the GNOME daemon on your behalf. You can find the script and some instructions on how to get going with it here: http://www.unix.com/shell-programming-scripting/157714-subversion-gnome-keyring.html
@Mark Bannister:
That’s really great! Thanks for sharing the script.
– Kenneth
I was wondering if you had any success using the RHEL-5 provided v1.6.11 Subversion. It looks like they’ve trouble keeping gnome-keyring support in? (see bug links below), but I’m having trouble telling whether it’s in the latest 1.6.11 with RHEL 5.6. Looking between the two it appears not to be, but they could’ve built it differently, i guess?
$ rpm -q subversion
subversion-1.6.11-7.el5_6.3.i386
$ ls -ltr /usr/lib/libsvn*gnome*
ls: /usr/lib/libsvn*gnome*: No such file or directory
$ ls -ltr /opt/CollabNet_Subversion/lib/libsvn*gnome*
-rwxr-xr-x 1 root root 23123 Feb 24 11:38 /opt/CollabNet_Subversion/lib/libsvn_auth_gnome_keyring-1.so.0.0.0*
lrwxrwxrwx 1 root root 36 Apr 26 13:32 /opt/CollabNet_Subversion/lib/libsvn_auth_gnome_keyring-1.so.0 -> libsvn_auth_gnome_keyring-1.so.0.0.0*
lrwxrwxrwx 1 root root 36 Apr 26 13:32 /opt/CollabNet_Subversion/lib/libsvn_auth_gnome_keyring-1.so -> libsvn_auth_gnome_keyring-1.so.0.0.0*
I can get it to work using the directly downloaded CollabNet copy, but not the RHEL5 one.
https://bugzilla.redhat.com/show_bug.cgi?id=522592
https://bugzilla.redhat.com/show_bug.cgi?id=506781
My RHEL 5 servers ship with basically the same subversion version you’re running, and I’ve not gotten it working with Gnome keyring. From the bug links you provided it looks like there’s been an effort getting it into Fedora, but it doesn’t look like it’s made it’s way into RHEL (yet). Come to think of it, I think I’m gonna contact Red Hat support and ask if they plan on doing this in the future. I’ll post back here when I get to the bottom of it.
To your questions about how to determine whether a given subversion client comes compiled with Gnome keyring support, I’m not quite sure how this can be done. If you find a way to verify this please do drop a line here describing how.
As far as I can tell, if libsvn_auth_gnome_keyring-1.so is installed in the same directory as the other libsvn libraries, then you have GNOME Keyring support.
Here are two examples. The standard RHEL5 client:
$ cd /usr/lib; ls libsvn*
libsvn_client-1.so.0 libsvn_ra_dav-1.so.0
libsvn_client-1.so.0.0.0 libsvn_ra_dav-1.so.0.0.0
libsvn_delta-1.so.0 libsvn_ra_local-1.so.0
libsvn_delta-1.so.0.0.0 libsvn_ra_local-1.so.0.0.0
libsvn_diff-1.so.0 libsvn_ra_svn-1.so.0
libsvn_diff-1.so.0.0.0 libsvn_ra_svn-1.so.0.0.0
libsvn_fs-1.so.0 libsvn_repos-1.so.0
libsvn_fs-1.so.0.0.0 libsvn_repos-1.so.0.0.0
libsvn_fs_base-1.so.0 libsvn_subr-1.so.0
libsvn_fs_base-1.so.0.0.0 libsvn_subr-1.so.0.0.0
libsvn_fs_fs-1.so.0 libsvn_swig_py-1.so.0
libsvn_fs_fs-1.so.0.0.0 libsvn_swig_py-1.so.0.0.0
libsvn_ra-1.so.0 libsvn_wc-1.so.0
libsvn_ra-1.so.0.0.0 libsvn_wc-1.so.0.0.0
The CollabNet client:
$ cd /opt/CollabNet_Subversion/lib; ls libsvn*
libsvn_auth_gnome_keyring-1.so libsvn_ra-1.so
libsvn_auth_gnome_keyring-1.so.0 libsvn_ra-1.so.0
libsvn_auth_gnome_keyring-1.so.0.0.0 libsvn_ra-1.so.0.0.0
libsvn_client-1.so libsvn_ra_local-1.so
libsvn_client-1.so.0 libsvn_ra_local-1.so.0
libsvn_client-1.so.0.0.0 libsvn_ra_local-1.so.0.0.0
libsvn_delta-1.so libsvn_ra_neon-1.so
libsvn_delta-1.so.0 libsvn_ra_neon-1.so.0
libsvn_delta-1.so.0.0.0 libsvn_ra_neon-1.so.0.0.0
libsvn_diff-1.so libsvn_ra_serf-1.so
libsvn_diff-1.so.0 libsvn_ra_serf-1.so.0
libsvn_diff-1.so.0.0.0 libsvn_ra_serf-1.so.0.0.0
libsvn_fs-1.so libsvn_ra_svn-1.so
libsvn_fs-1.so.0 libsvn_ra_svn-1.so.0
libsvn_fs-1.so.0.0.0 libsvn_ra_svn-1.so.0.0.0
libsvn_fs_fs-1.so libsvn_repos-1.so
libsvn_fs_fs-1.so.0 libsvn_repos-1.so.0
libsvn_fs_fs-1.so.0.0.0 libsvn_repos-1.so.0.0.0
libsvn_fs_util-1.so libsvn_subr-1.so
libsvn_fs_util-1.so.0 libsvn_subr-1.so.0
libsvn_fs_util-1.so.0.0.0 libsvn_subr-1.so.0.0.0
libsvnjavahl-1.so libsvn_wc-1.so
libsvnjavahl-1.so.0 libsvn_wc-1.so.0
libsvnjavahl-1.so.0.0.0 libsvn_wc-1.so.0.0.0
RHEL 6 now ships with a GNOME keyring compatible svn client. See the update in the blog post for info.
You may find the following blog helpful: http://technicalprose.blogspot.com/2011/06/using-subversion-with-gnome-keyring.html
Ken,
I’ve updated Mark Bannister’s blog (see previous comment) with information that you might find useful.
Dennis
@Dennis McRitchie:
I just read it, and it looks good. Thanks for sharing this info!
– Kenneth
Hey Kenneth,
Great article – without something like this I would have struggled to get this anywhere near working.
After tons of trials and tribulations – it seems like I got everything setup. I have the keyring created for SVN and set a password. I went to my dir and tried to checkout my svn URL, and it prompts for me for my username’s password – which I’ll put in, then its ask me for the SVN keyring password? Is that correct?
I can type in anything here – it doesn’t need to match the password I created. Let’s for example pretend I made the password for the svn keyring “kenneth”, when I do the svn checkout and it prompts me for keyring password I can type in anything “billy” “kenneth” and even just leave it blank and hit enter, and it seeemingly works?
And then it says checked out revision #.
Shouldn’t it only take the password that matches the one I set for svn?
I’m glad the article was of some help. I’m not really in a position right now where I can look into this issue, but maybe some of the other commenters here could help out?