Re: svn+ssh long-lived daemon

On 20 November 2015 at 06:08, Daniel Shahaf <d.s_at_daniel.shahaf.name> wrote:
> 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).
>
> 3. VPN with key-based authentication, then just use svn:// over the VPN
> subnet. For example, OpenVPN can do this.
>
> 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.
>
5. HTTPS authentication using client certificates

-- 
Ivan Zhakov