SSH/Gateway

Beschreibung

• Alle Clients baut aktiv einen SSH-Tunnel zu einem SSH-Gateway auf
• Anpassungen an Firewall auf Client-Seiten sind nicht erforderlich

Gateway

Als Gateway dient ein SSH-Server im Internet

• Hostname: gateway.foxtom.de
• Username: sshtunnel

Kundenrechner

• Hostname: kunde01
• Username: support

Gateway

Account für den Tunnelaufbau anlegen

root@gateway# useradd --create-home --groups users --shell /bin/bash sshtunnel

Passwort vergeben

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

Passwort-Zugang testen

user@support# ssh sshtunnel@gateway
sshtunnel@gateway's password:
sshtunnel@gateway:~$ exit

Public-Key übertragen

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

Public-Key-Zugang testen

user@support# ssh sshtunnel@gateway.foxtom.de
sshtunnel@gateway's password:
sshtunnel@gateway:~$ exit

Kunden-Rechner

Tunnel-User anlegen

root@kunde01# useradd -m -G users -s /bin/bash support

SSH-Key erzeugen

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

Eine Passphrase wird nicht verwendet (Enter)

Public-Key übertragen

support@kunde01$ ssh-copy-id -p2227 -i /home/support/.ssh/gateway.foxtom.de.pub sshtunnel@gateway.foxtom.de

Public-Key-Zugang testen

support@kunde01$ ssh -i /home/support/.ssh/gateway.foxtom.de.pub -p2227 sshtunnel@gateway.foxtom.de

1. Vergleich des Fingerprints
2. Bestätigung durch Eingabe von "yes"

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

Tunnelaufbau

Manueller Aufbau

support@kunde01$ 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

Optionen	Bedeutung
-NTC
-o ServerAliveInterval=60
-o ExitOnForwardFailure=yes
-o StrictHostKeyChecking=no
-i
-R

Parameter	Bedeutung
${SSHKEY}	Der komplette Pfad zum SSH-Key, z.B. ~/.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 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" (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 "sshtunnel" oder "ssh-kunde1". [FIXME]
${GWHOST}	Der Hostname des Gateways, also z.B. "gateway".

Beispiel

support@debian01:~$ ssh -NTC -o ServerAliveInterval=60 -o ExitOnForwardFailure=yes -o StrictHostKeyChecking=no -i ~/.ssh/gateway.foxtom.de -R 22277:localhost:2227 -p2227 sshtunnel@gateway.foxtom.de

Support-Rechner

Tunnel starten

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

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

Verbindung zum Zielrechner

user@support$ ssh -p 10022 admin@localhost

"admin" ist ein Nutzer auf dem Zielsystem, über welchen der Support abgewickelt wird.

Absicherung

Nutzergruppen

Um verschiedene Kunden/Dienstleiter voneinander zu trennen, kann auf dem Gateway je Tunnel (Kombination aus Kunde/Dienstleiter) ein Zugang angelegt werden.

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

Passwort-Zugang sperren

root@gateway# passwd --lock sshtunnel

Nutzung von UNIX Sockets

Das Verbinden des vom Zielsystem kommenden Tunnels mit dem des Supporters geschieht ü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.

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

Tunnel über Socket aufbauen

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

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

Oder bei einem UNIX-Socket:

user@support$ ssh -nNT -L 10443:/home/ssh-kunde1/ziel3-https.socket sshtunnel@gateway

Wird nun im Browser https://localhost:10443 eingegeben, ist man direkt mit dem Webserver auf dem Zielsystem verbunden.

Allgemein

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 muss 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 "SSH-Login mit OpenPGP Card" beschrieben, auf einer Smartcard abgelegt werden.

Automatisierung

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"
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@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 (hier 22 und 443) entspricht
• Hier ergibt das auf dem Gateway TCP-Sockets mit den Ports 4022 und 40443.

Die Parameter für die Instanzen sollten über Drop-In-Files angepaßt werden:

/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.

Links

Extern

1. http://www.unitas-network.de/support/wiki/management/remote-management-mit-ssh-tunnel/