Wissen

Benutzer-Werkzeuge

Webseiten-Werkzeuge

Sie befinden sich hier: Start » ssh-tunnel
Zuletzt angesehen: • security_key • ffmpeg • iptables • mysql-dump • zfs
ssh-tunnel

Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

Link zu dieser Vergleichsansicht

Beide Seiten der vorigen RevisionVorhergehende Überarbeitung
Nächste Überarbeitung		Vorhergehende Überarbeitung
ssh-tunnel [2018-06-25 12:11:30] – [ssh-Tunnel HOWTO] manfredssh-tunnel [2018-06-25 14:50:55] (aktuell) – [Remote port forwarding] manfred
Zeile 1: Zeile 1:
 +====== SSH-Tunnel ======
 +
 +
 +===== ssh-Tunnel HOWTO =====
 +
 +  * [[https://ssh-tunnel.de/ssh-tunnel-mit-linux/]]
 +
 +Dieses HOWTO beschreibt, wie man einen SSH-Tunnel über ein Gateway zum Zielrechner aufbaut um zum Beispiel SVN darüber laufen zu lassen. Das Verfahren wird manchmal auch "port forwarding" genannt.
 +
 +Angenommen ein SVN-Repository war früher im Internet via HTTPS erreichbar, doch der Betreiber entschied sich dazu nur noch anfragen aus dem (entfernten) Netzwerk zuzulassen. Wenn man sich nicht bereits in diesem Netz befindet würde man sich üblicherweise per VPN ins entfernte Netz einfwählen und wie gewohnt weiterarbeiten. Möchte man allerdings nicht extra für einen Dienst ein VPN betreten, kann man diesen Dienst auch über SSH tunneln.
 +
 +
 +==== Tunnel aufbauen ====
 +
 +Das Kommando
 +  # ssh -4L lokalerport:zielrechner:zielport gatewaylogin@gateway
 +
 +erzeugt nach erfolgreichem login auf dem Rechner "gateway", einen Tunnel.
 +Alle Anfragen an Port "lokalerport" auf dem lokalen Rechner, werden nun über den Rechner "gateway" zum "Zielrechner" an den "Zielport" geleitet.
 +
 +In dem folgenden Beispiel leiten wir alle Anfragen vom lokalen Port 7777 über den Rechner "gateway" (zu dem müssen wir natürlich SSH-Zugang haben und er muss sich im selben Netz wie der "svnserver" befindet) an den Port 443 des Rechners "svnserver" weiter:
 +  # ssh -4L 7777:svnserver:443 user@gateway
 +
 +Nun ist man per SSH auf dem Rechner "gateway" eingeloggt und der Tunnel besteht solange bis man sich wieder ausloggt.
 +Soll die Verbindung automatisch aufgebaut werden, dann kann man das z.B. mit dem Programm ''screen'' bewerkstelligen:
 +  # screen -dmS sshtunnel ssh -4L 7777:svnserver:443 user@gateway
 +
 +
 +==== SVN-Arbeitskopie anpassen ====
 +
 +Da der "svnserver" jetzt nicht mehr über "https://svnserver/", sondern über "https://localhost:7777/" erreichbar ist, müssen bereits vorhandene Arbeitskopien (SVN) natürlich angepasst werden. Dazu wechselt man ins Verzeichnis der Arbeitskopie und "schaltet" von der alten URL auf die neue um:
 +  # svn switch --relocate https://svnserver/pfad/zu/repo https://localhost:7777/pfad/zu/repo
 +
 +Ein anschließendes
 +  # svn up
 +
 +Sollte nach ein paar eventuellen Fragen über den "neuen" Host die Arbeitskopie aktualisieren.
 +
 +
 +===== Port forwarding =====
 +
 +  * [[http://www.jfranken.de/homepages/johannes/vortraege/ssh2_inhalt.de.html#ToC9]]
 +
 +
 +==== Local port forwarding ====
 +
 +Wenn ich auf dem Rechner "hamster" das Kommando
 +  # ssh -g4L 4321:heise.de:80 gate
 +
 +aufrufe, dann baut SSH eine Verbindung zum Rechner "gate" auf und lauscht währenddessen auf dem Rechner "hamster:4321" und reicht alle dort ankommenden TCP-Verbindungen an den SSHD auf dem Rechner "gate" weiter, der sie an den Port 80 von "heise.de" weiterleitet.
 +Der Rückweg funktioniert entsprechend.
 +
 +Der Aufruf von "http://hamster:4321" sollte dann also genauso aussehen wie der Aufruf "http://heise.de".
 +
 +Man muss auf "hamster" Rootrechte haben, wenn man einen lokalen Port (kleiner als 1024) öffnen möchte.
 +
 +Wenn man den Parameter ''-g'' weglässt, dann funktioniert nur der Aufruf "http://lokalhost:4321".
 +Sie müssen dann also auf dem selben Rechner sein, wie der SSH-Client, oder aus einem anderen Tunnel dorthin umsteigen.
 +
 +Sollen die Benutzer auf dem SSHD-Rechner keinen Shellzugriff, sondern nur Portforwarding können, kann man zunächst in der /etc/ssh/sshd_config die Option //PasswordAuthentication=no// setzen und dann für jeden betreffenden Publickey in der //~/.ssh/authorized_keys// am Zeilenanfang einen Aufruf wie //command="/bin/cat"// oder //command="sleep 2000d"// einfügen.
 +
 +Wer zusätzlich einen keepalive einbauen möchte, damit die Natting-Tabelle der Firewall im Leerlauf die Tunnels nicht kappt, schreibt an den Beginn der Publickeyzeilen jeweils:
 +  command="while :;do date;sleep 10;done"
 +
 +Um die möglichen Portforwoarding-Ziele zu beschränken, kann man eine Liste von //permitopen//-Optionen vor den jeweiligen Publickeys einfügen,
 +z.B.:
 +  permitopen="192.168.42.5:80",permitopen="127.0.0.1:8080"
 +
 +
 +==== Remote port forwarding ====
 +
 +Wenn ich auf "hamster" das Kommando
 +  > ssh -R 9030:intranet:80 gate
 +
 +eingebe, dann nimmt SSHD auf "gate" die Verbindung entgegen, lauscht auf Port 9030 und reicht alle dort ankommenden Verbindungen an den ssh-Client auf "hamster" weiter, der sie auf den Port 80 von "intranet" weiterleitet.
 +Der Rückweg funktioniert entsprechend.
 +Somit haben wir einen Tunnel von ''gate:9030'' nach ''intranet:80'' gelegt.
 +
 +Wer im Browser "http://gate:9030" aufruft, landet auf dem Intranetserver.
 +
 +Man muss auf "gate" Rootrechte haben, wenn man remote Ports <1024 öffnen möchte.
 +Wer den Rootzugriff per SSH nicht erlauben möchte, kann den SSH-Tunnel auf einen hohen Port (z.B. 9030) legen und (wenn nötig) mit xinetd, netcat oder Firewallregeln auf Port 80 umleiten.
 +
 +Dies leisten folgende:
 +  # vi /etc/inetd.conf
 +  
 +  80  stream tcp nowait nobody /bin/nc /bin/nc -w 3 localhost 9030
 +
 +oder
 +
 +  # vi /etc/xinetd.d/intranet
 +  
 +  service intranet
 +  {
 +          type            = UNLISTED
 +          flags           = REUSE
 +          socket_type     = stream
 +          protocol        = tcp
 +          user            = root
 +          wait            = no
 +          instances       = UNLIMITED
 +          port            = 80
 +          redirect        = localhost 9030
 +          disable         = no
 +  }
 +
 +oder ein Firewallscript:
 +
 +  # echo 1 > /proc/sys/net/ipv4/ip_forward # turns on forwarding
 +  iptables -F -t nat # Flush existing translation tables
 +  iptables -t nat -A PREROUTING -p tcp --dport 9030 -j DNAT --to localhost:80
 +  iptables -t nat -A POSTROUTING -j MASQUERADE
 +
 +Der SSHD bindet die remote Tunnel in seiner Standardkonfiguration an das loopback-Interface; er nimmt also nur Verbindungen von localhost entgegen.
 +Wer möchte, dass seine Tunnel auf allen Netzinterfaces erreichbar sind, trage in der ''/etc/ssh/sshd_config'' auf dem Rechner "gate" die Zeile ''GatewayPorts yes'' ein oder leite den Port wie oben beschrieben mit SSH oder xinetd um.
 +