svn und port-forwarding
-
Hallo. Ich sitze an dieser Sache schon recht lange, aber irgendwie komme ich zu keinem Ergebnis:(( Ich schreibe meine Diplomarbeit an einem Lehrstuhl bei mir an der Uni. Das ganze Zeug wird in einer svn-repository aufbewahrt. Nun,möchte ich natürlich auch von zu Hause arbeiten können. Das Problem ist, dass der svn-server von der außenwelt abgeschirmt ist. Es gibt aber bei dem Lehrstuhl eine zentrale Gateway, also ein Server, der mit der Außenwelt verbunden ist. Und wenn man drauf kommt, dann kann man von diesem Server auch auf all die anderen Rechner zugreifen. Nun habe ich mir die schlaue Lösung überlegt, einfach einen Port auf meinem Rechner zu Hause auf einen Port des Subversion-Server über die Gateway zu forwarden. Was mach ich? Ich mach folgendes:
- ssh -L 10001:subversion-server:22 Gateway
- svn co svn+ssh://localhost/meineRepository:10001
Ich benutze den Port 22, das es svn+ssh ist. Hab aber auch den Standard-SVN-Port 3690 probiert. Nach dem Schritt 2) wird drei mal mein passwort abgefragt und dann kommt
Permission denied (publickey,keyboard-interactive).
svn: Netzwerkverbindung wurde unerwartet geschlossen.Dieselbe Meldung und die dreimalige Passwortabfrage kommt aber auch wenn ich mich einfach ins "nichts" verbinde.
Wüsste jemand, woran es liegen könnte? Die Admins bei uns am Lehrstuhl wissen es nicht

Gruß
Ewgenij
-
Versuch dich mal einfach per ssh einzuloggen und akzeptier den Schlüssel.
-
Ewgenijkkg schrieb:
Hallo. Ich sitze an dieser Sache schon recht lange, aber irgendwie komme ich zu keinem Ergebnis:(( Ich schreibe meine Diplomarbeit an einem Lehrstuhl bei mir an der Uni. Das ganze Zeug wird in einer svn-repository aufbewahrt. Nun,möchte ich natürlich auch von zu Hause arbeiten können. Das Problem ist, dass der svn-server von der außenwelt abgeschirmt ist. Es gibt aber bei dem Lehrstuhl eine zentrale Gateway, also ein Server, der mit der Außenwelt verbunden ist. Und wenn man drauf kommt, dann kann man von diesem Server auch auf all die anderen Rechner zugreifen. Nun habe ich mir die schlaue Lösung überlegt, einfach einen Port auf meinem Rechner zu Hause auf einen Port des Subversion-Server über die Gateway zu forwarden. Was mach ich? Ich mach folgendes:
- ssh -L 10001:subversion-server:22 Gateway
- svn co svn+ssh://localhost/meineRepository:10001
Ich benutze den Port 22, das es svn+ssh ist. Hab aber auch den Standard-SVN-Port 3690 probiert. Nach dem Schritt 2) wird drei mal mein passwort abgefragt und dann kommt
Permission denied (publickey,keyboard-interactive).
svn: Netzwerkverbindung wurde unerwartet geschlossen.Dieselbe Meldung und die dreimalige Passwortabfrage kommt aber auch wenn ich mich einfach ins "nichts" verbinde.
Wüsste jemand, woran es liegen könnte? Die Admins bei uns am Lehrstuhl wissen es nicht

Ich verstehe den ganzen Aufwand grade nicht? Wenn ssh des Subversion-Servers die Repositories über SSH erreichbar hält, dann greif doch einfach drauf zu:
svn checkout svn+ssh://subversion-server/PFAD_ZU_DEINEM_REPOSITORY_VOM_WURZELVERZEICHNIS_AUS_GESEHEN/meinRepository
Anschließend solltest Du mit Deinem Passwort darauf zugreifen können.
Permission denied könnte allerdings auch darauf hindeuten, dass Du keine Zugriffsrechte hast. Kann es sein, dass Dein Login auf Deinem Heimrechner nicht dem Login auf dem SVN-Server entspricht?
Ich weiß nicht, ob in Deinem Beispiel ein korrekter Pfad angegeben wurde. Wenn nicht, wird die Verbindung gekappt.
Auf dem Subversion-Server der SVN-Server läuft, musst Du auf den Server-Port zugreifen, also per Default 3690, bzw. diesen über das Gateway forwarden und entsprechend auf das Gateway zugreifen.
-
Bitte nächstes mal ins richtige Forum, danke.
-
Dieser Thread wurde von Moderator/in nman aus dem Forum Linux/Unix in das Forum Themen rund um den PC verschoben.
Im Zweifelsfall bitte auch folgende Hinweise beachten:
C/C++ Forum :: FAQ - Sonstiges :: Wohin mit meiner Frage?Dieses Posting wurde automatisch erzeugt.
-
.filmor schrieb:
Versuch dich mal einfach per ssh einzuloggen und akzeptier den Schlüssel.
Wo einloggen?
-
Ich verstehe den ganzen Aufwand grade nicht? Wenn ssh des Subversion-Servers die Repositories über SSH erreichbar hält, dann greif doch einfach drauf zu:
Ne, so einfach ist es nicht
Der Versionierungsserver ist von außen nicht erreichbar! Ich kann nicht direkt von zu Hause darauf zugreifen. Ich kann mich nur zuerst auf dem gateway-Server einloggen, und erst von da aus, auf den Versionierungsserver zugreifen.Permission denied könnte allerdings auch darauf hindeuten, dass Du keine Zugriffsrechte hast. Kann es sein, dass Dein Login auf Deinem Heimrechner nicht dem Login auf dem SVN-Server entspricht?
Nee, das ist genau derselbe login.
Ich weiß nicht, ob in Deinem Beispiel ein korrekter Pfad angegeben wurde. Wenn nicht, wird die Verbindung gekappt.
Den Pfad habe ich ermittelt, indem ich auf dem lehrstuhlinternen Rechner svn info ausgeführt habe. Das müsste also der richtige Pfad sein.
Auf dem Subversion-Server der SVN-Server läuft, musst Du auf den Server-Port zugreifen, also per Default 3690, bzw. diesen über das Gateway forwarden und entsprechend auf das Gateway zugreifen.
Ich hab auch versucht 3690 zu forwarden - Pustekuchen, klappt trotzdem nicht. Kann es sein, dass die admins die Portforwarding zu dem svn-Server gesperrt haben? Oder sonst irgendwelche Einstellungen geblockt sind?
-
Ewgenijkkg schrieb:
Ich verstehe den ganzen Aufwand grade nicht? Wenn ssh des Subversion-Servers die Repositories über SSH erreichbar hält, dann greif doch einfach drauf zu:
Ne, so einfach ist es nicht
Der Versionierungsserver ist von außen nicht erreichbar! Ich kann nicht direkt von zu Hause darauf zugreifen. Ich kann mich nur zuerst auf dem gateway-Server einloggen, und erst von da aus, auf den Versionierungsserver zugreifen.]Okay, dann bringt es Dir aber auch nichts, den SSH-Port des Gateways zu forwarden und dann auf das Gateway SVN zu tunneln. Du würdest ja dann versuchen das Gateway als SVN-Server zu nutzen - dort finden sich Deine Daten ja nicht.
Also muss das Gateway wissen, was Du von ihm willst.
Das Gateway muss also Deine Anfrage zum SVN-Server forwarden - nicht localhost zum Gateway.
Der Admin des Gateways müsste also entweder die Struktur des Repository-Servers ins Gateway einbinden, z.B. per NFS, so dass die Anfragen vom Gateway lokal bearbeitet werden können oder die entsprechenden Ports zum SVN-Server weiterleiten.
Dir werden da die Rechte fehlen.Ewgenijkkg schrieb:
Ich hab auch versucht 3690 zu forwarden - Pustekuchen, klappt trotzdem nicht. Kann es sein, dass die admins die Portforwarding zu dem svn-Server gesperrt haben? Oder sonst irgendwelche Einstellungen geblockt sind?
Du musst auf dem Gateway die Ports forwarden, dazu werden Dir vermutlich (für die Admins hoffentlich) die Rechte fehlen. Also könntest Du einen SSH-Tunnel auf dem Gateway versuchen, auf den SSH bzw. SVN Port des SVN-Servers und schließlich von Deinem Rechner auf den getunnelten Port des Gateways auschecken.
Ansonsten check auf das Gateway aus, dann hast Du die Arbeitskopie auf dem Gateway. Kopier sie auf Deinen Rechner und schieb sie zum Einchecken wieder auf's Gateway. Umständlich, aber besser umständlich als zwei Stunden rumprobieren, bis die Admins das Problem für Dich lösen.
-
wenn du portforwarding gemacht hast, brauchst du nicht mehr svn+ssh machen, sondern nur noch svn. die verbindung geht ueber die SSH verbindung und ist damit sicher. du musst natuerlich den localhost port angeben den du geforwardet hast.
-
Ewgenijkkg schrieb:
.filmor schrieb:
Versuch dich mal einfach per ssh einzuloggen und akzeptier den Schlüssel.
Wo einloggen?
Auf dem Server, der per svn+ssh angefunkt werden soll. Ich meine, ich hätte den Fehler "Permission denied (publickey,keyboard-interactive)" schonmal in diesem Zusammenhang gesehen.
Das Problem wäre dann, dass das "abnicken" des öffentlichen Schlüssels eben die Eingabe von "yes" bei der entsprechenden Frage erfordert, was zumindest bei mir svn nicht von sich aus gemacht hat.
-
.filmor schrieb:
Ewgenijkkg schrieb:
.filmor schrieb:
Versuch dich mal einfach per ssh einzuloggen und akzeptier den Schlüssel.
Wo einloggen?
Auf dem Server, der per svn+ssh angefunkt werden soll. Ich meine, ich hätte den Fehler "Permission denied (publickey,keyboard-interactive)" schonmal in diesem Zusammenhang gesehen.
Das Problem wäre dann, dass das "abnicken" des öffentlichen Schlüssels eben die Eingabe von "yes" bei der entsprechenden Frage erfordert, was zumindest bei mir svn nicht von sich aus gemacht hat.Die Frage wird an den User durchgereicht. Wenn er den Befehl auf der Konsole eingibt, wird er gefragt, ob er den Key akzeptieren möchte.
-
Okay, dann bringt es Dir aber auch nichts, den SSH-Port des Gateways zu forwarden und dann auf das Gateway SVN zu tunneln. Du würdest ja dann versuchen das Gateway als SVN-Server zu nutzen - dort finden sich Deine Daten ja nicht.
Tue ich ja auch nicht
Ich tunnele ja meinen eigenen Port auf localhost auf den SVN-Port des Versionierungsservers ÜBER das Gateway-Server!Das Gateway muss also Deine Anfrage zum SVN-Server forwarden - nicht localhost zum Gateway.
Das müsste doch schon durch ssh -L 10001:subversion-server:22 Gateway oder ssh -L 10001:subversion-server:3690 Gateway gewährleistet sein, oder?
Der Admin des Gateways müsste also entweder die Struktur des Repository-Servers ins Gateway einbinden, z.B. per NFS, so dass die Anfragen vom Gateway lokal bearbeitet werden können oder die entsprechenden Ports zum SVN-Server weiterleiten.
Dir werden da die Rechte fehlen.Hmm, also irgendwie verstehe ich das nicht. Mit dem SSH-Befehl sage ich doch dem SSH, der soll alles, was auf dem Port 22 oder 3690 von localhost ankommt über das Gateway zum Versionierungsserver schicken. Für den Versionierungsserver sollte es doch Wurscht sein, woher genau die Daten kommen. Für den kommen sie vom Gateway, oder?
Ansonsten check auf das Gateway aus, dann hast Du die Arbeitskopie auf dem Gateway. Kopier sie auf Deinen Rechner und schieb sie zum Einchecken wieder auf's Gateway.
Sowas mach ich schon seit ein paar Monaten:) Aber ich wollte einfach mal klären, warum es auf eine vernünftige Art und Weise nicht geht.
-
.filmor schrieb:
Ewgenijkkg schrieb:
.filmor schrieb:
Versuch dich mal einfach per ssh einzuloggen und akzeptier den Schlüssel.
Wo einloggen?
Auf dem Server, der per svn+ssh angefunkt werden soll. Ich meine, ich hätte den Fehler "Permission denied (publickey,keyboard-interactive)" schonmal in diesem Zusammenhang gesehen.
Das Problem wäre dann, dass das "abnicken" des öffentlichen Schlüssels eben die Eingabe von "yes" bei der entsprechenden Frage erfordert, was zumindest bei mir svn nicht von sich aus gemacht hat.Hi, also ich kann mich problemlos vom Gateway-Server auf dem Versionierungsserver einloggen. Da wird alles akzeptiert.
-
Hi, bitte schreib bei den Zitaten dabei, auf wen Du Dich beziehst.
Ewgenijkkg schrieb:
Okay, dann bringt es Dir aber auch nichts, den SSH-Port des Gateways zu forwarden und dann auf das Gateway SVN zu tunneln. Du würdest ja dann versuchen das Gateway als SVN-Server zu nutzen - dort finden sich Deine Daten ja nicht.
Tue ich ja auch nicht
Ich tunnele ja meinen eigenen Port auf localhost auf den SVN-Port des Versionierungsservers ÜBER das Gateway-Server!Weiß das Gateway das?

