Daniel Shahaf <d.s_at_daniel.shahaf.name> writes:
> Philip Martin wrote on Thu, Nov 19, 2015 at 18:22:29 +0000:
>> Are there alternative ways to get a long-lived daemon to do
>> authentication with public/private key pairs?
>
> 1. Plain old ssh port forwarding:
>
> server# svnserve -d
> client% ssh -MNf -L 3690:localhost:3690 $remotebox
> client% svn info svn://localhost/myrepos
>
> 2. Same, but without allocating a TCP port on the client:
>
> server# svnserve -d
> client% cat .subversion/config
> [tunnels]
> office = $SVN_OFFICE ssh -W localhost:3690 svn.office.com.example ;:
> client% svn info svn+office:///myrepos
>
> The ";:" at the end is to ignore the "svnserve -t" string that gets
> appended to the command line after stripping the variable and before
> passing it to system(). The URI has an an empty "host:port" part
> because the tunnel hardcodes the hostname. The client might still run
> 'ssh -MNf' beforehand, but unlike in #1 where running ssh manually was
> required, here it is merely a performance optimization.
>
> "ControlPath" may need to be set in ssh_config(5).
AFAICT 1 and 2 have the same issue as my use of a socat proxy. The key
pair is used to setup the ssh tunnel but that doesn't provide
authentication to the daemon. For Subversion to work, i.e. things like
svn:author and authz, a separate Subversion authentication has to
happen. The server has to be configured for both ssh keys and for
Subversion credentials and the user for is asked for authentication
twice.
What I want is a single authentication that only requries a key pair and
a username.
> 3. VPN with key-based authentication, then just use svn:// over the VPN
> subnet. For example, OpenVPN can do this.
This also requires Subversion authentication over the VPN. The server
still has to configured for Subversion credentials in addition to the
VPN credentials and the user is authenticated twice.
> 4. An ra_svn proxy that adds authentication info. The server runs
> 'svnserve -i --listen-host=localhost' and sshd. In
> .ssh/authorized_keys, instead of running socat as in your description,
> run a proxy that understands the ra_svn protocol, intercepts
> server-to-client authentication requests and answers them with
> credentials determined as a function of the authenticated ssh identity,
> and passes everything else back-and-forth unmodified.
That is an alternative. An svnproxy might have other uses, it might be
possible to implement a write-through proxy for the svn:// protocol.
--
Philip Martin
WANdisco
Received on 2015-11-20 12:17:20 CET