SSH Tunnel Reverse Port forwarding

VPN Tunnel mit SSH Port Weiterleitung

SSH ist bei Linux von Beginn an dabei, auch Apple hat Secure Shell in macOS integriert, und Microsoft verpasste ebenfalls OpenSSH unter Windows 10 ab 1803 und Server 2019 als optio­nales Feature. Dazu gibt es SSH-Tunnel und SSH Port forwarding von den seit geraumer Zeit bekannten Tools wie PuTTY und KiTTY. Warum also SSH nicht auch als VPN Tunnel nutzen, dabei stehen nützliche Möglichkeiten für den Einsatz zur Verfügung, beispielsweise wenn ein VPN Tunnel nicht an der Firewall terminiert werden soll, oder wenn in Unternehmensnetzwerke zusätzliche Software nicht installiert werden kann, oder die rechte dazu fehlen. Ein SSH Reverse Tunnel ist immer dann hilfreich, wenn es Zugriff auf ein Remote Computer geben soll, dieser hinter einer Firewall steht.

Anwendung von SSH als VPN Tunnel und Port forwarding mit OpenSSH auf Linux, macOS und Windows

SSH Tunnel zu Remote Host B

Bei diesem Beispiel wird ein Tunnel von Host A zu Host B aufgebaut, Host B ist ein Webserver von diesem die Intranet Seite http://192.168.111.10 auf Host A geöffnet werden soll. Die einzige voraussetzung ist dabei, das es beim Router ein NAT Mapping über Port 22 zu Host B gibt, und das SSH auf jedem Host vorhanden ist.

Abbildung: ssh tunnel host A to host B

Das Command im Linux Terminal auf Host A wie folgt ausführen:

$ ssh -NT -L 80:192.168.111.10:80 cherry@172.17.16.15 -p 45680

Auf Host A kann nun die Webseite http://localhost geöffnet werden. Der SSH Tunnel macht die Weiterleitung über TCP Port 80 auf Host B von 192.168.111.10 zum localhost 127.0.0.1 auf Host A, der externe Port ist 45680. Bei Host B authentifizieren wir mit Benutzer cherry.

Die Bedeutung der Parameter:
-L = Lokaler Port.
-N = kein Remote Command ausführen.
-p = Externer SSH Port (NAT Port bei Firewall).
-T = kein Terminal öffnen.

Auf dem Host B muss der SSH Daemon konfiguriert und aktiviert sein, in der Konfigurationsdatei /etc/ssh/sshd_config sind folgende Einstellungen erforderlich, diese bei vielen Linux distributionen der Standard ist.

# Force SSH Protocol 2
Protocol 2

#Turn on Privileged Separation for security
UsePrivilegeSeparation yes

#Deny root login
PermitRootLogin no

#Do not allow empty passwords
PermitEmptyPasswords no

# installations will only check .ssh/authorized_keys
AuthorizedKeysFile      .ssh/authorized_keys

# Forward my X Sessions
X11Forwarding yes
X11DisplayOffset 10

# I hate Motd displays
PrintMotd no

# It's alliivee
TCPKeepAlive yes

#AllowTcpForwarding yes

  Die mit # auskommentierten Zeilen sind default Werte, zB. #AllowTcpForwarding ist per default yes.

Als SSH Server eignen sich viele Geräte, die auf Linux und FreeBSD OS laufen, so auch Synology NAS, FreeNAS, FreePBX Distro, OpenWrt, Raspberry Pi (Raspbian) und nun auch Windows Server, um nur einige zu nennen.

SSH Tunnel zu Remote Host C

In diesem Beispiel wird ein SSH Tunnel von Host A zu Host C aufgebaut, Host C ist ein RDS-Terminalserver, Host B dient als Port forwarder.

Abbildung: ssh tunnel host A to host C

Das Command im Linux Terminal auf Host A wie folgt ausführen:

$ ssh -NT -L 3389:192.168.111.10:3389 cherry@172.17.16.15 -p 43389