Wenn ich das richtig sehe, dann erzeugst Du einen Tunnel von Deinem Rechner zum einer nicht existierenden Internet-IP, was darin endet, dass kein Gateway bemüht wird.
Dein Problem ist ja, dass Du am Gateway nicht vorbei kommst und ein Tunnel nach irgendwo kommt auch nicht am Gateway vorbei.Ewgenijkkg schrieb:
Das Gateway muss also Deine Anfrage zum SVN-Server forwarden - nicht localhost zum Gateway.
Das müsste doch schon durch ssh -L 10001:subversion-server:22 Gateway oder ssh -L 10001:subversion-server:3690 Gateway gewährleistet sein, oder?
Wenn subversion-server von Dir aus nicht per SVN erreichbar ist - weil das Gateway dazwischen steht - wo geht dann der Tunnel hin?
Kannst Du den SVN-Server pingen? Oder Dich (ohne den Umweg über das Gateway) dort irgendwie einloggen?
Ewgenijkkg schrieb:
Der Admin des Gateways müsste also entweder die Struktur des Repository-Servers ins Gateway einbinden, z.B. per NFS, so dass die Anfragen vom Gateway lokal bearbeitet werden können oder die entsprechenden Ports zum SVN-Server weiterleiten.
Dir werden da die Rechte fehlen.Hmm, also irgendwie verstehe ich das nicht. Mit dem SSH-Befehl sage ich doch dem SSH, der soll alles, was auf dem Port 22 oder 3690 von localhost ankommt über das Gateway zum Versionierungsserver schicken. Für den Versionierungsserver sollte es doch Wurscht sein, woher genau die Daten kommen. Für den kommen sie vom Gateway, oder?
Nur wenn das Gateway Deine Daten auch weiterleitet und aus Deiner Erklärung habe ich bisher nicht gesehen, dass es das tuen sollte.
Ewgenijkkg schrieb:
Ansonsten check auf das Gateway aus, dann hast Du die Arbeitskopie auf dem Gateway. Kopier sie auf Deinen Rechner und schieb sie zum Einchecken wieder auf's Gateway.
Sowas mach ich schon seit ein paar Monaten:) Aber ich wollte einfach mal klären, warum es auf eine vernünftige Art und Weise nicht geht.
Aus Deinen bisherigen Erklärungen gehe ich davon aus, dass Du Deinem Rechner beibringst, einen Port zum SVN-Server zu tunneln, welcher aber nicht erreichbar ist, sonst wäre ja das Gateway überflüssig. (Die IP Adresse des SVN-Servers ist vermutlich 192.168.x.y? zwischen 172.16.x.y bis 172.31.x.y oder 10.x.y.z?)
Erstellst Du den Tunnel zum Gateway, funktioniert das immernoch nicht:
Der SVN-Port wird vom Gateway nicht weitergeleitet und ist geschlossen: Das Gateway reagiert also nicht.
Der SSH Port ist offen, der es wird ein SSH-Tunnel zum Gateway erzeugt. Nun greifst du mit SVN per ssh+svn auf Deinen Tunnel zu, das wird zum Gateway übertragen und damit forderst Du das Gateway auf, Dir SVN-Dienste zur Verfügung zu stellen. Das Gateway kennt Dein Repository aber nicht.
Das Repository müsste also entweder dem Gateway bekannt sein (z.B. per NFS) oder das Gateway müsste wissen, dass Du zum SVN-Server willst.Du erzeugst einen Tunnel zu einem Ziel (Gateway), dass Du ungetunnelt genauso gut erreichen kannst, bzw den SVN-Server, den Du nicht erreichen kannst, weil das Internet nicht weiß, dass es dafür durch das Gateway muss.
Du möchtest aber eigentlich einen Tunnel durch das Gateway erzeugen.Also erzeuge den Tunnel auf dem Gateway (nicht auf Deinem Rechner), das damit den Zugriff auf den SVN Server über die (erreichbare) GatewayIP erlaubt.
Auf Deinem Rechner holst Du nun das Repository von gateway:tunnelport ab. Das Gateway wirft Deine Anfrage in den Tunnel, der zum SVN-Server führt und dort bearbeitet geführt wird.Wenn Du Dich per SSH auf dem Gateway einloggst, bist Du selbst der Tunnel. Das Gateway hat ja den Zweck, zwischen zwei Netzen (hier Internet und Intranet) zu vermitteln. Du kannst auf den Intranet-SVN-Server zugreifen, aber auch direkt auf das Internet. Im Intranet werden die Anfragen von Dir unbemerkt ans Gateway weitergeleitet und vom Internet (wo Du in diesem Fall herkommst) kann der Intranet-SVN-Server nicht gesehen werden.
Deine Lösung funktioniert nur, wenn Du Dich ohne Umweg des Gateways auf den SVN-Server einloggen kannst und in dem Fall wäre der Tunnel nicht erforderlich. Also auf dem Gateway den Tunnel einrichten und das Repository vom Gateway anfragen.
-
Weiß das Gateway das?

