Tutoriales

HTTP (S) / WS (S) / TCP-Tunnel zu Localhost, die nur SSH verwenden

Sish ist eine Open-Source-Serveo / Ngrok-Alternative.

Builds werden automatisch für jedes Commit für das Repo erstellt und an Dockerhub gesendet. Builds werden mit einem Commit sha, einem Filialnamen, einem Tag und dem neuesten Tag versehen, wenn sie auf main veröffentlicht werden. Eine Liste finden Sie hier. Jede Version wird separat erstellt sish Binärdateien, die von hier für verschiedene Betriebssysteme / Bögen heruntergeladen werden können. Sie können entweder die automatisierten Binärdateien verwenden oder Ihre eigenen erstellen. Wenn Sie eine PR einreichen, werden Bilder nicht standardmäßig erstellt und erfordern die Erstellung eines Retags von einem Betreuer.

docker pull antoniomika/sish:latest

docker run -itd –name sish -v ~ / sish / ssl: / ssl -v ~ / sish / keys: / keys -v ~ / sish / pubkeys: / pubkeys –net = host antoniomika / sish: latest –Ssh-address =: 22 –http-address =: 80 –https-address =: 443 –https = true –https-Zertifikatsverzeichnis = / ssl –authentication-keys-directory = / pubkeys –Private-key-location = / keys / ssh_key –bind-random-ports = false

  • SSH an Ihren Host, um mit sish zu kommunizieren

ssh -p 2222 -R 80:localhost:8080 ssi.sh

Docker Compose

Sie können Docker Compose auch verwenden, um Ihre sish-Instanz einzurichten. Dies beinhaltet die Pflege von SSL über Let’s Encrypt für Sie. Hierbei wird der adferrand / dnsrobocert-Container verwendet, um die Ausstellung von Platzhalterzertifizierungen über DNS zu handhaben. Weitere Informationen zur Verwendung finden Sie unter dem obigen Link. Im Allgemeinen können Sie Ihren Dienst folgendermaßen bereitstellen:

docker-compose -f deploy / docker-compose.yml up -d

Die Domain- und DNS-Authentifizierungsinformationen in deploy/docker-compose.yml und deploy/le-config.yml sollte aktualisiert werden, um Ihre Bedürfnisse widerzuspiegeln. Sie müssen auch einen Symlink erstellen, der auf die Let’s Encrypt-Zertifikate Ihrer Domain verweist, z.

In -s / etc / letsencrypt / live / /fullchain.pem deploy / ssl / .crt
In -s / etc / letsencrypt / live / /privkey.pem deploy / ssl / .key

Achtung: Die Symlinks müssen darauf verweisen /etc/letsencrypt, kein relativer Pfad. Die Symlinks werden nicht auf dem Host-Dateisystem aufgelöst, aber sie werden innerhalb des sish-Containers aufgelöst, da die letsencrypt-Dateien in / etc / letsencrypt bereitgestellt werden. nicht ./letsencrypt.

Ich verwende diese Dateien in meiner Bereitstellung von ssi.sh und haben sie hier aus Gründen der Konsistenz aufgenommen.

Google Cloud Platform

Es gibt ein Tutorial zum Erstellen einer Instanz in Google Cloud Platform mit vollständig eingerichtetem Sish, das Sie hier finden. Der Zugriff erfolgt über Google Cloud Shell.

Wie es funktioniert?

SSH kann normalerweise lokale und Remote-Ports weiterleiten. Dieser Dienst implementiert einen SSH-Server, der nur die Weiterleitung und sonst nichts übernimmt. Der Dienst unterstützt das Multiplexen von Verbindungen über HTTP / HTTPS mit WebSocket-Unterstützung. Weisen Sie einfach einen Remote-Port als Port zu 80 zum Proxy-HTTP-Verkehr und 443 zum Proxy-HTTPS-Verkehr. Wenn Sie einen anderen Remote-Port verwenden, überwacht der Server den Port auf TCP-Verbindungen, jedoch nur, wenn dieser Port verfügbar ist.

Sie können Ihre eigene Subdomain auswählen, anstatt sich auf eine zufällig zugewiesene zu verlassen, indem Sie die Option festlegen --bind-random-subdomains Option zu false und dann Auswählen einer Subdomain durch Voranstellen an den Remote-Port-Bezeichner:

ssh -p 2222 -R foo:80:localhost:8080 ssi.sh