Die Remotedesktop Sitzung zu Host C wird über localhost auf Host A aufgebaut, durch drücken der Taste Win + R wird Ausführen geöffnet, dazu die Eingabe mstsc /v:localhost mit OK bestätigen.

 In diesem Beispiel wird der Standard TCP Port 3389 für RDP als interner sowie auch als externer Port verwendet. Es können alle unprivilegierte Ports (-L) höher als 1024 verwendet werden, kommt ein anderer Port als 3389 zur Anwendung, dann muss der Port zur ausführung an RDP übergeben werden, zB: mstsc /v:localhost:44389

Bei Host B muss der Kernel für IP forwarding aktiviert sein, das Command hierfür in der Shell als root ist:

$ net.ipv4.ip_forward = 1

Alternativ wird mit echo in der Shell Console das selbe bewirkt:

$ echo 1 > /proc/sys/net/ipv4/ip_forward

Den aktuellen IPv4 forward Status wie folgt abfragen:

$ sysctl net.ipv4.ip_forward
net.ipv4.ip_forward = 1

Mit 1 wird die aktivierung bestätigt, 0 gilt für die deaktivierung. Die Änderung ist nicht Boot persistent, damit nach dem nächsten start das IP forwarding wieder aktiv ist, editiert man mit nano oder mit sudo vi /etc/sysctl.conf

# Controls IP packet forwarding
net.ipv4.ip_forward = 1

Es empfiehlt sich zur Authentifizierung ein SSH Schlüssel zu verwenden, ein Schlüsselpaar kann wie folgt erzeugt werden:

$ ssh-keygen -f ~/.ssh/key_rsa -t rsa -b 4096

Den Public Key ~/.ssh/key_rsa.pub speichert man im Home Pfad des Benutzers, hier in diesem Beispiel auf dem Host B unter dem Pfad in der Datei ~/.ssh/authorized_keys, mehr dazu in diesem Artikel hier.

  Die Authentifizierung unter Verwendung von SSH Schlüssel ist nicht nur sicherer, es bieten sich weitere vorteile, Beispielweise wird der Anwender nicht aufgefordert ein Passwort eingeben zu müssen, auch lässt sich so der SSH Tunnel und weitere Commands aus einem Script ausführen.

SSH Tunnel unter macOS

Bei Apple macOS steht SSH erst nach der Aktivierung zur Verfügung, dies im Terminal wie folgt zur Ausführung kommt:

$ sudo systemsetup -setremotelogin on

Danach kann der SSH Tunnel unter macOS aufgebaut werden.

$ ssh -i ~/.ssh/key_rsa -NT -R 3389:192.168.111.11:3389 cherry@172.17.16.15 -p 43389

Mit dem Remote Desktop for Mac wird jetzt bei Gateway localhost eingetragen und die RDP Session aufgebaut, auf diese weise sind Terminalserver geschützt und nur über SSH erreichbar.

macOS bietet auch die möglichkeit zur automatisierung und nutzt dazu launchd und die launch system services, folgendes Script wird angelegt unter:
@/Library/LaunchDaemons/server.hostc.client.cherry.home.plist mit folgendem Inhalt:

<plist version="1.0">
   <dict>
   <key>Label</key>
   <string>server.hostc.client.cherry.home</string>
   <key>ProgramArguments</key>
   <array>
	  <string>ssh</string>
	  <string>-NTC</string>
	  <string>-o ServerAliveInterval=60</string>
	  <string>-o ExitOnForwardFailure=yes</string>
	  <string>-i</string>
	  <string>/Users/cherry/.ssh/key_rsa</string>
	  <string>-R 3389:192.168.111.11:3389</string>
	  <string>cherry@172.17.16.15</string>
          <string>-p 43389</string>
   </array>
   <key>UserName</key>
   <string>cherry</string>
   <key>RunAtLoad</key>
   <true>
   <key>KeepAlive</key>
   <true>
</true></true></dict>
</plist>

OpenSSH-Server Installation aus PowerShell

Bei Windows Server 2019 kann der OpenSSH-Server auch mit erhöhten Rechte aus der PowerShell als Administrator bereitgestellt werden.

