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.
This way, the client authenticates to the interposed proxy using ssh,
and the interposed proxy authenticates to svnserve using $whatever;
there _is_ an additional password, but it's private to the proxy and
svnserve, never goes on the wire (except the loopback interface), and
never needs to be known by the user. It's essentially an implementation
detail of the server configuration.
This is basically similar to your design, but in-band rather than
out-of-band.
As an optimmisation, once the proxy has completed an authentication
request, it can stop parsing ra_svn protocol and just shuffle raw bytes
in both directions: it knows only one set of credentials, so once it's
provided them, knowing that the *same* credentials won't be asked for
a second time, it will have no more reason to parse the protocol. (This
means further authentication requests will go to the client, which can't
successfully answer them, but they will at least serve as a clear
indication of an error.)
Cheers,
Daniel
>
> Can svn:// with SASL do
> it? It might be possible to extend SASL, but I think this would involve
> client and server changes.
Received on 2015-11-20 04:08:32 CET