Wenn die ausgewählte Subdomain nicht belegt ist, wird sie Ihrer Verbindung zugewiesen.

Unterstützte Weiterleitungstypen

sish kann beliebig viele HTTP-Verbindungen über SSH weiterleiten. Außerdem können Sie die Verbindungen zu dem verbundenen Client protokollieren, der die Verbindung weitergeleitet hat, sowie eine Weboberfläche, um die vollständigen Anforderungen und Antworten für jede weitergeleitete Verbindung anzuzeigen. Jedes Webinterface kann für die weitergeleitete Verbindung eindeutig sein oder ein einheitliches Zugriffstoken verwenden. Um die HTTP-Weiterleitung zu nutzen, müssen Ports [80, 443] werden verwendet, um sish mitzuteilen, dass eine HTTP-Verbindung weitergeleitet wird und dass das virtuelle HTTP-Hosting für den Dienst definiert werden sollte. Angenommen, ich entwickle einen HTTP-Webservice auf meinem Laptop am Port 8080 das benutzt Websockets und ich möchte einem meiner Kollegen zeigen, der nicht in meiner Nähe ist. Ich kann die Verbindung so weiterleiten:

ssh -R hereiam: 80: localhost: 8080 ssi.sh

Und dann teilen Sie den Link https://hereiam.ssi.sh mit meinem Kollegen. Sie sollten in der Lage sein, nahtlos über HTTPS auf den Dienst zuzugreifen, wobei die vollständige Unterstützung des Websockets einwandfrei funktioniert. Sagen wir hereiam.ssi.sh ist nicht verfügbar, dann generiert sish eine zufällige Subdomain und gibt sie mir.

Jeder TCP-basierte Dienst kann mit sish für die TCP- und Mote-Weiterleitung verwendet werden. Durch die TCP-Weiterleitung wird ein Remote-Port auf dem Server eingerichtet, auf dem Sie sish bereitstellen, und alle Verbindungen werden über die SSH-Verbindung und an Ihr lokales Gerät an diesen Port weitergeleitet. Zum Beispiel, wenn ich einen SSH-Server auf meinem Laptop mit Port ausführen sollte 22 und möchten von überall auf darauf zugreifen können ssi.sh:2222Ich kann einen SSH-Befehl auf meinem Laptop verwenden, um die Verbindung weiterzuleiten:

ssh -R 2222: localhost: 22 ssi.sh

Über die weitergeleitete Verbindung kann ich von überall auf meinen Laptop zugreifen:

ssh -p 2222 ssi.sh

Angenommen, ich möchte nicht, dass der Rest der Welt auf den Dienst zugreifen kann. Sie können dann einen TCP-Mote ​​verwenden. Ein TCP-Mote ​​ist eine Art weitergeleitete TCP-Verbindung, die nur innerhalb von sish besteht. Sie können auf den Mote ​​zugreifen, indem Sie SSH mit dem verwenden -W Flag, das den SSH-Prozess ‘stdin / stdout’ an die vorwärtsgerichtete TCP-Verbindung weiterleitet. In Kombination mit der Authentifizierung wird dadurch sichergestellt, dass Ihr Remote-Dienst vor dem Rest der Welt sicher ist, da Sie sich anmelden müssen, um sish zu verwenden, bevor Sie darauf zugreifen können. Wenn Sie das obige Beispiel ändern, müssen Sie den folgenden Befehl auf meinem Laptop ausführen:

ssh -R mylaptop: 22: localhost: 22 ssi.sh

sish veröffentlicht Port 22 oder 2222 nicht mehr für den Rest der Welt, sondern behält einen Zeiger bei, der besagt, dass TCP-Verbindungen innerhalb von SSH hergestellt wurden, nachdem sich ein Benutzer bei authentifiziert hat mylaptop:22 sollte an den weitergeleiteten TCP-Tunnel weitergeleitet werden. Dann kann ich über die weitergeleitete Verbindung von überall auf meinen Laptop zugreifen:

ssh -o ProxyCommand = «ssh -W% h:% p ssi.sh» mylaptop

Abkürzung dafür ist dies bei neueren SSH-Versionen:

ssh -J ssi.sh mylaptop

Authentifizierung