Wenn ich das richtig sehe, dann erzeugst Du einen Tunnel von Deinem Rechner zum einer nicht existierenden Internet-IP, was darin endet, dass kein Gateway bemüht wird.
Dein Problem ist ja, dass Du am Gateway nicht vorbei kommst und ein Tunnel nach irgendwo kommt auch nicht am Gateway vorbei.Also im ssh manual steht:
-L [bind_address:]port:host:hostport
Specifies that the given port on the local (client) host is to be
forwarded to the given host and port on the remote side. This
works by allocating a socket to listen to port on the local side,
optionally bound to the specified bind_address. Whenever a con-
nection is made to this port, the connection is forwarded over
the secure channel, and a connection is made to host port
hostport from the remote machine. Port forwardings can also be
specified in the configuration file. IPv6 addresses can be spec-
ified with an alternative syntax: [bind_address/]port/host/host-
port or by enclosing the address in square brackets. Only the
superuser can forward privileged ports. By default, the local
port is bound in accordance with the GatewayPorts setting. How-
ever, an explicit bind_address may be used to bind the connection
to a specific address. The bind_address of ``localhost'' indi-
cates that the listening port be bound for local use only, while
an empty address or `*' indicates that the port should be avail-
able from all interfaces.Das heisst doch, dass mit ssh -L 10001:subversion-server:22 Gateway mein locales Port 10001 über das Gateway auf subversion-server geforwarded wird. Für das Gateway ist ja der SVN-Port durchaus erreichbar, deswegen tunnele ich ja auch über das Gateway. Also die Daten laufen zum Gateway und Gateway schickt sie zum spezifizierten Port des SVN-Servers. Das ist doch der ganze Sinn vom Tunneln, dass ich etwas, was so nicht erreichbar ist, über einen Tunnel erreiche.
Specifies that the given port on the local (client) host is to be
forwarded to the given host and port on the remote side. This
works by allocating a socket to listen to port on the local side,
optionally bound to the specified bind_address. Whenever a con-
nection is made to this port, the connection is forwarded over
the secure channel, and a connection is made to host port
hostport from the remote machineheisst doch genau das. Also der locale Port wird zum Gateway geleitet, und von da aus zu der remote side, also zum SVN-Server. So verstehe ich diesen Absatz. Du meinst, ich verstehe ihn falsch?
-
Hi,
du brauchst 2 Shells.Shell 1:
ssh -L 7777:localhost:443 dein.host.de(brav user/pass eingeben)
Shell 2:
svn co https://localhost:7777/dein/repository(einfach ganz normal auschecken, so wie du normalerweise auschecken wuerdest)
-
Korbinian schrieb:
Shell 1:
ssh -L 7777:localhost:443 dein.host.de(brav user/pass eingeben)
Bei mir funktioniert das, wenn ich localhost durch die IP des SVN-Servers ersetze. localhost ist ja das Gateway, aber auf dem läuft SVN doch nicht.
7777 ist das eine Tunnelportal und <host>:443 das andere, das Gateway ist der Berg. Will ich zum SVN-Server tunneln, muß dort also stehen: -L 7777:<SVN-Server>:<SVN-Port> <Gateway>
Oder?