by In letzter Zeit habe ich mich viel mit dem Thema Ansible und Vagrant beschäftigt. Nur zum Verständnis….während du mit Ansible dein komplettes Netzwerk automatisierst (vom Switch, über Router, Firewall, Server und Clients), dient Vagrant zum Automatisieren von Umgebungen für Virtuellen Maschinen (VM). Sprich das erstellen, konfigurieren und löschen von VM. Das spart extrem viel Zeit, wenn du zum Beispiel 3 VM (und das sind noch wenig) parallel aufsetzen willst, um einen Webserver, eine Datenbank und einen Webclient in einer Testumgebung (aber auch im realen Einsatz) benötigst. Warum alle 3 Schritte nacheinander machen mit viel manuellen Hick Hack, wenn das auch automatisiert in eine Rutsch geht? Das kannst du dir ähnlich wie Docker vorstellen, nur Docker virtualisiert Umgebungen für einzelne Anwendungen (Apps oder Dienste) und Vagrant vollwertige Betriebssysteme – macht Dinge zwar ähnlich, aber mit einem anderen Ziel.
Ziel dieses Blogbeitrages ist es aufzuzeigen, wie du in einer Windows-Umgebung Vagrant installierst und grundlegend nutzt. Die Nutzung in einer Linux-Umgebung ist nicht viel anders, Anleitungen findest du da genug (für Windows leider nicht). Ich empfehle dir ausdrücklich nicht, für Vagrant Windows WSL oder WSL2 zu nutzen, das schafft mehr Probleme als Lösungen.
Aber eines ist für Windows-Nutzer noch wichtig. Wie ich bereits in einem andere Blog-Beitrag erwähnt habe, vertragen sich manchmal mehrere verschiedene Virtualisierungs-Hosts nicht miteinander. Vor allem der Hyper-V zickt da gerne rum. Installiere also VMWare oder Virtualbox (inkl. des Extension Packs) und deaktiviere Hyper-V, wenn der bereits laufen sollte. Möglicherweise bootet dein PC dabei neu. Öffne die Powershell mit administrativen Rechten und führe folgenden Befehl aus:
#Windows 10
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
#Windows 11
bcdedit /set hypervisorlaunchtype off
Die Installation setzt sich aus folgenden Schritten zusammen:
- Installation Virtualbox oder VMWare
- Installation Ruby für Windows
- ggf. manuelle Installation MSYS2
- Installation Vagrant für Windows
- Installation MobaXterm oder Putty, wenn du dich für die „falsche“ Pille entscheidest 😉
Installation
Was wir zuerst benötigen ist Ruby, das ist schnell installiert (du kannst die Version ohne DevKit nehmen.). Die Installation selbst beschreibe ich nicht weiter, du kannst die Standardeinstellungen des Installers so belassen.
Die Frage nach der Installationsvariante MSYS2 beantwortest du mit 1 („base installation“ reicht):
Solltest du eine Fehlermeldung bekommen, das der MSYS2 installer failed, dann gehe auf https://www.msys2.org/, lade den Installer dort manuell herunter und installiere diesen auf auf der dort beschrieben Art. Starten brauchst du MSYS2 nicht am Ende (Haken raus!, wenn doch passiert, einfach mit exit verlassen). Anschließen kannst du mit erneuten auswählen der MSYS2 base installation (1) den Erfolg prüfen.
Läuft also!
Bei Vagrant klickst du ebenfalls auf Download, dann Windows und empfehle dir in der heutigen Zeit die 64bit-Variante (es sei denn, du bist noch mit einem 32-bit-Windows unterwegs). Auch hier belassen wir die Standardeinstellungen des Installers. Den Vorgang beschreibe ich nicht weiter – das kannst du!
Nach einem erneuten Neustart war es das auch schon. Damit ist alles auf deinem System installiert, was zur Nutzung notwendig ist. Also machen wir uns auf zur ersten virtuellen Maschine
Virtuelle Maschinen mittels Vagrant installieren
An dieser Stelle ein paar Grundlagen, wie Vagrant arbeitet. Du wirst sehr viele Parallelen zu Docker auf der Kommandozeile feststellen. Du benötigst ein Arbeitsverzeichnis auf deiner Festplatte, indem du dein Vagrantfile (eine in Ruby geschriebene Initialisierungsdatei ablegst). Das Vagrantfile beschreibt das Provisioning der Umgebung für die virtuellen Maschinen. Bei Docker gibt es diese Provisioning-Datei ebenfalls – das sogenannte Dockerfile (in YAML geschrieben). Bei beiden werden in jeweils eigener Syntax die Arbeitsschritte bzw. Umgebungsvariablen definiert, die zum Bau der Laufzeitumgebung notwendig sind. So wie bei Docker du in jedem Arbeitsverzeichnis ein eigenes Dockerfile haben kannst, was am Ende zu vielen verschiedenen Docker-Umgebungen (WORDPRESS-Instanz parallel zu einer NGINX-PROXY-Instanz) führt – hast du bei Vagrant bei unterschiedlichen Arbeitsverzeichnissen mit je einem Vagrantfile auch unterschiedliche Sets von virtuellen Maschinen. Die können am Ende zwar alle auf einen Host laufen (ausreichend Arbeitsspeicher und Prozessorpower vorausgesetzt), sind aber netzwerkseitig voneinander separiert. Wenn du Änderungen am Provisioning (oder Neustart, anhalten) deiner Laufzeitumgebung machen möchtest, musst du dich mit cd <VERZEICHNIS> immer in das entsprechende Verzeichnis stellen und dann die entsprechenden Kommandos ausführen. Probieren wir das gleich aus:
Öffne die Kommandozeile CMD (Eingabeaufforderung) und gib dort ein vagrant box add hashicorp/bionic64 , gefolgt von ENTER.
Je nachdem, welchen Virtualisierungshost du benutzt (in meinem Beispiel hier 2- Virtualbox), wird dir eine Beispiel Ubuntu-VM von Hashicorp importiert (wohin, erkläre ich dir später). Abhängig von deiner Internetverbindung kann das einen Moment dauern.
Jetzt kommt der interessante Teil. Erstelle ein Verzeichnis für zukünftige Vagrant-Arbeitsumgebungen und dort gleich eines für eine erste Testumgebung. Wechsel dann in dieses Verzeichnis und lass dir von Vagrant eine INI-Datei für dein erstes kleines Projekt mit vagrant init hashicorp/bionic64 generieren – das bereits erwähnte Vagrantfile.
Starten kann du das ganze dann mit vagrant up, ich für meinen Fall habe noch die Option Provider ergänzt, da ich VMWare Workstation und Virtualbox parallel installiert habe und Vagrant mitteilen muss, welchen Provider ich nutzen möchte. Da nicht jeder bereit ist, ein wenig Geld für einen Virtualisierer wie VMWare auszugeben, beschreibe ich das ganze hier jedoch mit Virtualbox – klappt genausogut.
Wenn du anschließend Virtualbox startest, sieht du, das bereits eine neue VM gestartet wurde, der Name beginnt wie dein Unterverzeichnis test:
Ein Doppelklick zeigt dir einen Ubuntu-Login, kein Wunder bionic64 ist ja auch eine Ubuntu-Version.
Die Login-Daten findest du im Log, der dir nach vagrant up ausgegeben wurde. Dort kannst du auch entnehmen, dass die VM bereits per SSH erreichbar ist (bei mir hier im Beispiel 127.0.0.:1 Port 2200 mit dem Benutzer vagrant und als Authentifizierung einen private key. Keine Sorge, ein Passwort als Backup gibt es auch, der ist hier gleich der Benutzername, also auch vagrant. Wenn du diese Kombi bei der VM anwendest, bist du auch schon eingeloggt:
Der erfahrene IT-Admin weiß jedoch nur zu genau, das das arbeiten auf dieser „grafischen“ Console keinen Spaß macht. Copy & Paste funktioniert nicht immer sauber, die Auflösung lässt sich nicht flexibel ändern, die Schrift ist bei großen Monitoren oftmals viel zu klein und und und.
Wir wollen einen echten SSH-Zugang von einem Terminal-Client haben!
Du kannst als SSH-Client Putty verwenden (kennt nahezu jeder), ich empfehle dir jedoch MobaXterm, welches es auch in einer kostenlosen als auch portablen Version gibt. MobaXterm ist um Welten leistungsfähiger, wie du feststellen wirst. Einschränkungen hast du bei der kostenlosen zum Beispiel in der Anzahl an Sitzungen, aber selbst dann hast du noch erheblich mehr Leistungsumfang als bei Putty.
Du kannst dir dort direkt auf der Shell mit ssh vagrant@127.0.0.1 -p 2200 eine SSH-Verbindung zu deiner VM aufbauen…. (Passwort vagrant)
Klappt!
Wie du ja im Log nach vagrant up gelesen hast, kannst du dich auch mittels SSH-Key einloggen, also passwortlos. Aber wo befindet sich der private Key? Das ist recht einfach. In deinem Verzeichnis vagrant\test wurde ein verstecktes Unterverzeichnis .vagrant erstellt und darin befinden sich alle relevanten Daten
C:\Users\lmueller\vagrant\test>tree
Auflistung der Ordnerpfade
Volumeseriennummer : 92B2-5284
C:.
└───.vagrant
├───bundler
├───machines
│ └───default
│ ├───virtualbox
│ └───vmware_desktop
└───rgloaderBei dir wird es den Ordner vmware_desktop vermutlich nicht geben, aber schau mal in den Ordner virtualbox
C:\Users\lmueller\vagrant\test>dir .vagrant\machines\default\virtualbox
Volume in Laufwerk C: hat keine Bezeichnung.
Volumeseriennummer: 92B2-5284
Verzeichnis von C:\Users\lmueller\vagrant\test\.vagrant\machines\default\virtualbox
25.08.2023 11:29 <DIR> .
25.08.2023 11:28 <DIR> ..
25.08.2023 11:29 40 action_provision
25.08.2023 11:29 10 action_set_name
25.08.2023 11:29 144 box_meta
25.08.2023 11:29 1 creator_uid
25.08.2023 11:29 36 id
25.08.2023 11:29 32 index_uuid
25.08.2023 11:29 1.706 private_key
25.08.2023 11:29 134 synced_folders
25.08.2023 11:28 30 vagrant_cwd
9 Datei(en), 2.133 Bytes
2 Verzeichnis(se), 135.989.882.880 Bytes freiSiehe da, da liegt die Datei private_key. Kopiere die dir am besten in ein Verzeichnis deiner Wahl (damit der Pfad nicht zu lang wird) oder stelle zum Test sofort eine Verbindung mittels diesem private_key her, in MobaXterm hast du über /drives/….. übrigens Zugriff auf deine Festplatten im Windows-System (dazu später mehr). Also mit exit raus aus der aktuellen SSH-Sitzung und mittels Key neu verbinden (bedenke, das dein Verzeichnis sicherlich etwas anders heißt als hier im Screenshot (mindestens was den Benutzer betrifft))
Schön, das funktioniert also wie gewollt. Wenn du MobaXterm nutzt, empfehle ich dir zu Testzwecken den (unsicheren) Key mittels cat /drives/c/lmueller/vagrant/test/.vagrant/machines/default/virtualbox/private_key > ~/.ssh/private_key in das Standard-Verzeichnis für SSH-Keys in MobaXterm abzulegen und dir anschließend über die GUI ein Setup für den Zugriff anzulegen. Das geht ganz schnell über einen Klick auf Session.
Bei aktivierten „Use private key“ kannst du dann deinen Schlüssel, hier private_key auswählen. Achte ansonsten auf die korrekte Port-Nummer und die Angabe des Benutzer vagrant und dann kannst du mit einem Klick auf OK die SSH-Verbindung auch schon starten. Weiter unten erläutere ich noch, die du einen eigenen SSH-Key erzeugst und beim Generieren der VM den public key in die VM importierst.
Mit vagrant halt kannst du die VM herunterfahren, vagrant destroy löscht die VM-Umgebung. Achte dabei darauf, das du im selben Verzeichnis stehst, wo du am Anfang die INIT-Datei (Vagrantfile) generiert hast, hier also vagrant\test. Denn die vagrant-Befehle beziehen sich grundsätzlich auf das Vagrantfile in dem Verzeichnis, in dem du gerade stehst – aber das habe ich dir oben bereits erläutert. Ist wie bei Docker und docker compose up (oder ähnlich).
Der Vorteil liegt hier auf der Hand, du kannst mit vagrant up eine VM-Laufzeitumgebung erstellen und mit dieser arbeiten, mit vagrant halt kannst du die VMs herunterfahren. Nach einem erneuten vagrant up steht die Laufzeitumgebung so wie zuvor verlassen (also auch mit allen gemachten Änderungen) wieder zur Verfügung. Nur vagrant destroy löscht so gut wie alles außer dem Vagrantfile und dem Image, du kannst also mit vagrant up eine saubere, neue VM-Laufzeitumgebung starten – gerade in Laborumgebungen (liebevoll Lab genannt) zum Testen von Dingen ein Traum.
C:\Users\lmueller\vagrant\test>vagrant destroy
default: Are you sure you want to destroy the 'default' VM? [y/N] y
==> default: Forcing shutdown of VM...
==> default: Destroying VM and associated drives...Eigene SSH Keys
Mittels ssh-keygen kannst du dir ein eigenes Schlüsselpaar generieren, welches per default unter /home/.ssh abgelegt wird.
Öffne in MobaXterm eine neue Shell (+-Zeichen in der Tableiste) und führe das Kommando ssh-keygen aus. Beantworte die Fragen mit ENTER und du hast im Verzeichnis ~/.ssh die Dateien id_rsa (privater key) und id_rsa.pub (den öffentlichen Key) liegen. Damit du dich bei zukünftigen Laborumgebungen direkt mit deinem Standard-Key anmelden kannst, musst du den id_rsa.pub lediglich mit Vagrant verknüpfen. Kopiere die Datei id_rsa.pub nach C:\Users\<NAME>\vagrant\
cp ~/.ssh/id_rsa.pub /drives/c/lmueller/vagrant/Am Ende des jeweiligen Vagrantfiles (hier im Beispiel unter vagrant\test\Vagrantfile ) noch VOR dem end in der letzten Zeile folgenden Block einfügen. Also stehen am Ende zwei mal das end, siehe auch Screenshot
config.vm.provision "shell" do |s|
ssh_pub_key = File.readlines("/Users/lmueller/vagrant/id_rsa.pub").first.strip
s.inline = <<-SHELL
echo #{ssh_pub_key} >> /home/vagrant/.ssh/authorized_keys
echo #{ssh_pub_key} >> /root/.ssh/authorized_keys
SHELL
end
Wenn du dann mit vagrant up das Lab erneut startest, wirst du im Log feststellen, das der Hinweis auf den insecure_private_key noch immer vorhanden ist. Den kannst du jedoch ignorieren. Der Grund ist, das das importieren des eigenen Keys erst nach der Erstellung der VM erfolgt, sprich das ist bereits unsere erste Konfigurationänderung NACH Erstellung der VM – das nennt man Provisioning.
Kurz zur Erläuterung der Ruby-Anweisung:
- die 1. Zeile weist ein Provisioning an, also eine Systemkonfiguration
- die 2. Zeile weist der Variable ssh_pub_key den Inhalt der Datei id_rsa.pub zu (also den public key in Textform)
- die folgenden 4 Zeilen schreiben den Inhalt der Variablen in das Unterverzeichnis .ssh im Home-Verzeichnis vom Benutezr vagrant in die Datei authorized_keys und nochmal in die selbe Datei im Home-Verzeichnis des Users root (kann zu einer Fehlermeldung führen, wenn es da Rechte fehlen, was aber in diesem Fall schlimm ist), Andere VM unterstützen den User root an der Stelle ggf., da macht die Anweisung dann mehr Sinn. Ziel ist ja eine Automatisierung, das heißt auch bei unterschiedlichen VM immer dasselbe Verhalten.
- die letzte Zeile beendet den Block mit end
In MobaXterm wurde deine Session ja automatisch gespeichert (unter dem gelben Stern auf der linken Seite). Dort kannst du mit einem Rechtsklick die Verbindung ändern, wechsle dort auf das Register Advanced SSH Settings und ändere dort unter Use private key deinen Schlüssel von private_key auf id_rsa)
Wenn du erneut versuchst, dich mit MobaXterm zu verbinden, klappt der Login mit dem eigenen SSH-Key problemlos.
Bleibt jetzt die Frage, wo du die Images eigentlich herbekommst, das mit der Ubuntu-Bionic war ja einfach. Keine Sorge, in der Vagrant Cloud findest du alles, was du brauchst. VMs in allen Größen und und oft auch direkt für die üblichen Provider VMWare, Parallels und Virtualbox. Und selbst wenn in einem Minimal-Image mal etwas fehlt….jede einzelne VM hat grundsätzlich Internetzugang über deinen Host und so kannst du die VM nach belieben updaten oder Pakete nachinstallieren (dazu komme ich in einem späteren Blogbeitrag).
Im übrigen musst du bei Einsatz von MobaXterm gar nicht erst die Windows-Eingabeaufforderung benutzen, sondern kannst das auch direkt in MobaXterm erledigen. Das coole dabei, du kannst Windows- und Linux-Befehle (im Folgenden durch Anzeigen von Verzeichnissinhalten dargestellt) in einer Shell gleichzeitig benutzen. Öffne einen neuen Tab, wechsle das Verzeichnis auf die Windows-Ebene. Probieren wir das doch gleich mal aus (siehe Screenshot)
Du siehst, sowohl der DIR-Befehl von Windows, als auch der ls-Befehl von Linux funktionieren hier am selben Ort. Und mit vagant destroy ist die VM auch schon gelöscht, wovon du dich in Virtualbox überzeugen kannst.
Die Windows-Verzeichnistruktur (in und außerhalb von MobaXterm)
An dieser Stelle vielleicht ein paar Erläuterungen zu der Verzeichnisstruktur:
Unter Windows liegt dein Benutzerverzeichnis unter C:\User\<NAME>\ – das kannst du auch im Windows Explorer erkunden.
Dort findest du dann auch die Ordner Dokumente, Downloads, Bilder, etc. (oder eben auf englisch Documents, Downloads, Pictures, etc.).
Im selben Verzeichnis liegt jetzt auch der von dir hier erstellte Ordner vagrant, der wiederum deinen neuen test-Ordner enthält (aus dem Beispiel oben).
Wenn du in den Explorer-Optionen auch versteckte Dateien und Verzeichnisse einblendest, siehst du deutlich mehr Ordner. Da gibt es auch auf dieser Ebene einen Ordner Namens .vagrant.d (mit einem Punkt davor, was auf einen versteckten Ordner hinweist), welcher die Basiskonfiguration von Vagrant beinhaltet. Der Unterordner boxes enthält zum Beispiel alle VMs, die du aus der Vagrant Cloud oder anderswo heruntergeladen hast.
Und im Bild oben siehst du auch eine Besonderheit von MobaXterm. Das Programm benutzt grundsätzlich ein eigenes Homeverzeichnis, oben unter /home/mobaxterm zu sehen. Willst du jetzt auf die Windows-Laufwerke zugreifen, sind diese unter /drives gemounted, gefolgt von dem Laufwerksbuchstaben (hier C). Der Rest ist selbsterklärend. Falls du das Homeverzeichnis von MobaXterm mal im Explorer unter Windows suchen solltest, du findest es unter:
C:\Users\<NAME>\AppData\Roaming\MobaXterm\home
Fazit
Mit dem neuen Wissen sollte es für dich jetzt ein leichtes sein, auch die in IT-Sicherheitskreisen (oder auch Hacker) gern genutzten Schwachstellen-Plattformen Metasploitable für Linux Ubuntu 1404 und Microsoft Windows 2008 in Betrieb zu nehmen. Demnächst folgt ein Blogbeitrag, in dem wir uns eine umfangreichere VM-Umgebung erstellen lassen.