PS C:\> Get-WindowsCapability -Online | ? name -like *OpenSSH.Server* | Add-WindowsCapability -Online
  Bei Windows 10 ist der OpenSSH Client in den Einstellungen zu finden, unter Apps & Features – Optionale Features – OpenSSH-Client.

Let’s Encrypt Zertifikat Windows und Exchange Server

Let’s Encrypt Zertifikat für Windows IIS Websites und Exchange Server erstellen

HTTPS verschlüsselte Webseiten sind der neue Standard, und bei Kontaktformularen sogar Pflicht. Seit 2017 markiert Google unverschlüsselte Seiten als unsicher, zudem bevorzugen Suchmaschinen HTTPS-Webseiten für tendenziell besseres Ranking. Voraussetzung für die Einrichtung einer sicheren HTTPS-Verbindung ist ein vertrauenswürdiges Zertifikat, dieses von Zertifizierungsstellen (Certificate Authority, CA) ausgestellt werden.

Verschlüsselte Datenübertragung

Die verschlüsselte Datenübertragung zwischen Client und Server erfolgt anschliessend per SSL/TLS. In der Regel sind diese Zertifikate nicht kostenlos erhältlich – doch es gibt kostenlose Alternativen wie die Let’s Encrypt Initiative. In dieser Anleitung wird ein SSL-Zertifikat mit Let’s Encrypt selbst erstellt, für Windows IIS-Manager und Exchange Server.

Was ist Let’s Encrypt?

Die Certificate Authority (CA) Let’s Enrypt bietet seit Ende 2015 kostenlos und automatisiert SSL-Zertifikate an. Das erklärte Ziel: die Schaffung eines einfachen, kostenlosen und verschlüsselten Internets.

Let’s Encrypt mit Certify Certificate Manager

Let’s Encrypt stellt noch kein offizielles Tool zur Verfügung, um die ACME Challenge wie für Linux Server, auch auf einem Windows Server und Exchange Server durchzuführen. Da es jedoch ein offenes Protokoll ist, gibt es bereits diverse Tools, die alle auf den ACME Dienst von Let’s Encrypt zurückgreifen. Zu empfehlen ist hier Certify the web von Webprofusion. Zum aktuellen Zeitpunkt ist Certify the web mit der Version 4.1.6 für eine begrenzte Anzahl Zertifikate kostenlos erhältlich. Es ist das bisher einzige Tool mit GUI und bietet Premium-Funktionen wie die automatisierte Verlängerung der Zertifikate und Multidomain Zertifikate.

Certify The Web

Als Voraussetzung gilt für “Certify the web”, ist dass der Windows Server auf dem neusten Stand ist und IIS bereits installiert ist, die Webseite auf dem Webserver muss über Port 80 erreichbar sein. Außerdem muss man eine Domain besitzen, und Zugriff haben auf deren DNS Einträge. Man fügt in der DNS-Zone der Domain, einen A-Record auf die IPv4 Adresse und einen AAAA-Record auf die IPv6 Adresse des Webservers ein.

Installation

Certify the web wird auf dem Server installiert, auf diesem IIS ausgeführt wird. Das kostenlose Tool kann man hier herunterladen, oder es wird in der Eingabeaufforderung mit „winget“ Windows Package Manager installiert.

winget install -e --id CertifyTheWeb.CertifySSLManager

Beim ersten start wird man begrüsst mit der Bitte, einen neuen Kontakt zu registrieren, über die E-Mail Adresse die man registriert, lässt Let’s Encrypt einem auf dem laufenden, und erinnert uns über die Laufzeit des Zertifikats.

Im IIS-Manager (inetmgr) wird als Bindung der Hostname mit dem Domainname eintragen, zum Beispiel web.shop.net.

Bindungen bearbeiten…

Unter Sites über der entsprechenden Site mit Rechtsklick das Kontextmenü öffnen und auf Bindungen bearbeiten gehen.

Sitebindung und Let’s Encrypt Zertifikat

Als Hostname wird hier web.shop.net eingetragen.

Certify Start

