[prev in list] [next in list] [prev in thread] [next in thread] 

List:       subversion-users
Subject:    Multiple SSH key handling for svn+ssh access.
From:       Nico Kadel-Garcia <nkadel () gmail ! com>
Date:       2015-10-12 14:11:10
Message-ID: CAOCN9rxa2w+_+miRd_+oR8y51nsx04NWukrV_ZiXZrB=eSCTnA () mail ! gmail ! com
[Download RAW message or body]

I've recently been dealing with some svn+ssh, and git, issues where
the user may have "ssh-agent" running, and thus have different sets of
SSH keys available, when connecting to the same upstream repository.
The result can be confusing if the ssh-agent has multiple keys loaded
with different privileges, and especially if there is a local SSH key
for a system user, and would record commits or changes with different
usernames. So, I thought I'd point out my workaround!!!

Pick an upstream repository server, using SSH, such as
svn+ssh://server.example.com/localhost/repo/trunk/. When checking out
the repository as user1, and to keep the access consistent, use a fake
hostname and put it in $HOME/.ssh/config file, and tie it to a locally
stored copy of a *passphrase protected* private SSH key.

         Host user1.server.example.com
                  Hostname server.example.com
                  IdentityFile $HOME/.ssh/id_server

Then check out or switch to the repository URL to use the fake servername:

         svn+ssh://user1-server.example.com/localhost/repo/trunk

Repeat as necessary to use other forced credentials.

This way, the particular working copy can be tied to a particular set
of credentials and access linked to those credentials, rather than to
other credentials that may be stored in an "ssh-agent" or perhaps in
the default "$HOME/.ssh/id_rsa".

The passphrase protection of the private SSH key is not mandatory,
especially for unattended automatic pulls of configuration files, but
it can help avoid some security problems.
[prev in list] [next in list] [prev in thread] [next in thread]