Wenn Sie diesen Dienst privat nutzen möchten, unterstützt er sowohl die Authentifizierung mit öffentlichem Schlüssel als auch mit Kennwort. Um die Authentifizierung zu aktivieren, legen Sie fest --authentication=true als eine Ihrer CLI-Optionen und stellen Sie sicher, dass Sie konfigurieren --authentication-password oder --authentication-keys-directory nach Ihren Wünschen. Das von bereitgestellte Verzeichnis --authentication-keys-directory wird auf Änderungen überwacht und lädt die autorisierten Schlüssel automatisch neu. Der autorisierte Zertifikatsindex wird bei der Verzeichnisänderung neu generiert, sodass entfernte öffentliche Schlüssel ebenfalls automatisch entfernt werden. Dateien in diesem Verzeichnis können entweder ein einzelner Schlüssel pro Datei oder mehrere Schlüssel pro Datei sein, die durch Zeilenumbrüche getrennt sind, ähnlich wie authorized_keys. Die Kennwortauthentifizierung kann durch Festlegen deaktiviert werden --authentication-password="" als CLI-Option.

Eine meiner bevorzugten Möglichkeiten, dies für die Authentifizierung zu verwenden, ist folgende:

sish @ sish0: ~ / sish / pubkeys # curl https://github.com/antoniomika.keys> antoniomika

Dadurch werden meine öffentlichen Schlüssel von GitHub geladen, in das Verzeichnis gelegt, das sish gerade überwacht, und dann wird der Pubkey geladen. Sobald dieser Befehl ausgeführt wird, kann ich natural SSH und er wird mich autorisieren.

Benutzerdefinierte Domänen

sish unterstützt das Ermöglichen, dass Benutzer benutzerdefinierte Domänen zum Dienst bringen, die SSH-Schlüsselauthentifizierung muss jedoch aktiviert sein. Um diese Funktion nutzen zu können, müssen Sie TXT- und CNAME / A-Einträge für die Domain / Subdomain einrichten, die Sie für Ihre weitergeleitete Verbindung verwenden möchten. Der CNAME / A-Eintrag muss auf die Domain oder IP verweisen, die sish hostet. Der TXT-Datensatz muss a sein key=val Zeichenfolge, die aussieht wie:

sish = SSHKEYFINGERPRINT

Wo SSHKEYFINGERPRINT ist der Fingerabdruck des Schlüssels, der für die Anmeldung am Server verwendet wird. Sie können mehrere TXT-Datensätze festlegen, und sish überprüft alle Datensätze, um sicherzustellen, dass mindestens einer übereinstimmt. Sie können Ihren Schlüsselfingerabdruck abrufen, indem Sie Folgendes ausführen:

ssh-keygen -lf ~ / .ssh / id_rsa | awk ‘print $ 2’

Wenn Sie den Benutzern vertrauen, die eine Verbindung zu sish herstellen, und die Verwendung einer Domain mit sish zulassen möchten (Umgehung der Überprüfung), gibt es einige zusätzliche Flags, die dies unterstützen. Dies ist besonders nützlich, wenn Sie mehrere Platzhalterzertifikate zu sish hinzufügen, um nicht automatisch Let’s Encrypt-Zertifikate bereitstellen zu müssen. Um die Überprüfung zu deaktivieren, setzen Sie --bind-any-host=true, wodurch die Kombination von Subdomain und Domain verwendet werden kann. Um nur Subdomains einer bestimmten Teilmenge von Domains zuzulassen, können Sie festlegen --bind-hosts zu einer durch Kommas getrennten Liste von Domänen, die gebunden werden dürfen.

Konfigurieren Sie die, um Zertifikate für die Verwendung von sish hinzuzufügen --https-certificate-directory flag, um auf ein Verzeichnis zu zeigen, auf das sish zugreifen kann. Im Verzeichnis sucht sish nach einer Kombination von Dateien, die so aussehen name.crt und name.key. name kann in beiden Fällen beliebig sein, es muss nur für das Zertifikat- und Schlüsselpaar eindeutig sein, damit sie in sish geladen werden können.

Lastverteilung

sish kann jede Art von weitergeleiteter Verbindung ausgleichen, dies muss jedoch aktiviert sein, wenn sish mit dem gestartet wird --http-load-balancer, --tcp-load-balancer, und --alias-load-balancer Flaggen. Angenommen, Sie haben einige Edge-Knoten (Himbeer-Pis), auf denen ein Dienst intern ausgeführt wird, möchten jedoch in der Lage sein, die Last von außen auf diese Geräte zu verteilen. Durch Aktivieren des Lastausgleichs in sish geschieht dies automatisch, wenn ein Gerät mit demselben weitergeleiteten TCP-Port, Mote ​​oder derselben HTTP-Subdomain eine Verbindung zu sish herstellt. Die Verbindungen werden dann gleichmäßig auf alle Knoten verteilt, die mit der weitergeleiteten Verbindung übereinstimmen.

