Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
MIME-Version: 1.0
In-Reply-To: <20151120030822.GG2103@tarsus.local2>
References: <871tblc0ii.fsf@wandisco.com>
 <20151120030822.GG2103@tarsus.local2>
From: Ivan Zhakov <ivan@visualsvn.com>
Date: Fri, 20 Nov 2015 09:35:56 +0300
Message-ID: 
 <CABw-3Ye+cSR+pyHuiyyzQkH5Cgg3yBq+qUc9RpAaud7k=sgZsA@mail.gmail.com>
Subject: Re: svn+ssh long-lived daemon
To: Daniel Shahaf <d.s@daniel.shahaf.name>
Cc: Philip Martin <philip.martin@wandisco.com>, dev@subversion.apache.org
Content-Type: text/plain; charset=UTF-8

On 20 November 2015 at 06:08, Daniel Shahaf <d.s@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