Zum Inhalt springen

SSH/Gateway: Unterschied zwischen den Versionen

Aus Foxwiki
Versionsgeschichte interaktiv durchsuchen
← Zum vorherigen Versionsunterschied
VisuellWikitext
Keine Bearbeitungszusammenfassung
 
(316 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 1: Zeile 1:
Support-Zugriff über SSH-Tunnel-Gateway
'''SSH-Gateway''' - vermittelt verschlüsselte Tunnelverbindungen zwischen SSH-Clients


= Beschreibung =
== Beschreibung ==
Eigenschaften dieser Lösung
; Teilnehmer bauen aktiv einen Tunnel zum Gateway auf
* Keine Anpassungen an Firewall auf Client-Seiten erforderlich
* Keine Portweiterleitungen erforderlich
* Alle Clients baut aktiv einen SSH-Tunnel zu einem Gateway auf
* Keine Namensauflösung der Teilnehmer erforderlich
* Supporter baut auch einen SSH-Tunnel zum Gateway auf und hat darüber Zugriff auf das Zielsystem
; Gateway vermittelt den Kontakt
* Gateway ist ein SSH-Server im Internet
; Trennung verschiedener Kunden/Dienstleiter
* Je Tunnel (Kombination aus Kunde/Dienstleiter) ein Zugang


'''Gateway'''
; Szenario
{| class="wikitable sortable"
! Hostname !! Username
|-
| gateway.foxtom.de || sshTnlKunde001
|-
| kunde001 || support
|-
| support || user
|}


Als Gateway dient ein SSH-Server im Internet
== Gateway ==
* Hostname: gateway.foxtom.de
=== Kunden-Zugang ===
* Username: sshtunnel
==== Tunnel-Benutzerkonto ====
'''Kundenrechner'''
'''root@gateway#''' useradd --create-home --groups users --shell /bin/bash --comment "Tunnel-User Kunden001" sshTnlKunde001
* Hostname: kunde01.foxtom.de
<!-- Ist ein Loginshell notwendig?, Ist die Gruppe users erforderlich? -->
* Username: support


= Gateway =
==== Passwort vergeben ====
== Tunnel-User ==
  '''root@gateway#''' passwd sshTnlKunde001
Erstellen des Accounts für den Tunnelaufbau
'''root@gateway#''' useradd --create-home --groups users --shell /bin/bash sshtunnel
Passwort vergeben
  '''root@gateway#''' passwd sshtunnel
  New password:
  New password:
  Retype new password:
  Retype new password:
  passwd: password updated successfully
  passwd: password updated successfully
Passwort-Zugang testen
'''user@support#''' ssh sshtunnel@gateway.foxtom.de
sshtunnel@gateway.foxtom.de's password:
'''sshtunnel@mx10:~$''' exit
Public-Key übertragen
'''user@support#''' ssh-copy-id sshtunnel@gateway.foxtom.de


Public-Key-Zugang testen
==== Zugang testen ====
  '''user@support#''' ssh sshtunnel@gateway.foxtom.de
  '''user@support#''' ssh -p22 sshTnlKunde001@gateway.foxtom.de
  sshtunnel@gateway.foxtom.de's password:
  sshTnlKunde001@gateway's password:
'''sshtunnel@mx10:~$''' exit


Passwort-Zugang sperren
=== SSH-Server ===
'''root@gateway#''' passwd --lock sshtunnel
; UNIX Sockets
Damit sich Kunden nicht mit dem System eines anderen Kunden verbinden können, werden hier UNIX Sockets verwandt.
* Diese besitzen im Gegensatz zu TCP-Ports eine Zugriffssteuerung


== Nutzergruppen ==
Damit der Socket beim Abbau des Tunnels eine neue Socket-Datei erstellt wird, wird die Konfiguration des SSH-Dienstes ergänzt
* Sollen auf dem Gateway verschiedene Nutzergruppen mit Zugriff auf unterschiedliche Zielsystem existieren (mehrere Kunden, verschiedene Dienstleister oder ähnliche Szenarien), empfiehlt es sich, für jede Kombination aus Supportern und Zielsystemen einen eigenen Tunnelnutzer anzulegen:
* ein erneuter Aufbau des Tunnels ist ansonsten mit dem gleichen Socket-Namen nicht möglich


'''root@gateway#''' useradd --create-home --groups users --shell /bin/bash --comment "Tunnel-User Kunden001" ssh-kunde001
''/etc/ssh/sshd_config''
'''root@gateway#''' passwd --lock ssh-kunde001
  # Specifies whether to remove an existing Unix-domain socket file for local or remote port forwarding before creating a new one.
 
== Nutzung von UNIX Sockets ==
Das Verbinden des vom Zielsystem kommenden Tunnels mit dem des Supporters geschieht eigentlich über einen TCP-Port
* Der Supporter gibt beim Aufbau des Tunnels den gleichen Port auf dem Gateway an, den das Zielsystem für seinen Tunnel nutzt
* Da TCP-Ports über keine Zugriffssteuerung verfügen, könnte sich beim o.g. Szenario mit mehreren Nutzergruppen z.B. auch der Kunde1 mit dem SSH-Schlüssel seines Zielsystems mit dem Tunnel zum Zielsystem des Kunden2 verbinden
* Um das zu verhindern, bietet sich die Nutzung von UNIX Sockets an
* Diese sind nur für den jeweiligen Tunnel-User erreichbar.
 
Bei Nutzung von UNIX Sockets sollte die Konfiguration des SSH-Daemons wie folgt ergänzt werden:
  # Specifies whether to remove an existing Unix-domain socket file
# for local or remote port forwarding before creating a new one.
  StreamLocalBindUnlink yes
  StreamLocalBindUnlink yes


Ohne diesen Eintrag wir des Socket beim Abbau des Tunnels nicht gelöscht, wonach der Tunnel nicht wieder mit dem gleichen Socket-Namen aufgebaut werden könnte.
== Kunden-Rechner ==
 
=== Tunnel-Benutzerkonto ===
= Kunden-Rechner =
  '''root@kunde001#''' useradd -m -G users -s /bin/bash kunde001Tnl
== Tunnel-User anlegen ==
  '''root@kunde01#''' useradd -m -G users -s /bin/bash support
 
== SSH-Key erzeugen ==
Nach Login als dieser neue User wird ein SSH-Key für den Tunnel erzeugt (als Name wird im Beispiel der FQDN des Gateways genutzt, das ist aber nicht zwingend):
'''root@kunde01#''' sudo -u support -i
'''support@kunde01 ssh-keygen -f ~/.ssh/gateway.foxtom.de -t ecdsa
 
Eine Passphrase wird nicht verwendet (nur Enter drücken)
 
Der öffentliche Schlüssel muss nun auf dem Gateway der Datei ~/.ssh/authorized_keys des Tunnel-Users hinzugefügt werden
 
Auf dem Gateway wird als der dortige Tunnel-User der Schlüssel wie folgt eingefügt:
sshtunnel@gateway$ echo command=\"\",no-pty ecdsa-sha2-nistp256 \
AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBB\
GFrouMZKE6ozpWLj+xH3mONc6LWL3ZbnFbpL7sMKAjMSiTlBzek0doE\
Hrh9VvTmKce4pmHK9ilkI4ILFw7t+sk \
support@kunde01 \
>>~/.ssh/authorized_keys
 
Durch das Voranstellen von ''command="",no-pty'' kann ein User mit diesem Key auf dem Gateway kein Kommando ausführen und kein Terminal öffnen.
 
Zurück auf dem Zielsystem wird nun zum Test und zur Aufnahme als "known host" eine SSH-Verbindung zum Gateway aufgebaut:
support@kunde01$ ssh -i ~/.ssh/gateway.foxtom.de sshtunnel@gateway.foxtom.de


Nach Vergleich des angezeigten Fingerprints und Bestätigung durch Eingabe von "yes" erscheint eine Fehlermeldung "PTY allocation request failed on channel 0" und die Verbindung wird wieder abgebrochen. Das ist so gewollt.
=== SSH-Key erzeugen ===
'''root@kunde001#''' sudo -u support -i
'''support@kunde001$''' ssh-keygen -f /home/support/.ssh/gateway -t ecdsa


= Tunnelaufbau =
Keine Passphrase eingeben (Enter)
== Manueller Aufbau ==
ssh -NTC\
  -o ServerAliveInterval=60
  -o ExitOnForwardFailure=yes
  -o StrictHostKeyChecking=no\
  -i ${SSHKEY}
  -R ${GWSOCK}:localhost:${LOCALPORT}\
  ${GWUSER}@${GWHOST}


Durch den Parameter "-R" wird ein reverse Tunnel erstellt, um vom Gateway aus auf den Kundenrechner zugreifen zu können
=== Public-Key übertragen ===
'''support@kunde001$''' ssh-copy-id -p22 -i /home/support/.ssh/gateway.foxtom.de.pub sshTnlKunde001@gateway.foxtom.de


'''Variablen'''
=== Public-Key-Zugang testen ===
'''support@kunde001$''' ssh -i /home/support/.ssh/gateway.foxtom.de -p22 sshTnlKunde001@gateway.foxtom.de


'''${SSHKEY}'''
# [[SSH/Fingerprint |Fingerprint vergleichen]]
*Der komplette Pfad zum SSH-Key, z.B. ~/.ssh/gateway.foxtom.de
# Bestätigung durch Eingabe von "yes"
'''${GWSOCK}'''
Fehlermeldung "PTY allocation request failed on channel 0" und die Verbindung wird abgebrochen. Das ist beabsichtigt.
* Der Socket, welcher auf dem Gateway für den Tunnel verwendet wird
* Diesen muß man dort ansprechen, um sich mit dem Zielsystem zu verbinden
* Werden mehrere Tunnel zum Gateway aufgebaut (was recht wahrscheinlich ist), muß natürlich für jeden ein anderer Socket verwendet werden
* Ein Socket kann ein TCP- oder ein UNIX-Socket sein. Ein TCP-Socket ist einfach eine Port-Nummer
* Da zum Tunnelaufbau normale User (nicht root) genutzt werden, können dabei nur Ports über 1024 verwendet werden.Bei einem UNIX-Socket muss dessen kompletter Pfad angegeben werden, z.B. "/home/ssh-kunde1/zielsystem3.socket".
* Das darf nicht mit "~/zielsystem3.socket" abgekürzt werden
'''${LOCALPORT}'''
* Das ist der Port, mit welchem der Tunnel auf dem Zielsystem verbunden wird
* Soll über den Tunnel eine SSH-Sitzung aufgebaut werden, nimmt man den Port 22. Läuft auf dem Zielsystem ein Webserver und dieser soll über den Tunnel erreichbar sein, wird Port 443 genommen (für verschlüsselte Seiten).  
'''${GWUSER}'''
* Der User auf dem Gateway
* In unserem Beispiel also "sshtunnel" oder "ssh-kunde1".  [FIXME]
'''${GWHOST}'''
* Der Hostname des Gateways, also z.B. "gateway.foxtom.de".


== Aufbau beim Booten==
=== Automatisierung ===
Systemd-Service-Unit erstellen
==== Systemd konfigurieren ====
; Systemd-Service-Unit  


'''/etc/systemd/system/ssh-reverse@.service'''
''/etc/systemd/system/ssh-reverse@.service''
  [Unit]
  [Unit]
  Description=Reverse SSH Tunnel Service
  Description=Reverse SSH Tunnel Service
Zeile 132: Zeile 82:
  User=support
  User=support
  Environment="GWSOCK=40%I"
  Environment="GWSOCK=40%I"
  Environment="GWUSER=sshtunnel"
  Environment="GWUSER=sshTnlKunde001"
  Environment="GWHOST=gateway.foxtom.de"
  Environment="GWHOST=gateway"
  Environment="SSHKEY=/home/support/.ssh/gateway.foxtom.de"
  Environment="SSHKEY=/home/support/.ssh/gateway"
  ExecStart=/usr/bin/ssh -NTC -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i ${SSHKEY} -R ${GWSOCK}:localhost:%I ${GWUSER}@${GWHOST}
  ExecStart=/usr/bin/ssh -NTC -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i ${SSHKEY} -R ${GWSOCK}:localhost:%I ${GWUSER}@${GWHOST}
   
   
Zeile 144: Zeile 94:
  WantedBy=multi-user.target
  WantedBy=multi-user.target


Durch das @ im Namen der Unit können verschiedene Instanzen, also mehrere Tunnel erstellt werden
Durch das @ im Namen der Unit-Datei können verschiedene Instanzen (also Tunnel) erstellt werden:
* Z.B. einer für SSH und einer für HTTPS:
  '''root@kunde001#''' systemctl daemon-reload
  '''root@kunde01#''' systemctl daemon-reload
  '''root@kunde001#''' systemctl start ssh-reverse@22.service
  '''root@kunde01#''' systemctl start ssh-reverse@22.service
  '''root@kunde001#''' systemctl start ssh-reverse@443.service
  '''root@kunde01#''' systemctl start ssh-reverse@443.service


Der Port des Tunnels auf dem Gateway wird auf "40%I" gesetzt wobei %I dem Instanznamen (im Beispiel 22 und 443) entspricht
* Der Port des Tunnels auf dem Gateway wird auf "40%I" gesetzt wobei %I dem Instanznamen (hier 22 und 443) entspricht
* Im Beispiel ergibt das auf dem Gateway TCP-Sockets mit den Ports 4022 und 40443.
* Hier ergibt das auf dem Gateway TCP-Sockets mit den Ports 4022 und 40443.


Die Parameter für die einzelnen Instanzen können und sollten über Drop-In-Files angepaßt werden, z.B.:
; Parameter für Instanzen
* Drop-In-Files


'''/etc/systemd/system/ssh-reverse@22.service.d/tunnel.conf:'''
''/etc/systemd/system/ssh-reverse@22.service.d/tunnel.conf''
  [Service]
  [Service]
  # Port of the tunnel at the remote gateway
  # Port of the tunnel at the remote gateway
Zeile 162: Zeile 112:
  Environment="GWUSER=ssh-kunde1"
  Environment="GWUSER=ssh-kunde1"
  # remote gateway
  # remote gateway
  ##Environment="GWHOST=gateway.foxtom.de"
  ##Environment="GWHOST=gateway"
  # Location of the SSH key
  # Location of the SSH key
  ##Environment="SSHKEY=/home/support/.ssh/gateway.foxtom.de"
  ##Environment="SSHKEY=/home/support/.ssh/gateway"


'''/etc/systemd/system/ssh-reverse@443.service.d/tunnel.conf:'''
''/etc/systemd/system/ssh-reverse@443.service.d/tunnel.conf''
  [Service]
  [Service]
  # Port of the tunnel at the remote gateway
  # Port of the tunnel at the remote gateway
Zeile 173: Zeile 123:
  Environment="GWUSER=ssh-kunde1"
  Environment="GWUSER=ssh-kunde1"
  # remote gateway
  # remote gateway
  ##Environment="GWHOST=gateway.foxtom.de"
  ##Environment="GWHOST=gateway"
  # Location of the SSH key
  # Location of the SSH key
  ##Environment="SSHKEY=/home/support/.ssh/gateway.foxtom.de"
  ##Environment="SSHKEY=/home/support/.ssh/gateway"


In diesen Beispielen werden die auf dem Gateway verwendeten Sockets angepasst, statt den TCP-Ports werden verschiedene UNIX-Sockets verwendet.
* Hier werden die auf dem Gateway verwendeten Sockets angepasst, statt den TCP-Ports werden verschiedene UNIX-Sockets verwendet.
* Außerdem wird ein anderer User auf dem Gateway verwendet.
* Außerdem wird ein anderer User auf dem Gateway verwendet.


= Support-Rechner =
== Support-Rechner ==
Als normaler User, dessen SSH-Key beim Tunnel-User auf dem Gateway ("sshtunnel") hinterlegt ist, wird der Tunnel zum Gateway wie folgt aufgebaut:
=== Public-Key-Zugang ===
  user@support$ ssh -nNT -L 10022:localhost:10001 \
==== Public-Key übertragen ====
                        sshtunnel@gateway.foxtom.de
  '''user@support#''' ssh-copy-id -p22 sshTnlKunde001@gateway.foxtom.de


Damit wird ein Tunnel vom lokalen Port 10022 zum Port 10001 auf dem Gateway erstellt
==== Public-Key-Zugang testen ====
* Hat das Zielsystem, wie im Beispiel, einen reverse Tunnel zum Gateway von seinem lokalen Port 22 auf den Port 10001 auf dem Gateway gestartet, kann man nun vom support auf das Zielsystem mit SSH zugreifen:
  '''user@support#''' ssh -p22 sshTnlKunde001@gateway.foxtom.de
  user@support$ ssh -p 10022 admin@localhost
'''sshTnlKunde001@gateway:~$''' exit


"admin" ist ein Nutzer auf dem Zielsystem, über welchen der Support abgewickelt wird.
== Anwendung ==
=== Public-Key-Zugang ===
'''support@kunde001$''' ssh -i /home/support/.ssh/gateway.foxtom.de.pub -p22 sshTnlKunde001@gateway.foxtom.de
# Fingerprint vergleichen
# Bestätigung durch Eingabe von "yes"


Wird der Tunnel vom Zielsystem aus auf dem Gateway mit dem UNIX-Socket "" erstellt, wird der Tunnel vom Support-Client zum Gateway stattdessen so aufgebaut:
'''"PTY allocation request failed on channel 0"'''
user@support$ ssh -nNT -L 10022:/home/ssh-kunde1/ziel3-ssh.socket \
                        sshtunnel@gateway.foxtom.de


Ist ein Zugriff mittels Browser auf das Zielsystem notwendig, wird ein zweiter Tunnel zum Gateway erstellt:
Fehlermeldung und die Verbindung wird abgebrochen, das ist beabsichtigt.
user@support$ ssh -nNT -L 10443:localhost:10002 \
                        sshtunnel@gateway.foxtom.de


Oder bei einem UNIX-Socket:
=== Tunnel starten ===
  user@support$ ssh -nNT -L 10443:/home/ssh-kunde1/ziel3-https.socket \
  '''user@support$''' ssh -nNT -L 10022:localhost:10001 sshTnlKunde001@gateway
                        sshtunnel@gateway.foxtom.de


Wird nun im Browser [https://localhost:10443/ https://localhost:10443] eingegeben, ist man direkt mit dem Webserver auf dem Zielsystem verbunden.
Damit wird ein Tunnel vom lokalen Port 10022 zum Port 10001 auf dem Gateway erstellt
 
= Sicherheit =
Es wird ein Tunnel durch die Firewall gebohrt, welche das Netzwerk mit dem Zielsystem schützt
* Das schafft definitiv neue Angriffsmöglichkeiten auf das Netzwerk
* Hier muß man, wie bei allen Fernwartungszugängen, zwischen dem Komfortgewinn und dem Sicherheitsverlust abwägen.
 
Ein Angreifer müsste Zugriff auf das Gateway erlangen und könnte von dort alle zu managenden Zielsysteme erreichen
* Das Zielsystem und das dahinter liegende Netzwerk ist dann nur noch durch die Sicherheitsmechanismen geschützt, welche die über den Tunnel erreichbare Anwendung auf dem Zielsystem bietet (z.B. SSH- oder Webserver).
 
Es ist also zum einen wichtig, das Gateway gut abzusichern
* Das ist gar nicht so anspruchsvoll, weil es sich beim Gateway um ein Minimalsystem handelt, welches vergleichsweise einfach upgedatet und sicher konfiguriert werden kann
* Zum anderen sollten auch auf dem Zielsystem die üblichen Sicherheitsmaßnahmen durchgeführt werden (laufende Updates, sichere Passwörter usw.). Insgesamt ist bei Einhaltung dieser Maßnahmen die Sicherheit im Vergleich zu anderen Varianten (proprietäre Fernwartungstools, Port-Forwarding durch Firewalls) als höher einzuschätzen.
 
Empfehlenswert ist eine zusätzliche Absicherung der durch die Supporter benutzten SSH-Schlüssel
* Die können z.B., wie unter "[http://www.unitas-network.de/support/wiki/smartcards/ssh-login-mit-openpgp-card/ SSH-Login mit OpenPGP Card]" beschrieben, auf einer Smartcard abgelegt werden.
 
= Links =
== Intern ==
== Extern ==
# http://www.unitas-network.de/support/wiki/management/remote-management-mit-ssh-tunnel/
 
[[Category:Netzwerke:SSH]]
 
= Tunnelaufbau =
== Manueller Aufbau ==
ssh -NTC\
  -o ServerAliveInterval=60
  -o ExitOnForwardFailure=yes
  -o StrictHostKeyChecking=no\
  -i ${SSHKEY}
  -R ${GWSOCK}:localhost:${LOCALPORT}\
  ${GWUSER}@${GWHOST}


Durch den Parameter "-R" wird ein reverse Tunnel erstellt, um vom Gateway aus auf den Kundenrechner zugreifen zu können
=== Tunnelaufbau ===
; Manueller Aufbau
'''support@debian01:~$''' ssh -N -T -C -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i '''${SSHKEY}''' -R '''${GWSOCK}''':localhost:'''${LOCALPORT}''' '''${GWUSER}'''@'''${GWHOST}'''


'''Variablen'''
{| class="wikitable sortable"
|-
! Optionen  !! Bedeutung
|-
| '''-N''' || Keinen Befehl in der Ferne ausführen
|-
| '''-T''' || Deaktiviert Pseudo-Terminal-Zuweisung
|-
| '''-C''' || Komprimierung sämtlicher Daten
|-
| '''-o ServerAliveInterval=60''' ||
|-
| '''-o ExitOnForwardFailure=yes''' ||
|-
| '''-o StrictHostKeyChecking=no''' ||
|-
| '''-i ${SSHKEY}''' ||absoluter Pfad zum SSH-Key, beispielsweise  ~/.ssh/gateway
|-
| '''-R ${GWSOCK}:localhost:${LOCALPORT}''' ||  Reverse Tunnel erstellt, um vom Gateway aus auf den Kundenrechner zugreifen zu können
|}


'''${SSHKEY}'''
{| class="wikitable sortable"
*Der komplette Pfad zum SSH-Key, z.B. ~/.ssh/gateway.foxtom.de
|-
'''${GWSOCK}'''
! Parameter !! Bedeutung
* Der Socket, welcher auf dem Gateway für den Tunnel verwendet wird
|-
* Diesen muß man dort ansprechen, um sich mit dem Zielsystem zu verbinden
| '''${SSHKEY}''' || Der komplette Pfad zum SSH-Key, beispielsweise  ~/.ssh/gateway
* Werden mehrere Tunnel zum Gateway aufgebaut (was recht wahrscheinlich ist), muß natürlich für jeden ein anderer Socket verwendet werden
|-
| '''${GWSOCK}''' || Der Socket, welcher auf dem Gateway für den Tunnel verwendet wird
* Diesen muss man dort ansprechen, um sich mit dem Zielsystem zu verbinden
* Werden mehrere Tunnel zum Gateway aufgebaut (was recht wahrscheinlich ist), muss jeweils ein anderer Socket verwendet werden
* Ein Socket kann ein TCP- oder ein UNIX-Socket sein. Ein TCP-Socket ist einfach eine Port-Nummer
* Ein Socket kann ein TCP- oder ein UNIX-Socket sein. Ein TCP-Socket ist einfach eine Port-Nummer
* Da zum Tunnelaufbau normale User (nicht root) genutzt werden, können dabei nur Ports über 1024 verwendet werden.Bei einem UNIX-Socket muss dessen kompletter Pfad angegeben werden, z.B. "/home/ssh-kunde1/zielsystem3.socket".
* Da zum Tunnelaufbau normale User (nicht root) genutzt werden, können dabei nur Ports über 1024 verwendet werden. Bei einem UNIX-Socket muss dessen kompletter Pfad angegeben werden, beispielsweise  "/home/ssh-kunde1/zielsystem3.socket" (nicht "~/zielsystem3.socket")
* Das darf nicht mit "~/zielsystem3.socket" abgekürzt werden
|-
'''${LOCALPORT}'''
| '''${LOCALPORT}''' ||
* Das ist der Port, mit welchem der Tunnel auf dem Zielsystem verbunden wird
* Das ist der Port, mit welchem der Tunnel auf dem Zielsystem verbunden wird
* Soll über den Tunnel eine SSH-Sitzung aufgebaut werden, nimmt man den Port 22. Läuft auf dem Zielsystem ein Webserver und dieser soll über den Tunnel erreichbar sein, wird Port 443 genommen (für verschlüsselte Seiten).  
* Soll über den Tunnel eine SSH-Sitzung aufgebaut werden, nimmt man den Port 22. Läuft auf dem Zielsystem ein Webserver und dieser soll über den Tunnel erreichbar sein, wird Port 443 genommen (für verschlüsselte Seiten).
'''${GWUSER}'''
|-
| '''${GWUSER}''' ||
* Der User auf dem Gateway
* Der User auf dem Gateway
* In unserem Beispiel also "sshtunnel" oder "ssh-kunde1".  [FIXME]
* In unserem Beispiel also "sshTnlKunde001" oder "ssh-kunde1".  [FIXME]
'''${GWHOST}'''  
|-
* Der Hostname des Gateways, also z.B. "gateway.foxtom.de".
| '''${GWHOST}''' ||
 
* Der Hostname des Gateways, also beispielsweise  "gateway".
== Aufbau beim Booten==
|}
Systemd-Service-Unit erstellen
 
'''/etc/systemd/system/ssh-reverse@.service'''
[Unit]
Description=Reverse SSH Tunnel Service
ConditionPathExists=|/usr/bin
After=network.target
[Service]
User=support
Environment="GWSOCK=40%I"
Environment="GWUSER=sshtunnel"
Environment="GWHOST=gateway.foxtom.de"
Environment="SSHKEY=/home/support/.ssh/gateway.foxtom.de"
ExecStart=/usr/bin/ssh -NTC -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i ${SSHKEY} -R ${GWSOCK}:localhost:%I ${GWUSER}@${GWHOST}
# Restart every >2 seconds to avoid StartLimitInterval failure
RestartSec=3
Restart=always
[Install]
WantedBy=multi-user.target
 
Durch das @ im Namen der Unit können verschiedene Instanzen, also mehrere Tunnel erstellt werden
* Z.B. einer für SSH und einer für HTTPS:
'''root@kunde01#''' systemctl daemon-reload
'''root@kunde01#''' systemctl start ssh-reverse@22.service
'''root@kunde01#''' systemctl start ssh-reverse@443.service
 
Der Port des Tunnels auf dem Gateway wird auf "40%I" gesetzt wobei %I dem Instanznamen (im Beispiel 22 und 443) entspricht
* Im Beispiel ergibt das auf dem Gateway TCP-Sockets mit den Ports 4022 und 40443.
 
Die Parameter für die einzelnen Instanzen können und sollten über Drop-In-Files angepaßt werden, z.B.:
 
'''/etc/systemd/system/ssh-reverse@22.service.d/tunnel.conf:'''
[Service]
# Port of the tunnel at the remote gateway
Environment="GWSOCK=/home/ssh-kunde1/ziel3-ssh.socket"
# User at gateway to create the tunnel
Environment="GWUSER=ssh-kunde1"
# remote gateway
##Environment="GWHOST=gateway.foxtom.de"
# Location of the SSH key
##Environment="SSHKEY=/home/support/.ssh/gateway.foxtom.de"
 
'''/etc/systemd/system/ssh-reverse@443.service.d/tunnel.conf:'''
[Service]
# Port of the tunnel at the remote gateway
Environment="GWSOCK=/home/ssh-kunde1/ziel3-https.socket"
# User at gateway to create the tunnel
Environment="GWUSER=ssh-kunde1"
# remote gateway
##Environment="GWHOST=gateway.foxtom.de"
# Location of the SSH key
##Environment="SSHKEY=/home/support/.ssh/gateway.foxtom.de"
 
In diesen Beispielen werden die auf dem Gateway verwendeten Sockets angepasst, statt den TCP-Ports werden verschiedene UNIX-Sockets verwendet.
* Außerdem wird ein anderer User auf dem Gateway verwendet.
 
= Support-Rechner =
Als normaler User, dessen SSH-Key beim Tunnel-User auf dem Gateway ("sshtunnel") hinterlegt ist, wird der Tunnel zum Gateway wie folgt aufgebaut:
user@support$ ssh -nNT -L 10022:localhost:10001 \
                        sshtunnel@gateway.foxtom.de
 
Damit wird ein Tunnel vom lokalen Port 10022 zum Port 10001 auf dem Gateway erstellt
* Hat das Zielsystem, wie im Beispiel, einen reverse Tunnel zum Gateway von seinem lokalen Port 22 auf den Port 10001 auf dem Gateway gestartet, kann man nun vom support auf das Zielsystem mit SSH zugreifen:
user@support$ ssh -p 10022 admin@localhost
 
"admin" ist ein Nutzer auf dem Zielsystem, über welchen der Support abgewickelt wird.
 
Wird der Tunnel vom Zielsystem aus auf dem Gateway mit dem UNIX-Socket "" erstellt, wird der Tunnel vom Support-Client zum Gateway stattdessen so aufgebaut:
user@support$ ssh -nNT -L 10022:/home/ssh-kunde1/ziel3-ssh.socket \
                        sshtunnel@gateway.foxtom.de
 
Ist ein Zugriff mittels Browser auf das Zielsystem notwendig, wird ein zweiter Tunnel zum Gateway erstellt:
user@support$ ssh -nNT -L 10443:localhost:10002 \
                        sshtunnel@gateway.foxtom.de
 
Oder bei einem UNIX-Socket:
user@support$ ssh -nNT -L 10443:/home/ssh-kunde1/ziel3-https.socket \
                        sshtunnel@gateway.foxtom.de


Wird nun im Browser [https://localhost:10443/ https://localhost:10443] eingegeben, ist man direkt mit dem Webserver auf dem Zielsystem verbunden.
; Beispiel
$ ssh -N -T -C -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i ~/.ssh/gateway.foxtom.de -R 227:localhost:22 -p22 sshTnlKunde001@gateway.foxtom.de


= Sicherheit =
== Sicherheit ==
; Angriffsmöglichkeiten
Es wird ein Tunnel durch die Firewall gebohrt, welche das Netzwerk mit dem Zielsystem schützt
Es wird ein Tunnel durch die Firewall gebohrt, welche das Netzwerk mit dem Zielsystem schützt
* Das schafft definitiv neue Angriffsmöglichkeiten auf das Netzwerk
* Hier muß man, wie bei allen Fernwartungszugängen, zwischen dem Komfortgewinn und dem Sicherheitsverlust abwägen.
Ein Angreifer müsste Zugriff auf das Gateway erlangen und könnte von dort alle zu managenden Zielsysteme erreichen
* Das Zielsystem und das dahinter liegende Netzwerk ist dann nur noch durch die Sicherheitsmechanismen geschützt, welche die über den Tunnel erreichbare Anwendung auf dem Zielsystem bietet (z.B. SSH- oder Webserver).
Es ist also zum einen wichtig, das Gateway gut abzusichern
* Das ist gar nicht so anspruchsvoll, weil es sich beim Gateway um ein Minimalsystem handelt, welches vergleichsweise einfach upgedatet und sicher konfiguriert werden kann
* Zum anderen sollten auch auf dem Zielsystem die üblichen Sicherheitsmaßnahmen durchgeführt werden (laufende Updates, sichere Passwörter usw.). Insgesamt ist bei Einhaltung dieser Maßnahmen die Sicherheit im Vergleich zu anderen Varianten (proprietäre Fernwartungstools, Port-Forwarding durch Firewalls) als höher einzuschätzen.
Empfehlenswert ist eine zusätzliche Absicherung der durch die Supporter benutzten SSH-Schlüssel
* Die können z.B., wie unter "[http://www.unitas-network.de/support/wiki/smartcards/ssh-login-mit-openpgp-card/ SSH-Login mit OpenPGP Card]" beschrieben, auf einer Smartcard abgelegt werden.
= Links =
== Intern ==
== Extern ==
# http://www.unitas-network.de/support/wiki/management/remote-management-mit-ssh-tunnel/
[[Category:Netzwerke:SSH]]
'' ssh -i ~/.ssh/gateway.foxtom.de sshtunnel@gateway.foxtom.de
Nach Vergleich des angezeigten Fingerprints und Bestätigung durch Eingabe von "yes" erscheint eine Fehlermeldung "PTY allocation request failed on channel 0" und die Verbindung wird wieder abgebrochen. Das ist so gewollt.
= Tunnelaufbau =
== Manueller Aufbau ==
ssh -NTC\
  -o ServerAliveInterval=60
  -o ExitOnForwardFailure=yes
  -o StrictHostKeyChecking=no\
  -i ${SSHKEY}
  -R ${GWSOCK}:localhost:${LOCALPORT}\
  ${GWUSER}@${GWHOST}
Durch den Parameter "-R" wird ein reverse Tunnel erstellt, um vom Gateway aus auf den Kundenrechner zugreifen zu können


'''Variablen'''
; Risiken
Angreifer erlangt Zugriff auf das Gateway
* könnte von dort alle zu managenden Zielsysteme erreichen
* Das Zielsystem und das dahinter liegende Netzwerk ist dann nur noch durch die Sicherheitsmechanismen geschützt, welche die über den Tunnel erreichbare Anwendung auf dem Zielsystem bietet (beispielsweise  SSH- oder Webserver).


'''${SSHKEY}'''
; Gateway gut absichern
*Der komplette Pfad zum SSH-Key, z.B. ~/.ssh/gateway.foxtom.de
Das ist gar nicht so anspruchsvoll
'''${GWSOCK}'''
* weil es sich beim Gateway um ein Minimalsystem handelt
* Der Socket, welcher auf dem Gateway für den Tunnel verwendet wird
* welches vergleichsweise einfach upgedatet und sicher konfiguriert werden kann
* Diesen muß man dort ansprechen, um sich mit dem Zielsystem zu verbinden
* Werden mehrere Tunnel zum Gateway aufgebaut (was recht wahrscheinlich ist), muß natürlich für jeden ein anderer Socket verwendet werden
* Ein Socket kann ein TCP- oder ein UNIX-Socket sein. Ein TCP-Socket ist einfach eine Port-Nummer
* Da zum Tunnelaufbau normale User (nicht root) genutzt werden, können dabei nur Ports über 1024 verwendet werden.Bei einem UNIX-Socket muss dessen kompletter Pfad angegeben werden, z.B. "/home/ssh-kunde1/zielsystem3.socket".
* Das darf nicht mit "~/zielsystem3.socket" abgekürzt werden
'''${LOCALPORT}'''
* Das ist der Port, mit welchem der Tunnel auf dem Zielsystem verbunden wird
* Soll über den Tunnel eine SSH-Sitzung aufgebaut werden, nimmt man den Port 22. Läuft auf dem Zielsystem ein Webserver und dieser soll über den Tunnel erreichbar sein, wird Port 443 genommen (für verschlüsselte Seiten).
'''${GWUSER}'''
* Der User auf dem Gateway
* In unserem Beispiel also "sshtunnel" oder "ssh-kunde1".  [FIXME]
'''${GWHOST}'''
* Der Hostname des Gateways, also z.B. "gateway.foxtom.de".


== Aufbau beim Booten==
; Sicherheitsmaßnahmen auf dem Zielsystem
Systemd-Service-Unit erstellen
* laufende Updates
* kein root-logins zulassen
* starke Passwörter


'''/etc/systemd/system/ssh-reverse@.service'''
; Bewertung
[Unit]
Bei Einhaltung dieser Maßnahmen die Sicherheit im Vergleich zu anderen Varianten (proprietäre Fernwartungstools, Port-Forwarding durch Firewalls) als höher einzuschätzen
Description=Reverse SSH Tunnel Service
ConditionPathExists=|/usr/bin
After=network.target
[Service]
User=support
Environment="GWSOCK=40%I"
Environment="GWUSER=sshtunnel"
Environment="GWHOST=gateway.foxtom.de"
Environment="SSHKEY=/home/support/.ssh/gateway.foxtom.de"
ExecStart=/usr/bin/ssh -NTC -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i ${SSHKEY} -R ${GWSOCK}:localhost:%I ${GWUSER}@${GWHOST}
# Restart every >2 seconds to avoid StartLimitInterval failure
RestartSec=3
Restart=always
[Install]
WantedBy=multi-user.target
 
Durch das @ im Namen der Unit können verschiedene Instanzen, also mehrere Tunnel erstellt werden
* Z.B. einer für SSH und einer für HTTPS:
'''root@kunde01#''' systemctl daemon-reload
'''root@kunde01#''' systemctl start ssh-reverse@22.service
'''root@kunde01#''' systemctl start ssh-reverse@443.service
 
Der Port des Tunnels auf dem Gateway wird auf "40%I" gesetzt wobei %I dem Instanznamen (im Beispiel 22 und 443) entspricht
* Im Beispiel ergibt das auf dem Gateway TCP-Sockets mit den Ports 4022 und 40443.
 
Die Parameter für die einzelnen Instanzen können und sollten über Drop-In-Files angepaßt werden, z.B.:
 
'''/etc/systemd/system/ssh-reverse@22.service.d/tunnel.conf:'''
[Service]
# Port of the tunnel at the remote gateway
Environment="GWSOCK=/home/ssh-kunde1/ziel3-ssh.socket"
# User at gateway to create the tunnel
Environment="GWUSER=ssh-kunde1"
# remote gateway
##Environment="GWHOST=gateway.foxtom.de"
# Location of the SSH key
##Environment="SSHKEY=/home/support/.ssh/gateway.foxtom.de"
 
'''/etc/systemd/system/ssh-reverse@443.service.d/tunnel.conf:'''
[Service]
# Port of the tunnel at the remote gateway
Environment="GWSOCK=/home/ssh-kunde1/ziel3-https.socket"
# User at gateway to create the tunnel
Environment="GWUSER=ssh-kunde1"
# remote gateway
##Environment="GWHOST=gateway.foxtom.de"
# Location of the SSH key
##Environment="SSHKEY=/home/support/.ssh/gateway.foxtom.de"
 
In diesen Beispielen werden die auf dem Gateway verwendeten Sockets angepasst, statt den TCP-Ports werden verschiedene UNIX-Sockets verwendet.
* Außerdem wird ein anderer User auf dem Gateway verwendet.
 
= Support-Rechner =
Als normaler User, dessen SSH-Key beim Tunnel-User auf dem Gateway ("sshtunnel") hinterlegt ist, wird der Tunnel zum Gateway wie folgt aufgebaut:
user@support$ ssh -nNT -L 10022:localhost:10001 \
                        sshtunnel@gateway.foxtom.de
 
Damit wird ein Tunnel vom lokalen Port 10022 zum Port 10001 auf dem Gateway erstellt
* Hat das Zielsystem, wie im Beispiel, einen reverse Tunnel zum Gateway von seinem lokalen Port 22 auf den Port 10001 auf dem Gateway gestartet, kann man nun vom support auf das Zielsystem mit SSH zugreifen:
user@support$ ssh -p 10022 admin@localhost
 
"admin" ist ein Nutzer auf dem Zielsystem, über welchen der Support abgewickelt wird.
 
Wird der Tunnel vom Zielsystem aus auf dem Gateway mit dem UNIX-Socket "" erstellt, wird der Tunnel vom Support-Client zum Gateway stattdessen so aufgebaut:
user@support$ ssh -nNT -L 10022:/home/ssh-kunde1/ziel3-ssh.socket \
                        sshtunnel@gateway.foxtom.de
 
Ist ein Zugriff mittels Browser auf das Zielsystem notwendig, wird ein zweiter Tunnel zum Gateway erstellt:
user@support$ ssh -nNT -L 10443:localhost:10002 \
                        sshtunnel@gateway.foxtom.de
 
Oder bei einem UNIX-Socket:
user@support$ ssh -nNT -L 10443:/home/ssh-kunde1/ziel3-https.socket \
                        sshtunnel@gateway.foxtom.de
 
Wird nun im Browser [https://localhost:10443/ https://localhost:10443] eingegeben, ist man direkt mit dem Webserver auf dem Zielsystem verbunden.
 
= Sicherheit =
Es wird ein Tunnel durch die Firewall gebohrt, welche das Netzwerk mit dem Zielsystem schützt
* Das schafft definitiv neue Angriffsmöglichkeiten auf das Netzwerk
* Hier muß man, wie bei allen Fernwartungszugängen, zwischen dem Komfortgewinn und dem Sicherheitsverlust abwägen.


Ein Angreifer müsste Zugriff auf das Gateway erlangen und könnte von dort alle zu managenden Zielsysteme erreichen
; Zusätzliche Absicherung
* Das Zielsystem und das dahinter liegende Netzwerk ist dann nur noch durch die Sicherheitsmechanismen geschützt, welche die über den Tunnel erreichbare Anwendung auf dem Zielsystem bietet (z.B. SSH- oder Webserver).
* [[fail2ban]]
* Durch die Supporter benutzte SSH-Schlüssel auf Smartcard ablegen
* Die können beispielsweise , wie unter "[https://www.unitas-network.de/support/wiki/smartcards/ssh-login-mit-openpgp-card/ SSH-Login mit OpenPGP Card]" beschrieben, auf einer Smartcard abgelegt werden


Es ist also zum einen wichtig, das Gateway gut abzusichern
== Siehe auch ==
* Das ist gar nicht so anspruchsvoll, weil es sich beim Gateway um ein Minimalsystem handelt, welches vergleichsweise einfach upgedatet und sicher konfiguriert werden kann
* Zum anderen sollten auch auf dem Zielsystem die üblichen Sicherheitsmaßnahmen durchgeführt werden (laufende Updates, sichere Passwörter usw.). Insgesamt ist bei Einhaltung dieser Maßnahmen die Sicherheit im Vergleich zu anderen Varianten (proprietäre Fernwartungstools, Port-Forwarding durch Firewalls) als höher einzuschätzen.


Empfehlenswert ist eine zusätzliche Absicherung der durch die Supporter benutzten SSH-Schlüssel
{{Special:PrefixIndex/{{BASEPAGENAME}}/}}
* Die können z.B., wie unter "[http://www.unitas-network.de/support/wiki/smartcards/ssh-login-mit-openpgp-card/ SSH-Login mit OpenPGP Card]" beschrieben, auf einer Smartcard abgelegt werden.
=== Dokumentation ===
==== RFC ====
==== Man-Page ====
==== Info-Pages ====
=== Links ===
==== Projekt ====
==== Weblinks ====
# https://www.unitas-network.de/support/wiki/management/remote-management-mit-ssh-tunnel/


= Links =
== Intern ==
== Extern ==
# http://www.unitas-network.de/support/wiki/management/remote-management-mit-ssh-tunnel/


[[Category:Netzwerke:SSH]]
[[Kategorie:SSH/Tunnel]]

Aktuelle Version vom 2. Oktober 2025, 09:40 Uhr

SSH-Gateway - vermittelt verschlüsselte Tunnelverbindungen zwischen SSH-Clients

Beschreibung

Teilnehmer bauen aktiv einen Tunnel zum Gateway auf
  • Keine Portweiterleitungen erforderlich
  • Keine Namensauflösung der Teilnehmer erforderlich
Gateway vermittelt den Kontakt
  • Gateway ist ein SSH-Server im Internet
Trennung verschiedener Kunden/Dienstleiter
  • Je Tunnel (Kombination aus Kunde/Dienstleiter) ein Zugang
Szenario
Hostname Username
gateway.foxtom.de sshTnlKunde001
kunde001 support
support user

Gateway

Kunden-Zugang

Tunnel-Benutzerkonto

root@gateway# useradd --create-home --groups users --shell /bin/bash --comment "Tunnel-User Kunden001" sshTnlKunde001

Passwort vergeben

root@gateway# passwd sshTnlKunde001
New password:
Retype new password:
passwd: password updated successfully

Zugang testen

user@support# ssh -p22 sshTnlKunde001@gateway.foxtom.de
sshTnlKunde001@gateway's password:

SSH-Server

UNIX Sockets

Damit sich Kunden nicht mit dem System eines anderen Kunden verbinden können, werden hier UNIX Sockets verwandt.

  • Diese besitzen im Gegensatz zu TCP-Ports eine Zugriffssteuerung

Damit der Socket beim Abbau des Tunnels eine neue Socket-Datei erstellt wird, wird die Konfiguration des SSH-Dienstes ergänzt

  • ein erneuter Aufbau des Tunnels ist ansonsten mit dem gleichen Socket-Namen nicht möglich

/etc/ssh/sshd_config 

# Specifies whether to remove an existing Unix-domain socket file for local or remote port forwarding before creating a new one.
StreamLocalBindUnlink yes

Kunden-Rechner

Tunnel-Benutzerkonto

root@kunde001# useradd -m -G users -s /bin/bash kunde001Tnl

SSH-Key erzeugen

root@kunde001# sudo -u support -i
support@kunde001$ ssh-keygen -f /home/support/.ssh/gateway -t ecdsa

Keine Passphrase eingeben (Enter)

Public-Key übertragen

support@kunde001$ ssh-copy-id -p22 -i /home/support/.ssh/gateway.foxtom.de.pub sshTnlKunde001@gateway.foxtom.de

Public-Key-Zugang testen

support@kunde001$ ssh -i /home/support/.ssh/gateway.foxtom.de -p22 sshTnlKunde001@gateway.foxtom.de
  1. Fingerprint vergleichen
  2. Bestätigung durch Eingabe von "yes"

Fehlermeldung "PTY allocation request failed on channel 0" und die Verbindung wird abgebrochen. Das ist beabsichtigt.

Automatisierung

Systemd konfigurieren

Systemd-Service-Unit

/etc/systemd/system/ssh-reverse@.service 

[Unit]
Description=Reverse SSH Tunnel Service
ConditionPathExists=|/usr/bin
After=network.target

[Service]
User=support
Environment="GWSOCK=40%I"
Environment="GWUSER=sshTnlKunde001"
Environment="GWHOST=gateway"
Environment="SSHKEY=/home/support/.ssh/gateway"
ExecStart=/usr/bin/ssh -NTC -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i ${SSHKEY} -R ${GWSOCK}:localhost:%I ${GWUSER}@${GWHOST}

# Restart every >2 seconds to avoid StartLimitInterval failure
RestartSec=3
Restart=always

[Install]
WantedBy=multi-user.target

Durch das @ im Namen der Unit-Datei können verschiedene Instanzen (also Tunnel) erstellt werden: 

root@kunde001# systemctl daemon-reload
root@kunde001# systemctl start ssh-reverse@22.service
root@kunde001# systemctl start ssh-reverse@443.service
  • Der Port des Tunnels auf dem Gateway wird auf "40%I" gesetzt wobei %I dem Instanznamen (hier 22 und 443) entspricht
  • Hier ergibt das auf dem Gateway TCP-Sockets mit den Ports 4022 und 40443.
Parameter für Instanzen
  • Drop-In-Files

/etc/systemd/system/ssh-reverse@22.service.d/tunnel.conf 

[Service]
# Port of the tunnel at the remote gateway
Environment="GWSOCK=/home/ssh-kunde1/ziel3-ssh.socket"
# User at gateway to create the tunnel
Environment="GWUSER=ssh-kunde1"
# remote gateway
##Environment="GWHOST=gateway"
# Location of the SSH key
##Environment="SSHKEY=/home/support/.ssh/gateway"

/etc/systemd/system/ssh-reverse@443.service.d/tunnel.conf 

[Service]
# Port of the tunnel at the remote gateway
Environment="GWSOCK=/home/ssh-kunde1/ziel3-https.socket"
# User at gateway to create the tunnel
Environment="GWUSER=ssh-kunde1"
# remote gateway
##Environment="GWHOST=gateway"
# Location of the SSH key
##Environment="SSHKEY=/home/support/.ssh/gateway"
  • Hier werden die auf dem Gateway verwendeten Sockets angepasst, statt den TCP-Ports werden verschiedene UNIX-Sockets verwendet.
  • Außerdem wird ein anderer User auf dem Gateway verwendet.

Support-Rechner

Public-Key-Zugang

Public-Key übertragen

user@support# ssh-copy-id -p22 sshTnlKunde001@gateway.foxtom.de

Public-Key-Zugang testen

user@support# ssh -p22 sshTnlKunde001@gateway.foxtom.de
sshTnlKunde001@gateway:~$ exit

Anwendung

Public-Key-Zugang

support@kunde001$ ssh -i /home/support/.ssh/gateway.foxtom.de.pub -p22 sshTnlKunde001@gateway.foxtom.de
  1. Fingerprint vergleichen
  2. Bestätigung durch Eingabe von "yes"

"PTY allocation request failed on channel 0"

Fehlermeldung und die Verbindung wird abgebrochen, das ist beabsichtigt.

Tunnel starten

user@support$ ssh -nNT -L 10022:localhost:10001 sshTnlKunde001@gateway

Damit wird ein Tunnel vom lokalen Port 10022 zum Port 10001 auf dem Gateway erstellt

Tunnelaufbau

Manueller Aufbau
support@debian01:~$ ssh -N -T -C -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i ${SSHKEY} -R ${GWSOCK}:localhost:${LOCALPORT} ${GWUSER}@${GWHOST}
Optionen Bedeutung
-N Keinen Befehl in der Ferne ausführen
-T Deaktiviert Pseudo-Terminal-Zuweisung
-C Komprimierung sämtlicher Daten
-o ServerAliveInterval=60
-o ExitOnForwardFailure=yes
-o StrictHostKeyChecking=no
-i ${SSHKEY} absoluter Pfad zum SSH-Key, beispielsweise ~/.ssh/gateway
-R ${GWSOCK}:localhost:${LOCALPORT} Reverse Tunnel erstellt, um vom Gateway aus auf den Kundenrechner zugreifen zu können
Parameter Bedeutung
${SSHKEY} Der komplette Pfad zum SSH-Key, beispielsweise ~/.ssh/gateway
${GWSOCK} Der Socket, welcher auf dem Gateway für den Tunnel verwendet wird
  • Diesen muss man dort ansprechen, um sich mit dem Zielsystem zu verbinden
  • Werden mehrere Tunnel zum Gateway aufgebaut (was recht wahrscheinlich ist), muss jeweils ein anderer Socket verwendet werden
  • Ein Socket kann ein TCP- oder ein UNIX-Socket sein. Ein TCP-Socket ist einfach eine Port-Nummer
  • Da zum Tunnelaufbau normale User (nicht root) genutzt werden, können dabei nur Ports über 1024 verwendet werden. Bei einem UNIX-Socket muss dessen kompletter Pfad angegeben werden, beispielsweise "/home/ssh-kunde1/zielsystem3.socket" (nicht "~/zielsystem3.socket")
${LOCALPORT}
  • Das ist der Port, mit welchem der Tunnel auf dem Zielsystem verbunden wird
  • Soll über den Tunnel eine SSH-Sitzung aufgebaut werden, nimmt man den Port 22. Läuft auf dem Zielsystem ein Webserver und dieser soll über den Tunnel erreichbar sein, wird Port 443 genommen (für verschlüsselte Seiten).
${GWUSER}
  • Der User auf dem Gateway
  • In unserem Beispiel also "sshTnlKunde001" oder "ssh-kunde1". [FIXME]
${GWHOST}
  • Der Hostname des Gateways, also beispielsweise "gateway".
Beispiel
$ ssh -N -T -C -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i ~/.ssh/gateway.foxtom.de -R 227:localhost:22 -p22 sshTnlKunde001@gateway.foxtom.de

Sicherheit

Angriffsmöglichkeiten

Es wird ein Tunnel durch die Firewall gebohrt, welche das Netzwerk mit dem Zielsystem schützt

Risiken

Angreifer erlangt Zugriff auf das Gateway

  • könnte von dort alle zu managenden Zielsysteme erreichen
  • Das Zielsystem und das dahinter liegende Netzwerk ist dann nur noch durch die Sicherheitsmechanismen geschützt, welche die über den Tunnel erreichbare Anwendung auf dem Zielsystem bietet (beispielsweise SSH- oder Webserver).
Gateway gut absichern

Das ist gar nicht so anspruchsvoll

  • weil es sich beim Gateway um ein Minimalsystem handelt
  • welches vergleichsweise einfach upgedatet und sicher konfiguriert werden kann
Sicherheitsmaßnahmen auf dem Zielsystem
  • laufende Updates
  • kein root-logins zulassen
  • starke Passwörter
Bewertung

Bei Einhaltung dieser Maßnahmen die Sicherheit im Vergleich zu anderen Varianten (proprietäre Fernwartungstools, Port-Forwarding durch Firewalls) als höher einzuschätzen

Zusätzliche Absicherung
  • fail2ban
  • Durch die Supporter benutzte SSH-Schlüssel auf Smartcard ablegen
  • Die können beispielsweise , wie unter "SSH-Login mit OpenPGP Card" beschrieben, auf einer Smartcard abgelegt werden

Siehe auch

Dokumentation

RFC

Man-Page

Info-Pages

Links

Projekt

Weblinks

  1. https://www.unitas-network.de/support/wiki/management/remote-management-mit-ssh-tunnel/
Abgerufen von „https://wiki.foxtom.de/index.php?title=SSH/Gateway&oldid=154216“