On 20 November 2015 at 06:08, Daniel Shahaf <[email protected]> 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
