On Wed, Mar 14, 2012 at 10:13 AM, Ulrich Eckhardt <
ulrich.eckhardt_at_dominolaser.com> wrote:
> Am 13.03.2012 11:14, schrieb Ruslan QuAzI:
>
> How can I use via SSH something like this svn co
>> svn+ssh://svn.mainhost.org:**8890/project/trunk<http://svn.mainhost.org:8890/project/trunk>I need sources from
>> svn://svn.mainhost.org:8890/**project/trunk<http://svn.mainhost.org:8890/project/trunk>(svnserve -t with local
>> path not have privileges) Both ssh and svn have non standard ports.
>> For ssh I change my ~/.ssh/config but how tweak svn to use network
>> connection instead svnserve -t ? Can't use "ssh -L" in parallel of
>> sync (sync started from software)
>>
>
> Passwords in clear text are always a problem, and svnserve is *not*
encrypted by default.
Do go look at the Subversin "Red Book" for guidelines. I'm one of the big
proponents of svn+ssh over HTTPS access, because it does not store
passwords in clear text. It usually uses SSH keys, and the "svnserver" and
URL's reflect using a common Subversion user account, typically "svn".
> It's a bit unclear what you have and what you want, so let me summarize
> what I understand:
> 1. You have a host running svnserve on port 8890.
> 2. You want to connect to that host using SSH and from there access the
> repository.
>
> Actually, the first question is why you want the SSH in between, but I
> guess that the simple reason is that the sources there are private and the
> svnserve isn't accessible from the outside.
>
> Now, using svn+ssh means using SSH to run svnserve on the remote host
> (with the current user's privileges) and then tunneling the traffic between
> svnserve's stdout and the local SVN client. However, this doesn't work
> because your user account on the remote machine doesn't have access rights
> to the files that make up the repository.
>
> There are two ways around this:
> 1. Get the access rights. This is not a good solution, as direct file
> access means anyone getting into your account can delete the whole
> repository.
> 2. You can use SSH to tunnel traffic between your local machine and the
> remote machine for some port, e.g. 12345. This means that you then check
> out and commit to svn://localhost:12345/project/**trunk. No tweaks to SVN
> are involved then.
>
>
> I could imagine that the SVN manual also mentions this approach, as it is
> the first approach for any service access when you only have a generic SSH
> access, not just for Subversion.
>
> I do sometimes with that the SVN manual listed the complex example
*first*, so people knew the right way to do it. The shared "svn" user
usually has a $HOME/.ssh/authorized_keys file se tup with restricted
command arguments to the SSH keys, setting the "user" for the svnserve
daemon that is being tunneled. The whole thing is kind of funky to manage,
but it's workable.
>
> Good luck!
>
> Uli
> ****************************************************************
> **************************
> Domino Laser GmbH, Fangdieckstraße 75a, 22547 Hamburg, Deutschland
> Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
> ****************************************************************
> **************************
> Visit our website at http://www.dominolaser.com
> ****************************************************************
> **************************
> Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten
> bestimmt und kann vertrauliche Informationen enthalten. Bitte
> benachrichtigen Sie den Absender umgehend, falls Sie nicht der
> beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu
> löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder
> anderweitig benutzt werden.
> E-Mails können durch Dritte gelesen werden und Viren sowie
> nichtautorisierte Änderungen enthalten. Domino Laser GmbH ist für diese
> Folgen nicht verantwortlich.
> ****************************************************************
> **************************
>
>
Received on 2012-03-15 01:38:41 CET