Derzeit haben wir einige Labore, in denen sich alle Instanzen außer Bastion VM in einem privaten Subnetz befinden. Entwickler müssen daher einen SSH-Tunnel von ihrem Laptop zu Bastion und einen weiteren Tunnel von Bastion zu einem Microservice erstellen, damit sie auf die Benutzeroberfläche zugreifen können.
Der Ablauf sieht folgendermaßen aus:
ssh -i <key>.pem -L <port x>:localhost:<port x> user@<hostname of Bastion>
User logged in to Bastion VM.
ssh -i <key>.pem -L <port x>:<hostname of microservice>:<port of microservice> user@<hostname of microservice>
Now they are able to access UI at http://localhost:<port x>
Da dies für den alltäglichen Gebrauch eine ziemlich komplexe und zeitaufwändige Aufgabe ist, dachte ich daran, eine Software zu entwickeln, die so konfiguriert werden kann, dass sie dasselbe mit einem Klick erledigt.
ich fand herausSichere Rohre, aber ich bin mir nicht sicher, wie ich es für meinen Zweck verwenden soll. Kann jemand eine Alternative vorschlagen, um das oben genannte mit einer anderen Software zu erreichen?
Antwort1
Es ist komplex, weil Sie es auf komplexe Weise tun. OpenSSH verfügt bereits über Mechanismen zur Vereinfachung dieser Art häufiger Verbindungen. (Notiz:Dieser Beitrag geht davon aus, dass der Entwickler private Schlüssel hat fürbeideVerbindungen auf dem lokalen Computer, d. h. der Bastion-Host verfügt nicht über einige nicht kopierbare Anmeldeinformationen.)
Finden Sie zunächst einen Weg, es auf einen SSH-Befehl zu komprimieren. Dadurch wird das Tunneln tatsächlich etwas umgekehrt, da der Bastion-Host nun die SSH-Verbindung und nicht die Webverbindungen weiterleitet.
ssh -i <key>.pem -o ProxyCommand="ssh -i <key>.pem -W %h:%p user@<bastion>" -L <portX>:<microservice>:<mport> user@<hostname>
In sehr aktuellen OpenSSH-Versionen kann es durch die Verwendung von -J/ JumpHostanstelle des manuellen ProxyCommands weiter vereinfacht werden:
ssh -i <key>.pem -J user@<bastion> -L <portX>:<microservice>:<mport> user@<hostname>
Konvertieren Sie dies nun in die Optionen ~/.ssh/config – identifizieren Sie diejenigen, die für die Verbindung mit dem Bastion-Host selbst erforderlich sind, diejenigen, die für die Service-Hosts gelten, und diejenigen, die für alle gemeinsam sind (die Abschnitte „Host“ akzeptieren mehrere Namen und sogar Platzhalter):
Host <bastion>
User <user>
IdentityFile <key>.pem
Host <hostname>
User <user>
IdentityFile <key>.pem
#JumpHost <bastion>
ProxyCommand ssh -W %h:%p <bastion>
Wenn dies eingerichtet ist (was zentral bereitgestellt werden kann), lautet Ihr Befehl nur noch:
ssh -L <portX>:<microservice>:<mport> <hostname>
(Es gibt auch eine Möglichkeit, die Unternehmensdomäne automatisch anzuhängen. Wenn der Server beispielsweise svc1.dev.example.com heißt, können Sie mit Hostname %h.dev.example.comoder ausführen .)CanonicalDomains dev.example.comssh svc1
So einfach kann eine generische Methode kaum sein – die verbleibenden vier Parameter sind von Natur aus variabel (je nach den Anforderungen des jeweiligen Entwicklers), sodass der Benutzer selbst dann, wenn Sie eine grafische Benutzeroberfläche darüber klatschen, die gleiche Menge an Informationen bereitstellen muss. (Funktioniert mit OpenSSH auf jedem Betriebssystem.)
Das heißt, wenn dieDasselbeTunnel werden jedes Mal aufgebaut, sie können auch in ~/.ssh/config ( -Lentspricht LocalForward) codiert werden, und das Dev muss nur ausgeführt werden ssh <hostname>.
(Praktisch jedes Betriebssystem, das OpenSSH ausführen kann, unterstützt auch Skripte, die im Allgemeinen in sh/bash geschrieben sind, und/oder Befehlsaliase.)