Florian Pose wrote:
> I noticed that Subversion treats SSH-tunneled connections as
> "authenticated" and sets the user name in the logs correctly. If I
> connect to the repository via local- or svnserve-access, the connection
> is treated as "unauthenticated" by default.
That is because subversion doesn't even know you are connected remotely
with the ssh tunnel. SSH logs in to the server, and invokes subversion
just as if you were logged on locally at the server. The server doesn't
handle any part of the login. When you run svnserve, it is listening
for connections and it must authenticate the user.
> I inferred, that the tunneled access gets a special treatment. I just
> wondered how this is done and if it can be done similarly in non-SSH
> When there is no need for the strong encryption SSH provides, why then
> burden the server with the extra load?
I think this is another case of wrong optimization. Optimize the
bottleneck first. Unless you have done some profiling and know that ssh
is chewing up a lot of time, then you are barking up the wrong tree.
I'll bet money that the extra cpu overhead that ssh adds is negligible,
but the only way to know for sure is to profile it.
>> You can use https instead and authenticate with a client certificate,
>> but AFAIK, there isn't anything like ssh-agent for SSL certificates, so
>> either the user will have to enter their password each time to decrypt
>> their certificate, or store the certificate on disk unencrypted, which
>> isn't good for security since anyone who manages to read that file can
>> impersonate the user.
> Since the repository is used only in the intranet (or from outside
> through VPN), the Apache solution is not really interesting for me.
Why not? It does what you need, so what's the fact that you're only
using it on a local network got to do with it? Also it frees you from
having to use the kludgey VPN junk to access the repository securely
from anywhere in the world.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Thu Mar 9 21:32:12 2006