Re: Push ?
On Mon, Sep 16, 2013 at 4:51 PM, Les Mikesell lesmikes...@gmail.com wrote: On Mon, Sep 16, 2013 at 2:53 PM, Dan White d_e_wh...@icloud.com wrote: The described solution is one we already use within our network space, but Security will not allow a connection from DMZ to the internal SVN server. It violates the whole purpose of having a DMZ in the first place. There is always the trick of ssh-ing a command from inside the firewall to the DMZ box that (a) sets up port-forwarding and (b) runs the svn command as though the repo is on localhost. Technically, and from the firewall's point of view, the connection is established outbound. This is also a firing offense in many environments. I once had a chief developer, with various root SSH key access, running just such tunnels to and from his home machine, tunnels that I happened to notice. He was also using non-passphrase protected SSH keys, and had *built* the previous version of Subversion in use at that company. Given the secure data he had access to this way, from offsite, it caused a serous scandal behind closed doors, (And I replaced that Subversion with a source controlled one, owned by root, instead of the one owned by him individually!)
Re: Push ?
On Tue, Sep 17, 2013 at 7:11 AM, Nico Kadel-Garcia nka...@gmail.com wrote: There is always the trick of ssh-ing a command from inside the firewall to the DMZ box that (a) sets up port-forwarding and (b) runs the svn command as though the repo is on localhost. Technically, and from the firewall's point of view, the connection is established outbound. This is also a firing offense in many environments. Yes, I can understand institutions and security policies that blindly outlaw tunnels, but note that in this case it goes the 'right' direction.- that is the control and connection comes from the 'more secure' side and the tunnel is just because the program that needs to run won't make its own connection in the direction you need. I once had a chief developer, with various root SSH key access, running just such tunnels to and from his home machine, tunnels that I happened to notice. He was also using non-passphrase protected SSH keys, and had *built* the previous version of Subversion in use at that company. Given the secure data he had access to this way, from offsite, it caused a serous scandal behind closed doors, (And I replaced that Subversion with a source controlled one, owned by root, instead of the one owned by him individually!) First, it is kind of foolish to assume that anyone with an unrestricted ssh login doesn't have complete access to all the data that account can read (or reach from either side of the connection), but also note that this is the opposite case, where the connection origin and tunnel destination are on the 'less secure' side and the controlling keys are also outside. -- Les Mikesell lesmikes...@gmail.com
Re: Push ?
First, it is kind of foolish to assume that anyone with an unrestricted ssh login doesn't have complete access to all the data that account can read (or reach from either side of the connection), but also note that this is the opposite case, where the connection origin and tunnel destination are on the 'less secure' side and the controlling keys are also outside. Oh, Les, this clown was doing both and all and simply treating security as something that stops me from getting my important work done. It's understandable: blindly applied policies do encourage people to simply work around them, and encourage people to work around them. Blindly applied workarounds are a similar problem. Simply setting up SSH tunnels, without some serious thought about how to keep it off the radar of the script kiddies, or keep it tied to Subversion repository mirroring alone and not abused for other purposes is one that needs serious thought. For example, a quick review of SSH daemon configurations allows one to set up an SSH daemon that is dedicated to Subversion SSH tunnels, with a restricted and forced specific SSH public key matched to the daemon that can only be used by the specific tunnel user, tied to the Subversion server's restricted access. But that takes significant extra work, and root privileges to start if the daemon is going to run on low numbered ports, and even SELinux considerations if that's enabled on either end.
RE: Push ?
Guten Tag Dan White, am Sonntag, 15. September 2013 um 17:32 schrieben Sie: Searching for a solution found one possibility: Check out a copy on the subversion server and then rsync to the final client destination. How is rsync more secure than accessing the client using SSH and use svn update? SSH has some options to limit access and possibilities. For example ForceCommand sounds interesting: http://askubuntu.com/questions/48129/how-to-create-a-restricted-ssh-user-for- port-forwarding I was hoping to find a one-step solution rather than a two step. How about polling on the client? Issueing a svn update every some seconds shouldn't hurt client and server much. This is what CI servers do... Cruise Control, Team City, Jenkins, etc. BOb
Re: Push ?
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.
Re: Push ?
The described solution is one we already use within our network space, but Security will not allow a connection from DMZ to the internal SVN server.It violates the whole purpose of having a DMZ in the first place.“Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” (Bill Waterson: Calvin Hobbes)On Sep 16, 2013, at 12:19 PM, Thomas Harold thomas-li...@nybeta.com wrote:On 9/15/2013 11:32 AM, Dan White wrote:The issue is that the client end of the transaction is in a DMZA connection from a DMZ to one’s internal network is a very highsecurity risk. What I was hoping for was a way to define a veryspecific 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.
Re: Push ?
On Mon, Sep 16, 2013 at 2:53 PM, Dan White d_e_wh...@icloud.com wrote: The described solution is one we already use within our network space, but Security will not allow a connection from DMZ to the internal SVN server. It violates the whole purpose of having a DMZ in the first place. There is always the trick of ssh-ing a command from inside the firewall to the DMZ box that (a) sets up port-forwarding and (b) runs the svn command as though the repo is on localhost. Technically, and from the firewall's point of view, the connection is established outbound. -- Les Mikesell lesmikes...@gmail.com
Re: Push ?
Guten Tag Dan White, am Sonntag, 15. September 2013 um 01:22 schrieben Sie: Is is possible to push a checkout or update from a subversion server to a remote client ? As said, there's no such mechanism in Subversion, but if you describe your problem more detailed, one can suggest workarounds. For example it shouldn't be a problem to login using ssh and initiate a client side update. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Push ?
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. Searching for a solution found one possibility: Check out a copy on the subversion server and then rsync to the final client destination. I was hoping to find a one-step solution rather than a two step. Other considerations include using svnsync to create a copy in the DMZ, but that has its own security concerns. Sadly, this is not a simple problem. On Sep 15, 2013, at 6:21 AM, Thorsten Schöning wrote: Guten Tag Dan White, am Sonntag, 15. September 2013 um 01:22 schrieben Sie: Is is possible to push a checkout or update from a subversion server to a remote client ? As said, there's no such mechanism in Subversion, but if you describe your problem more detailed, one can suggest workarounds. For example it shouldn't be a problem to login using ssh and initiate a client side update.
Re: Push ?
Guten Tag Dan White, am Sonntag, 15. September 2013 um 17:32 schrieben Sie: Searching for a solution found one possibility: Check out a copy on the subversion server and then rsync to the final client destination. How is rsync more secure than accessing the client using SSH and use svn update? SSH has some options to limit access and possibilities. For example ForceCommand sounds interesting: http://askubuntu.com/questions/48129/how-to-create-a-restricted-ssh-user-for-port-forwarding I was hoping to find a one-step solution rather than a two step. How about polling on the client? Issueing a svn update every some seconds shouldn't hurt client and server much. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: Push ?
On 15.09.2013 01:22, Dan White wrote: Is is possible to push a checkout or update from a subversion server to a remote client ? You could try svnpubsub: http://svn.apache.org/viewvc/subversion/trunk/tools/server-side/svnpubsub/ It includes a client implementation called svnwcsub which does more or less what you need. Svnpubsub is included in the Subversion 1.8.x source tarballs. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: Push ?
On Sep 14, 2013, at 18:22, Dan White wrote: Is is possible to push a checkout or update from a subversion server to a remote client ? Nope, clients must initiate updates. Servers don't keep any record of who checked out or updated what (expect possibly in logfiles).
