In der BW-Cloud wird für Forschung und Lehre die Installation eines Magento-eShops auf Ubuntu 16.04 zum Einsatz kommen. Die Student*Innen nutzen hierfür eine Instanz. Nachdem der eShop in einer Minimalausstattung vorliegt, soll der Umzug dieses eShops auf eine andere virtuelle Maschine realisiert werden, wieder zu Übungszwecken. Hierfür wird eine zweite Instanz zum Einsatz kommen. Soweit der Plan.
Diese virtuelle Maschine wird also wieder in der BW-Cloud laufen und mit der Ubuntversion 20.04 ausgestattet sein (z.B.). Darauf läuft dann die Magentoversion 2.X. (z.B.) Es gilt also von einer Ubuntu-Magento-Kombination älterer Natur auf eine Ubuntu-Magento-Kombination aktueller Version umzuziehen. Wie gesagt, alles zu Übungszwecken, um die „Update-Rituale“ in der Cloud zu üben und in den Griff zu bekommen. Soweit als überschaubar und in (vielen) vergangenen Semestern eine Routine. Insbesondere für die MAC-User*Innen: diese Student*Innen-Gruppen arbeiten mit dem den MAC-Terminal als call level interface/command line interface (kurz CLI). Die Terminal-App ist in MACOS standardmässig vorhanden und kennt i.d.R. alle SSH-Kommandos, die für die Remote-Arbeit in der Cloud nahezu unerlässlich ist.
Für uns bedeutet das konkret, dass sich die Studierenden mit der MAC-Terminal-App und mit SSH-Kommandos mit den virtuellen Maschinen in der BW-Cloud verbinden, einloggen und damit aus der Ferne arbeiten können. Wer nicht vor einem MAC sitzt, sondern vor einem Windows-Laptop, konnte bislang nicht mit den SSH-Kommandos arbeiten, insbesondere nicht mit den Windows-Versionen vor Version Windows 10.
Secure Shell (ssh) ist ein Standardwerkzeug, das in den meisten “Netzwerk”-Betriebssystemen enthalten ist, d. h. Linux, UNIX, MacOS, usw…
Drittanbieter-Anwendung
In der Vergangenheit benötigte Windows eine Drittanbieter-Anwendung, um überhaupt einen brauchbaren ssh-Client zu erhalten. Für Benutzer, die eine sichere Verbindung zum Rest der Welt mit einer Befehlszeilenschnittstelle benötigten, war PuTTY eine übliche Ergänzung. Nach mehreren Jahrzehnten hat Microsoft endlich einen nativen ssh-Client UND -Server unter Windows! Sowohl der Client als auch der Server sind Standard (und in stabilen Versionen) auf Windows 10 seit dem 1809 “Oktober Update”.
Soweit der aktuelle Stand, objektiv.
Subjektiv: weil es eben die Drittanbieter-Anwendungen putty und puttygen gibt, bevorzugen Windowsanwender*Innen eben diese Drittanbieter-Anwendungen – so die Erfahrungen in der Lehre. Auch recht!
Auch sicher: Terminals treffen nicht jedermanns/jederfrau Geschmack. Und klar ist auch: die intuitiver Unterstützung, so wie es eine GUI anbietet, fehlt komplett. Eine herbe Schönheit und sehr spartanisch!
Wenn wir nicht zu genau hinschauen, könnten wir sagen, PuTTY und SSH sind insofern kompatibel, dass beide Werkzeuge in etwa das gleich leisten: Schlüssel generieren und Verbindungen zu remote Computern zu beherschen. Die Philosophien von PuTTY und SSH unterscheiden sich aber beispielsweise schon darin, wenn es darum geht, Schlüssel zu generieren. SSH generiert selbstredend ssh-Schlüssel, puttygen muss das explizit gesagt werden… Auch wenn es um die Dateinamen für die Schlüsselpaare geht, haben PuTTY und SSH andere Ansichten: öffentliche Schlüssel haben i.d.R keine File-Extension und private Schlüssel arbeiten in der PuTTY-Welt i.d.R mit der Extension „.ppk“, während in der SSH-Welt durchaus die Extension „.txt“ passt. Und last but not least: natürlich passen ppk-Schlüssel nicht als private Schlüssel für den Austausch mittels SSH. (Hier sei aber der Vollständigkeit halber erwähnt, dass puttygen den ppk-Schlüssel konvertieren kann in eine SSH-Schlüssel als txt-Datei, der dann von der SSH verwendet werden kann…)
Das Schlüsselerlebnis
Das Hantieren und der Umgang mit Schlüsseln versetzt uns in die Lage, den Log-In-Vorgang in den remote Computer auf sichere Art zu automatisieren, weil wir vor allem kein Passwort brauchen, sondern eben über die SSH und den PuTTY unseren privaten Schlüssel nutzen können. Der Preis dafür: vorher die Auseinandersetzung mit Schlüsseln und die Schlüssel herstellen zu müssen. (Na gut, das müssen wir nur einmal machen, i.d.R, im Vergleich zum häufigen LogIn in den remote Computer).
Die Vereinfachungsmöglichkeit, für unseren Anwendungsfall
Da die SSH ein Standard ist, wäre die erste Möglichkeit in unserem Anwendungsfall „Schlüssel für die BW-Cloud“ Instanzen, besteht darin, sich als Window10-User*In in die SSH einzuarbeiten. Damit könnten sich Windows-User*Innen und Mac-User*Innen auch kommunikativ austauschen 😊 Diese Vereinfachung hätte also eine gewisse Teamverbindende Wirkung.
Windows 10 Build 1809
OpenSSH ist ein Konnektivitätstool für die Remoteanmeldung, das das SSH-Protokoll verwendet. Es verschlüsselt den gesamten Datenverkehr zwischen Client und Server, um Lauschangriffe, Verbindungsübernahmen und andere Angriffe zu verhindern.
OpenSSH kann verwendet werden, um Verbindungen zwischen Windows 10-Clients und beliebigen SSH-Servern (z.B. in BW-Cloud) und auch Windows Server 2019 herzustellen. Der OpenSSH-Client kann unter Windows 10 Build 1809 und höher installiert werden, während OpenSSH Server für die Installation unter Windows Server 2019 und höher verfügbar ist.
SSH auf Windows 10 installieren: Mehr dazu hier! (Lesedauer 2 Minuten)
Schlüssel in der Cloud machen lassen
Die zweite Möglichkeit der Vereinfacht wird durch die BW-Cloud angeboten: man/frau kann das notwendige und gewünschte Schlüsselpaar einfach mit der BW-Cloud machen (mit der dort integrierten SSH-Funktionalität, über den Web-Browser bedienbar. Diese Funktionalität bietet sich an, wenn die Instanz kreiert wird – denn für den Zugang zu der Instanz wird ja das Schlüsselpaar benötigt und gebraucht, also am Beste doch gleich beim herstellen der Instanz auch das Schlüsselpaar machen. Der öffentliche Schlüssel liegt dann auch gleich an der richtigen Stelle in der neu geschaffenen Instanz und den privaten Schlüssel lässt sich mittel copy+paste leicht als Text auf den persönlichen, lokalen Laptop holen und dann auf dem MAC etwa im Verzeichnis $HOME/.ssh abspeichern. Aus Gründen der Kompatibilität wurde man auf Windows das Verzeichnis auch so bezeichnen. Ein Restrisiko soll nicht unerwähnt bleiben: wenn dass Schlüsselpaar in der Cloud gemacht wird, entsteht natürlich auch private Schlüssel in der Cloud und wir müssen uns darauf verlassen, dass der Cloud-Betreiber keinen Unsinn mit dem privaten Schlüssel macht (und ihn vernichtet, nach dem wir ihn auf den privaten Rechner geholt haben.)
Raus aus Online-Meetings
Für die hier dargestellte Vorgehensweise sollten Sie sich NICHT in einem Online-Meeting befinden! Machen Sie alle Schritte, ohne dass gleichzeitig eine Online-Meeting-Software aktiv ist. Es muss reichen, wenn Ihr Laptop mit dem Browser in der BW-Cloud ist. Auf diese Weise laufen die Maßnahmen zu „Schlüsselpaar anlegen“ zuverlässig, während gleichzeitig aktive Online-Meeting-Software erhebliche Performanceprobleme verursachte und die Maßnahmen zum Scheitern bringen (können) – abhängig von verschiedenen Faktoren, die die Performance des genutzten Computers beeinflussen.
