Philip Martin wrote on Fri, Nov 20, 2015 at 11:17:06 +0000: > Daniel Shahaf <[email protected]> writes: > > 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. > > What I want is a single authentication that only requries a key pair and > a username.
You could set up the VPN to dedicate an IP address to each user, and arrange for svnserve to only accept a particular username if the remote IP address is that user's IP address. At that point you don't need to have an ra_svn password at all, svnserve will check the username against the remote IP address, the server doesn't even need to request a password from the user. Security will rely on the VPN IP routing, not on a password. You could arrange something similar with the 'ssh -W' idea: if svnserve listened on multiple IP:port tuples, and .ssh/authorized_keys permitted each user to connect to only one of those IP:port coordinates, svnserve could derive the authenticated username from the port number the connection was accepted on, and no ra_svn-level password will be required, only an SSH key. But zooming out, what's so unreasonable about assigning two authentication secrets to each user? Such as two secret keys, or a secret key and a password that only works in conjunction with that specific key? Requiring "a single secret per user" seems like an arbitrary requirement, you gave no reason for it, theoretically it's unmodelable. What's your concern? Administrative overhead? One employee (an "inside" attacker) impersonating another employee? You mentioned SASL in your first mail but I don't understand why using keys with SASL would require code changes. Using SASL with straight svn:// would probably be easiest solution. Regarding your in-band proxy idea, one minor tweak to it would be to use SCM_CREDS / SCM_CREDENTIALS for the sideband protocol, instead of inventing a custom side protocol. For example, you could have svnserve listen on a unix socket and authorized_keys execute a setgid wrapper, one wrapper per SSH-authenticated identity. The wrapper would act like 'socat STDIO svnserves_unix_socket' and call SCM_CREDS at the right moment. Also, you didn't mention if on-the-wire encryption is a goal, or just authentication. Cheers, Daniel