Jetzt den “Certify the web” Manger starten, um für die Domain ein CA Zertifikat anfordern zu lassen.

Man Klickt auf New Certificate um eine neues Zertifikat ausstellen zu lassen, nach dem man im Feld Add domains to certificate den Domainname einträgt und auf den Button ADD DOMAIN klickt.

Mit klick auf Request Certificate wird das Zertifikat angefordert und automatisch installiert.

ACME auf Exchange Server

Zertifikat für IIS und Exchange mit ACME Lets Encrypt ausstellen. Die CA von Let’s Encrypt stellt Zertifikate auch für SAN (Subject Alternative Name) Zertifikate aus, Wildcard-Zertifikate werden seit Anfang 2018 unterstützt.

Für öffentlich zugäng­liche Web­sites sind SSL-Verbin­dungen mittler­weile Standard, und selbiges sollte auch für Exchange gelten. Let’s Encrypt betreibt eine freie CA, die Zerti­fikate nicht nur kosten­los, sondern auch weit­gehend automa­tisiert ausstellt. Diese Anleitung zeigt das Vorgehen für IIS und Exchange.

Zur Verifikation, ob der Antragsteller jener ist, der die Domäne kontrolliert, für die er ein Zertifikat beanträgt, setzt Let’s Encrypt das ACME-Protokoll (Automatic Certificate Management Environment) ein.

Bei jeder Methode die zur Verifizierung der Domain verwendet wird, muss der FQDN über ein öffentlichen DNS-Server auflösbar und der Host auf Port 80 aus dem Internet erreichbar sein.

Das gilt auch, wenn man sich für die Verifizierung mittels Datei entscheidet, die der Client auf den lokalen Rechner herunterlädt. Diese muss dann auf den Host kopiert werden und dort für Let’s Encrypt zugänglich sein. Damit der ACME-Client die Hostnamen aus der IIS-Konfiguration ermitteln kann, muss im IIS-Manager sichergestellt werden, dass HTTP bei den gewünschten Sites an die jeweiligen FQDN gebunden ist.

Zertifikat anfordern

Das interaktive Tool win-acme kann hier heruntergeladen werden, nach dem entpacken wird in einem als Administrator geöffneten Comand Prompt wacs.exe ausgeführt.

Wir wählen hier also M Create new certificate (full options) für ein SAN Certificate. Seit Exchange 2013 werden zwei IIS-Sites verwendet, die ein Zertifikat benötigen. Danach wählen wir als Methode die Option 3 „[http-01] Create temporary application in IIS“.

Nach erfolgreicher Ausstellung des Zertifikats legt wacs.exe das Zertifikat unter C:\ProgramData\win-acme\httpsacme-v01.api.letsencrypt.org ab.

Dienste IIS SMTP IMAP

Exchange hat an dieser Stelle noch nicht für jeden Dienst ein Zertifikat. Das kann man manuell in der ECP-Konsole erledigen, oder aber das hierfür bereitgestellte Script ImportExchange.ps1 werwenden.

Interactive ausführung in Exchange Command Prompt (wacs.exe)

Create certificate with full options
 Manually input host names
 [http-01] Self-host verification files
 Create or update https bindings in IIS
 Would you like to add another installer step? (y/n): Y
 Run a custom script
 Would you like to add another installer step? (y/n): N
 Choose site to create new bindings: Default Web Site (or where ever OWA is at)
 Enter the path to the script that you want to run after renewal: ./Scripts/ImportExchange.ps1
 Enter the parameter format string for the script: '{CertThumbprint}' 'IIS,SMTP,IMAP' 1 '{CacheFile}' '{CachePassword}' '{CertFriendlyName}'

Es muss sichergestellt sein, das aufgrund der 90 Tage begrenzten Gültigkeit des Zertifikats, das dessen Erneuerung nicht verpasst wird. Am besten erstellt man hierfür ein geplanten Task. Dieser sollte nicht nur den ACME-Client mit dem renew-Parameter enthalten, sondern auch die zuweisung der Dienste.

Copy
Die mobile Version verlassen