Whitelisting IPs

Es ist auch möglich, IP-Bereiche oder Länder auf die Whitelist zu setzen. Ganze CIDR-Bereiche können mit dem angegeben werden --whitelisted-ips Option, die eine durch Kommas getrennte Zeichenfolge wie «192.30.252.0/22,185.199.108.0/22» akzeptiert. Wenn Sie eine einzelne IP auf die Whitelist setzen möchten, verwenden Sie die /32 Reichweite.

Verwenden Sie, um Länder auf die Whitelist zu setzen --whitelisted-countries mit einer durch Kommas getrennten Folge von Ländern im ISO-Format (z. B. „pt“ für Portugal). Sie müssen auch einstellen --geodb zu true.

DNS-Setup

Um sish verwenden zu können, müssen Sie einen Platzhalter-DNS-Eintrag hinzufügen, der für gemultiplexte Subdomänen verwendet wird. Hinzufügen eines A aufnehmen mit * Die Subdomain zur IP-Adresse Ihres Servers ist der einfachste Weg, um diese Konfiguration zu erreichen.

Demo – Zu diesem Zeitpunkt wurde für die Demo-Instanz festgelegt, dass aufgrund von Missbrauch eine Authentifizierung erforderlich ist

Derzeit läuft ein Demo-Dienst (und meine private Instanz) ssi.sh das erfordert keine Authentifizierung. Dieser Dienst bietet Standardprotokollierung (Fehler, Verbindungs-IP / Benutzername und Pubkey-Fingerabdruck). Ich protokolliere keine der Kennwortauthentifizierungsdaten oder der innerhalb des Dienstes / Tunnels gesendeten Daten. Meine Bereitstellung verwendet die genauen Bereitstellungsschritte, die oben aufgeführt sind. Diese Instanz dient nur zu Test- und Bildungszwecken. Sie können dies sehr einfach auf jedem Host bereitstellen (Google Cloud Platform bietet eine immer kostenlose Instanz, auf der dies perfekt ausgeführt werden sollte). Wenn der Dienst viel Verkehr aufbaut, aktiviere ich die Authentifizierung und Sie können sich an mich wenden, um Ihren SSH-Schlüssel auf die Whitelist zu setzen (stellen Sie sicher, dass er auf GitHub ist und Sie mir Ihren GitHub-Benutzernamen geben).

Anmerkungen

  1. Dies ist in keiner Weise produktionsbereit. Dies wurde zusammen gehackt und löst einen ziemlich spezifischen Anwendungsfall.
    • Sie können dazu beitragen, die Produktion vorzubereiten, indem Sie PRs einreichen / Code überprüfen / Tests schreiben / etc.
  2. Dies ist eine ziemlich einfache Implementierung. Ich habe an einigen Stellen absichtlich Ecken abgeschnitten, um das Schreiben zu vereinfachen.
  3. Wenn Sie Fragen oder Kommentare haben, wenden Sie sich bitte per E-Mail an [email protected] oder über freenode IRC #sish

Upgrade auf v1.0

Zwischen den Versionen vor 1.0 und nach 1.0 gibt es zahlreiche wichtige Änderungen bei sish. Die größten Änderungen finden sich in der Zuordnung von Befehlsflags und Konfigurationsparametern. Diese haben sich drastisch geändert, aber es sollte einfach sein, das neue Gegenstück zu finden. Die andere Änderung sind SSH-Schlüssel, die für die Hostschlüsselauthentifizierung unterstützt werden. sish unterstützt weiterhin die meisten modernen Schlüssel. Wenn jedoch kein Hostschlüssel gefunden wird, wird standardmäßig ein OpenSSH ED25519-Schlüssel zur Verwendung erstellt. Frühere Versionen von sish haben den PEM-Block dieses privaten Schlüssels verschlüsselt, aber seitdem haben wir das native OpenSSH-Format für private Schlüssel verwendet, um eine einfache Interaktion zwischen OpenSSH-Tools zu ermöglichen. Aus diesem Grund müssen Sie entweder einen AES-verschlüsselten Schlüssel manuell konvertieren oder einen neuen generieren.

Publicaciones relacionadas

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Botón volver arriba