On 9/15/2013 11:32 AM, Dan White wrote:
The issue is that the client end of the transaction is in a DMZ
A connection from a DMZ to one’s internal network is a very high
security risk. What I was hoping for was a way to define a very
specific connection from the Subversion server to the DMZ client
(push). This is considered to be a much lower security risk.
One way to handle this is to use SSH to access the specific SVN repository.
1. Use no-password SSH public-key pair that the DMZ host can punch
through to the SSH port on the internal SVN server. (Naturally, SSH
should be set to dis-allow root login, and only allow public-key
authentication.)
- If you can't change everyone over to using public keys and disabling
password based authentication for SSH, then you should run a 2nd SSHD
process on a different port and have that only allow specific accounts
to login and require public-key authentication. Then you can setup your
DMZ -> SVN server firewall to only allow access to the SVN SSH alternate
port from the DMZ.
2. Give the SSH account read-only access to the SVN repo that it needs
3. Lock down what the SSH account can do to just:
command="/usr/bin/svnserve -t -r
/var/svn",no-agent-forwarding,no-pty,no-port-forwarding,no-X11-forwarding ssh-rsa
...
Since the account will have very limited permissions on the SVN machine
(read-only access), there's not a whole lot that someone could do with
the account. Plus the use of the command= line means they'd have to
figure out a way to escape the svnserve program in order to get a
command-line on the SVN machine.
