network services, dhcp, dns, VNC, VNC, TFTP Server, PXE boot, gPXE, NBD, BKO, certtool
(Link zu dieser Seite als [[QEMU-KVM-Buch/ Netzwerkoptionen/ Netzwerkdienste]])
Inhaltsverzeichnis |
[bearbeiten] Netzwerkdienste
[bearbeiten] DHCP und DNS
Der in QEMU/KVM integrierte DHCP-Server (Dynamic Host Configuration Protocol) unterstützt eine automatische Netzwerkkonfiguration der Gast-Systeme im Usermode Network Stack. Damit ist mit fast allen netzwerkfähigen Gast-Betriebssystemen eine sofortige Netzwerkverbindung nach außen möglich. Sind die Optionen -net nic -net user angegeben, wird für das virtuelle Netzwerk (10.0.2.0) ein interner DHCP-Server (10.0.2.2) und DNS-Server (10.0.2.3) aktiviert. Den Gast-Systemen werden IP-Adressen ab 10.0.2.15 zugewiesen.
Host ~$ qemu Platte.img -net nic -net user
Da die Optionen -net nic -net user per Default aktiviert sind, können diese weggelassen werden.
Host ~$ qemu Platte.img
Mit -net user,hostname=host wird ein vom integrierten DHCP-Server zugewiesener DNS-Namen für das Gast-System definiert. In diesem Beispiel erhält die IP-Adresse des Gast-Systems den DNS-Eintrag knut.
Host ~$ qemu Platte.img -net nic -net user,hostname=knut
Die Option dhcpstart=addr definiert die erste Adresse des IP-Bereiches, die der DHCP-Server zuweisen kann. Dieser Bereich umfasst 16 IP-Adressen. Per Default liegt dieser Bereich zwischen x.x.x.16 und x.x.x.31. Zum Beispiel wird mit dhcpstart=10.0.2.50 per DHCP dem Gast-System eine IP-Adresse ab 10.0.2.50 vorgegeben.
Host ~$ qemu Platte.img -net nic -net user,dhcpstart=10.0.2.50
Die Option dns=addr definiert die für das Gast-System sichtbare IP-Adresse des integrierten DNS-Servers. Per Default ist dies die dritte IP-Adresse in dem Gast-Netzwerk, zum Beispiel x.x.x.3. In diesem Beispiel wird dem DNS-Server die IP-Adresse 10.0.2.7 zugewiesen. Diese Adresse wird dem Gast-System per DHCP mitgeteilt.
Host ~$ qemu Platte.img -net nic -net user,dns=10.0.2.7
Neben der automatischen Konfigurierung per DHCP kann im Gast-System die Netzwerkkonfiguration auch manuell erfolgen. Als Gateway muss die IP-Adresse 10.0.2.2 eingestellt werden. Die IP-Adresse der virtuellen Netzwerkkarte kann im Netzsegment 10.0.2.0 ab 10.0.2.15 konfiguriert werden. Auch können andere oder zusätzliche DNS-Server eingetragen werden. Konfiguriert man zum Beispiel einen DNS-Server entsprechend der Anleitung unter http://www.opennicproject.org/migrate im Gast-System, können die Top-Level-Domains .glue, .indy, .geek, .null, .oss und .parody des OpenNIC-Projektes aufgelöst werden.
[bearbeiten] Samba
Samba ist eine freie Software-Suite, die das Server Message Block Protocol (SMB) für Unix-Systeme verfügbar macht. Das heißt, mit Samba können Windows-Freigaben unter Unix/Linux erzeugt werden. QEMU und KVM ermöglichen mit Samba einen Datenaustausch zwischen dem Host und den Gast-Systemen. Wurde auf dem Host-System bereits ein Samba-Server installiert und konfiguriert kann im Gast-System auf dessen Freigaben über die URL \\10.0.2.2\ zugegriffen werden. Da weder QEMU noch KVM eigene Samba-Server enthalten ist auf dem Host-System ein Samba-Server zu installieren. Unter Debian oder Ubuntu ist die Installation mit einer Befehlszeile erledigt.
Host ~$ sudo apt-get install samba
Weiterhin wird ein Verzeichnis auf dem Host-System als Freigabe benötigt. Der Samba-Server muss Lese- und Schreibrechte für dieses Verzeichnis haben. Mit der Option -net user,smb=directory wird der Samba-Server (/usr/sbin/smbd) mit einer eigenen Konfiguration gestartet. Damit der Samba-Server aufgerufen werden kann muss der Benutzer, unter dem QEMU beziehungsweise KVM laufen soll, die Berechtigung zum Starten des Samba-Servers haben. Eine Variante ist es QEMU mit sudo aufzurufen.
Host ~$ sudo qemu Platte.img -net nic -net user,smb=/tmp/ Password: *****
Der Samba-Server hat die IP-Adresse 10.0.2.4. Im Microsoft Windows-Gast-System greift man im Dateimanager auf diese Freigabe zu (Menü Extras, Netzwerklaufwerk verbinden: \\10.0.2.4\qemu). Wer lieber einen Host-Namen für den Samba-Server nutzen möchte, kann der IP-Adresse einen Namen zuweisen. Dazu ist im Gast-System je nach Windows-Version in einer der Dateien C:\WINNT\SYSTEM32\DRIVERS\ETC\LMHOSTS, C:\WINDOWS\LMHOSTS oder C:\WINNT\SYSTEM32\DRIVERS\ETC\HOSTS die folgende Zeile hinzuzufügen.
10.0.2.4 smbserver
Optional kann die IP-Adresse des Samba-Servers mit der Option smbserver geändert werden. In diesem Beispiel wird dem Samba-Server die Adresse 10.0.2.7 zugewiesen.
Host ~$ sudo qemu Platte.img \ -net nic -net user,smb=/tmp/,smbserver=10.0.2.7
[bearbeiten] TFTP
Das Trivial File Transfer Protocol (TFTP) ist ein einfaches Dateiübertragungsprotokoll. Es unterstützt lediglich das Lesen und Schreiben von Dateien. Nicht vorhanden sind viele Funktionen des mächtigeren FTP wie etwa Rechtevergabe, Anzeigen der vorhandenen Dateien oder Benutzerauthentifizierung. Motivation für die Entwicklung von TFTP war das Laden von Betriebssystemen oder Konfigurationen über das Netzwerk. Hierfür ist das verbindungsorientierte TCP und das darauf aufsetzende FTP viel zu überladen. TFTP ist dagegen bewusst einfach gehalten. Der in QEMU/KVM integrierte TFTP-Server (IP-Adresse 10.0.2.2) erlaubt es auf einfache Weise einzelne Dateien des Host-Systems dem Gast-System zum Herunterladen zur Verfügung zu stellen. Auf dem Gast-System muss dazu ein TFTP-Client installiert und im Binär-Modus konfiguriert sein. Aktiviert wird der TFTP-Server mit der Option -net user,tftp gefolgt vom Pfad zum Download-Verzeichnis. Dazu ist die Unix-Schreibweise anzuwenden. Ist der Host ein Microsoft-Windows-System ist anstelle von C:\Users\User01 die Schreibweise /Users/Users01 anzuwenden. Ein Wechsel von Laufwerken ist nicht möglich. Das folgende Beispiel ermöglicht das Herunterladen von Dateien im Verzeichnis /tmp des Host-Systems.
Host ~$ qemu Platte.img -net nic -net user,tftp=/tmp/
Falls nicht vorhanden muss im Gast-System noch ein TFTP-Client installiert werden. Ist das Gast-System ein Debian-Derivat, ist das Paket tftp zu verwenden.
Gast ~$ sudo apt-get install tftp
Das Herunterladen einer Datei vom Host per TFTP erfolgt mit diesen Befehlen:
Gast ~$ tftp 10.0.2.2 tftp> binary tftp> get bla.txt tftp> quit
Unter Microsoft Windows NT, -2000 und -XP ist bereits ein TFTP-Client über die DOS-Eingabeaufforderung verfügbar.
Gast C:\> tftp -i 10.0.2.2 GET bla.txt
[bearbeiten] PXE
Das Preboot Execution Environment (PXE) ermöglicht einen netzwerkbasierten Boot-Vorgang. PXE verwendet die Protokolle TCP/IP, UDP, DHCP, TFTP sowie die Konzepte GUID/UUID, UNDI (Universal Network Device Interface) und eine client-seitige Firmware-Erweiterung mit festgelegten APIs. Mit einem PXE-fähigen Rechner ist es möglich, über das Netzwerk von einem Boot-Server booten. Dies ist notwendig, wenn auf einem Rechner ohne Zufügen von Speichermedien ein Betriebssystem installiert oder ein Thinclient-System aufgebaut werden soll. Der Netzwerk-Bootvorgang wird durch ein auf der Netzwerkkarte installiertes BIOS initiiert. Der Boot-Vorgang läuft dabei folgendermaßen ab: Die Firmware stellt per DHCP eine Anfrage, um den PXE-Boot-Server zu ermitteln. Nach Empfang einer Antwort kontaktiert sie den passenden Boot-Server, um von ihm den Pfad zum Herunterladen des NBP (Network Bootstrap Program) übermittelt zu bekommen. Dieser Bootloader wird anschließend in den Arbeitsspeicher geladen und ausgeführt. In QEMU wurde ab Version 0.12.0 der Netzwerk-Booloader gPXE (http://etherboot.org) integriert. gPXE ergänzt PXE mit zusätzlichen Funktionen. Zum Beispiel wird neben FTP auch HTTP und iSCSI unterstützt.
Mit der Option -boot n|o|p wird das Booten über Netzwerk ermöglicht. Wobei mit n die 1. Netzwerkkarte, o die 2. Netzwerkkarte und p die 3. Netzwerkkarte adressiert wird. Für das Booten über das Netzwerk werden die entsprechenden PXE-ROM-Images der Netzwerkkarten benötigt.
Host ~$ qemu -boot n No valid PXE rom found for network device
In diesem Fall findet QEMU kein PXE-ROM-Image. Man kann PXE-ROM-Images von den URLs http://etherboot.org und http://rom-o-matic.net herunterladen. Unter Linux sind diese in die Verzeichnisse /usr/share/kvm/ oder /usr/share/qemu/ zu kopieren. Eleganter ist die Installation des entsprechenden Paketes.
Host ~$ sudo apt-get install kvm-pxe
Es werden dabei die PXE-ROM-Images nur in das Verzeichnis /usr/share/kvm/ kopiert.
Host ~$ dpkg -L kvm-pxe | grep ".bin" /usr/share/kvm/pxe-e1000.bin /usr/share/kvm/pxe-ne2k_pci.bin /usr/share/kvm/pxe-pcnet.bin /usr/share/kvm/pxe-rtl8139.bin /usr/share/kvm/pxe-virtio.bin
QEMU sucht die PXE-ROM-Images unter /usr/share/qemu/. Man muss den Pfad mit der Option -option-rom angeben.
Host ~$ qemu -boot n -option-rom /usr/share/kvm/pxe-ne2k_pci.bin
Besser ist es mit Symlinks im Verzeichnis /usr/share/qemu/ auf die entsprechenden PXE-ROM-Images im Verzeichnis /usr/share/kvm/ zu verweisen.
Host ~$ cd /usr/share/kvm
Host ~$ sudo for i in `ls pxe*` ; do \
ln -s /usr/share/kvm/$i /usr/share/qemu/ ; done
Host ~$ qemu -boot n
Mit PXE ist es möglich, Betriebssysteme über das Netzwerk zu installieren. In diesem Beispiel ist es Ubuntu. Zuerst ist ein Verzeichnis anzulegen. Dann ist das Netboot-Archiv herunterzuladen und zu entpacken.
Host ~$ sudo mkdir /netboot Host ~$ cd /netboot Host ~$ sudo wget \ http://archive.ubuntu.com/ubuntu/dists/karmic/main/installer-i386/current/images/netboot/netboot.tar.gz Host ~$ sudo tar xzvf netboot.tar.gz
In einem beliebigen Verzeichnis wird die virtuelle Festplatte für die Installation generiert und danach QEMU oder KVM mit den entsprechenden Optionen gestartet. Der Parameter bootfile definiert die BOOTP-Datei. Die Installation von Ubuntu wird in dem Abschnitt Gast-Systeme (http://qemu-buch.de/d/Gast-Systeme/_x86-Architektur/_Linux) beschrieben.
Host ~$ qemu-img create -f qcow2 ubuntu.img 10G Host ~$ qemu -hda ubuntu.img -boot n \ -net nic -net user,tftp=/netboot/,bootfile=pxelinux.0
Mit den Optionen zum Booten über das Netzwerk ist es weiterhin möglich Diskless Clients für das Linux Terminal Server Project (http://www.ltsp.org) zu emulieren. Zum Beispiel verwendet die Linux-Distribution Eubuntu einen LTSP-Server, um Clients ohne Festplatte zu unterstützen. Benötigt wird das Paket ltsp-server.
Host ~$ sudo apt-get -s install ltsp-server
Dieses Paket enthält Werkzeuge, um eine LTSP-Umgebung (http://wiki.ubuntuusers.de/LTSP) zu installieren. Der folgende Befehl installiert eine LTSP-Umgebung unter /opt/ltsp/i386/.
Host ~$ sudo ltsp-build-client
Per Network Block Device (NBD) wird das LTSP-Images bereitgestellt. Der Befehl sudo ltsp-update-image generiert diese im Verzeichnis /opt/ltsp/images. Danach müssen die entsprechenden Dienste neu gestartet werden.
Host ~$ sudo ltsp-update-image --arch i386 Host ~$ sudo /etc/init.d/dhcdbd restart Host ~$ sudo /etc/init.d/tftpd-hpa restart Host ~$ sudo /etc/init.d/openbsd-inetd restart
QEMU wird mit folgenden Optionen gestartet.
Host ~$ sudo qemu -net nic -net tap -boot n -vga std -monitor stdio
[bearbeiten] VNC
Virtual Network Computing (VNC) ermöglicht es den Bildschirminhalt eines Rechners (auf dem der VNC-Server läuft) auf einem anderen Rechner (auf dem der VNC-Viewer läuft) anzuzeigen und im Gegenzug Tastatur- und Maus-Bewegungen zurück zu senden. Damit ist ein Remote-Zugriff auf den Desktop eines anderen Rechners möglich. Da es VNC-Server und -Viewer für fast alle gängigen Betriebssysteme gibt, sind auch Remote-Zugriffe auf Rechner mit anderen Betriebssystemen möglich. Ein weiterer Vorteil von VNC ist, dass gestartete Programme unabhängig von der VNC-Session weiterlaufen. Beim erneuten Einloggen per VNC findet man den Desktop wieder so vor wie man ihn verlassen hat. QEMU und KVM enthalten einen internen VNC-Server der einen Remote-Zugriff auf das Gast-System ermöglicht. Im Gast-System muss dazu kein VNC-Server installiert sein. Für eine Verbindung zum VNC-Server wird ein VNC-Viewer benötigt. Bei der Linux-Distribution Ubuntu Desktop zum Beispiel ist bereits ein solcher installiert. Aufgerufen wird er über das Menü Anwendungen, Internet, Terminal Server Client. Falls noch kein VNC-Viewer auf dem System vorhanden ist, wird TightVNC (http://www.tightvnc.com) installiert. Der Aufruf unter Microsoft Windows erfolgt über das Start-Menü, Alle Programme, TightVNC, TightVNC Viewer (Fast Compression). Hier als Beispiel die Installation unter einem Linux-Debian-Derivat.
Host ~$ sudo apt-get install xtightvncviewer
Den VNC-Server aktiviert die Option -vnc gefolgt von dem Host-Namen und einer Ziffer. Die Ziffer kennzeichnet den VNC-Server auf dem Host-Rechner, da mehrere VNC-Server gleichzeitig aufgerufen werden können. Die Option -k de schaltet die deutsche Tastatur ein.
Host ~$ qemu Platte.img -k de -vnc localhost:1
Bei der Option -vnc erscheint keine Bildschirmausgabe. Man startet einen VNC-Viewer. Laufen VNC-Server und VNC-Viewer auf dem gleichen Rechner gibt man als Option für den VNC-Viewer localhost:1 ein. Läuft der VNC-Server auf einem anderen Rechner ist dessen Rechnername beziehungsweise IP-Adresse anzugeben. Man kann auch eine zweite Instanz mit einem aktivierten VNC-Server starten. Dazu muss hinter der Option -vnc eine 2 eingegeben werden.
Host ~$ qemu Platte.img -k de -vnc localhost:2
Mit der Option -sdl wird zusätzlich die grafische Ausgabe mit SDL aktiviert.
Host ~$ qemu Platte.img -k de -vnc localhost:1 -sdl
Nützlich ist in Verbindung mit der Option -vnc auch die Option -usbdevice tablet. Diese stellt eine spezielle Maus-Emulation bereit die den Maus-Zeiger nicht mehr im Fenster der Instanz festhält. Wird das Fenster mit dem Maus-Zeiger verlassen wird die Kontrolle über den Maus-Zeiger wieder vom Host-System übernommen.
Host ~$ qemu Platte.img -k de -vnc :1 -usbdevice tablet
Im QEMU-Monitor gibt der Befehl info vnc Status-Informationen aus.
(qemu) info vnc VNC server active on: 0.0.0.0:1 No client connected
Die Aktivierung des VNC-Servers kann mit der Option -vnc none unterbunden werden. Die Konfiguration des VNC-Servers erfolgt dann im QEMU-Manager mit dem Befehl change vnc. Die Parameter entsprechen denen der Option -vnc.
Host ~$ qemu Platte.img -k de -vnc none -monitor stdio (qemu) info vnc VNC server disabled (qemu) change vnc localhost:1
Auch eine VNC-Reverse-Verbindung ist möglich. Dazu ist ein VNC-Viewer im Listen-Modus zu starten. Eine Instanz kann sich danach mit der Option reverse zu diesem VNC-Viewer verbinden. In diesem Beispiel wird auf einen Windows-PC der VNC-Client TightVNC im Listen-Modus betrieben. Danach wird eine Instanz, hier auf einen Linux-Rechner, mit der Option reverse gestartet. Dazu ist der Host-Name, hier windows-pc, und das Port anzugeben. Der Default-Wert für das Port ist 5500. Ist alles richtig konfiguriert, erscheint die VNC-Ausgabe auf dem Ziel-Rechner.
Host ~$ qemu Platte.im -vnc windows-pc:5500,reverse
Eine VNC-Verbindung sollte gesichert sein. Eine einfache Möglichkeit ist die Zugangseinschränkung mit einem Passwort. Das VNC-Protokoll beschränkt aber die Länge der Passwörter auf acht Zeichen und bietet so nur geringen Schutz. Der Passwort-Schutz wird mit dem Parameter password aktiviert.
Host ~$ qemu Platte.img -monitor stdio -vnc :1,password
Das Passwort wird im QEMU-Monitor mit dem Befehl change vnc password gesetzt.
(qemu) change vnc password Password: ********
Einen weiteren Schutz bietet die Authentifizierung mit X509-Zertifikaten und die Verschlüsselung der Session mit TLS (Transport Layer Security). Dazu dienen die Parameter x509 und tls. Die notwendigen Zertifikate müssen sich in dem angegebenen Verzeichnis, hier /etc/pki/qemu, befinden.
Host ~$ qemu -hda hd-image.img -monitor stdio \
-vnc :1,tls,x509=/etc/pki/qemu
Mit dem Parameter x509verify fordert der Server zusätzlich vom Client dessen gültiges Zertifikat an.
Host ~$ qemu -hda hd-image.img -monitor stdio \
-vnc :1,tls,x509verify=/etc/pki/qemu
Die höchste Sicherheit wird durch die zusätzliche Definition eines Passwortes erreicht.
Host ~$ qemu -hda hd-image.img -monitor stdio \
-vnc :1,password,tls,x509verify=/etc/pki/qemu
Zur Erzeugung der Zertifikate dient das Programm certtool. Die Installation unter Ubuntu ist mit einer Befehlszeile erledigt.
Host ~# apt-get install gnutls-bin
Alternativ lädt man certtool von der Website http://www.gnu.org/software/gnutls/ herunter und installiert es. Die Windows-Version ist von der URL http://josefsson.org/gnutls4win/ zu beziehen. Diese Anleitung bezieht sich auf die Linux-Version. Es ist zu empfehlen für die Zertifikate ein eigenes Verzeichnis anzulegen. Diese können entweder vom Benutzer root in /etc/pki/qemu oder für andere Benutzer in $HOME/.pki/qemu abgelegt werden.
Host ~# mkdir -p /etc/pki/qemu Host ~# cd /etc/pki/qemu
Zur Signierung der Keys ist eine Certificate Authority (CA) notwendig. Diese kann eine offizielle CA oder eine selbst signierte CA sein. In diesem Beispiel wird eine selbst signierte CA erzeugt. Dazu ist einmalig ein privater Key für die CA anzulegen. Dieser Key muss sicher aufbewahrt werden. Keineswegs darf er in falsche Hände geraten.
Host ~# certtool --generate-privkey > ca-key.pem
Dieser Key wird nur für den Eigentümer lesbar gesetzt.
Host ~# chmod 0600 ca-key.pem
Basierend auf dem privaten Key und Angaben zur Organisation und Konfiguration wird ein öffentlicher Key erstellt. Die Angaben werden dazu in eine Textdatei geschrieben. Der Name der Datei ist ca.info. Hier ein Beispiel für deren Inhalt.
cn = Name ihrer Organisation ca cert_signing_key
Es wird mit certtool der öffentliche Key angelegt.
Host ~# certtool --generate-self-signed \
--load-privkey ca-key.pem \
--template ca.info \
--outfile ca-cert.pem
Der öffentliche Key (ca-cert.pem) muss auf allen Servern und VNC-Clients kopiert werden. Wobei die Hosts mit installiertem QEMU oder KVM als Server bezeichnet werden. Weiterhin benötigt jeder Server einen privaten Key und ein Zertifikat. Der private Key wird mit folgendem Befehl erzeugt.
Host ~# certtool --generate-privkey > server-key.pem
Dieser private Key wird nur auf dem vorgesehenen Server anlegt. Dort wird er nur für den Eigentümer lesbar gesetzt.
Host ~# chmod 0600 server-key.pem
Auch jeder Server benötigt ein Zertifikat. Die notwendigen Angaben werden in eine Textdatei geschrieben. Der Name der Datei ist server.info. Hier ein Beispiel für deren Inhalt.
organization = Name ihrer Organisation cn = server.foo.example.com tls_www_server encryption_key signing_key
Es wird mit certtool das Zertifikat generiert.
Host ~# certtool --generate-certificate \
--load-ca-certificate ca-cert.pem \
--load-ca-privkey ca-key.pem \
--load-privkey server-key.pem \
--template server.info \
--outfile server-cert.pem
Das Zertifikat server-cert.pem wird nur auf dem vorgesehenen Server angelegt. Es müssen noch die VNC-Clients ihre Keys und Zertifikate erhalten. Der private Key wird mit diesem Befehl erzeugt.
Host ~# certtool --generate-privkey > client-key.pem
Dieser Key wird nur auf dem vorgesehenen Client angelegt. Dort wird er nur für den Eigentümer lesbar gesetzt.
Host ~# chmod 0600 client-key.pem
Wenn bei dem Server die Option x509verify verwendet wird, benötigt der Client ein Zertifikat. Die notwendigen Angaben werden in eine Textdatei geschrieben. Der Name der Datei ist client.info. Hier ein Beispiel für deren Inhalt.
country = DE state = Berlin locality = Berlin organization = Name ihrer Organisation cn = client.foo.example.com tls_www_client encryption_key signing_key
Es wird mit certtool das Zertifikat angelegt und nur auf dem vorgesehenen VNC-Client kopiert.
Host ~# certtool --generate-certificate \
--load-ca-certificate ca-cert.pem \
--load-ca-privkey ca-key.pem \
--load-privkey client-key.pem \
--template client.info \
--outfile client-cert.pem
QEMU und KVM unterstützen die Authentifizierung des VNC-Zugriffs mit dem Simple Authentication and Security Layer (SASL). SASL bietet dem Applikationsprotokoll eine standardisierte Möglichkeit der Aushandlung von Kommunikationsparametern zwischen Server und Client. Es können unter anderem die Authentifizierungsmethoden PAM, GSSAPI/Kerberos, LDAP, SQL-Datenbank und Einmal-Keys angewendet werden. Durch die Konfiguration der jeweiligen SASL-Implementierungen wird ein Verfahren festgelegt. Wurde QEMU/KVM mit der Unterstützung für SASL kompiliert erfolgt dies durch die SASL-Konfigurationsdatei /etc/sasl2/qemu.conf. Alternativ kann auf eine andere Konfigurationsdatei mit der Variable SASL_CONF_PATH verwiesen werden. Für eine einfache Verschlüsselung mit Passwörtern hat die Datei /etc/sasl2/qemu.conf folgenden Inhalt.
# /etc/sasl2/qemu.conf mech_list: digest-md5 sasldb_path: /etc/sasl2/qemu.db
Zur Definition von SASL-Passwörtern ist das Paket sasl2-bin zu installieren (Beispiel Ubuntu).
Host ~$ sudo apt-get install sasl2-bin
Mit dem Programm saslpasswd2 werden die jeweiligen Zugangsdaten in die SASL-Datenbank geschrieben. Hier wird der Benutzer ich mit dem Passwort geheim angelegt.
Host ~$ sudo saslpasswd2 -f /etc/sasl2/qemu.db ich Password: geheim Again (for verification): geheim
Übrigens löscht man einen Benutzer in der SASL-Datenbank mit der Option -d.
Host ~$ saslpasswd2 -f /etc/sasl2/qemu.db -d ich
Die angelegten Accounts listen man mit folgenden Befehl auf.
Host ~$ sasldblistusers2 -f /etc/sasl2/qemu.db ich@localhost.localdomain: userPassword
QEMU beziehungsweise KVM wird mit der Option -vnc :1,sasl gestartet.
Host ~$ qemu Platte -vnc :1,sasl
Leider beherrschen nicht alle VNC-Clients das SASL-Protokoll. Neben dem virt-viewer und dem virt-manager (siehe Abschnitt libvirt) beherrscht vinagre Version 2.26.1 das SASL-Protokoll.
Host ~$ sudo apt-get install vinagre Host ~$ vinagre
Zusätzliche Sicherheit bringt die Verwendung von Zugriffssteuerungslisten (Access Control Lists - ACL). Dazu muss QEMU/KVM mit der Unterstützung für ACL kompiliert worden sein. Bei x509-Client-Zertifikaten wird der Distinguished Name getestet. Dieser hat zum Beispiel die Form C=DE,O=BLA,L=Berlin,CN=ich. Bei SASL wird der Benutzername überprüft. Je nach verwendeten SASL-Plugin kann der Benutzername beispielsweise in den Formen ich oder ich@beispiel.de angegeben werden. Wenn der acl-Flag gesetzt wird ist die Zugriffssteuerungsliste leer und verfügt nur über die Deny-Policy. Dadurch wird verhindert, dass jemand unerlaubten Zugriff erhält solange der VNC-Server noch keine ACL geladen hat. Aktiviert wird die Verwendung von ACL mit der Option acl.
Host ~$ qemu Platte -vnc :1,sasl,acl
Zum Anzeigen der Zugriffssteuerungsliste dient der Befehle acl_show im QEMU-Monitor. Dieser listet alle Regeln der Zugriffssteuerungsliste und der Default-Policy auf. Es gibt zwei benannte Zugriffssteuerungslisten: Während vnc.x509dname auf den Distinguished Name testet überprüft vnc.username auf den SASL-Benutzernamen.
(qemu) acl_show vnc.username policy: deny
Mit folgenden Befehl wird der Liste vnc.username der Zugang gewährt.
(qemu) acl_policy vnc.username allow acl: policy set to 'allow'
(qemu) acl_show vnc.username policy: allow
Dem Benutzer ich erhält nun Zugangsberechtigung.
(qemu) acl_add vnc.username ich allow acl: added rule at position 1 (qemu) acl_show vnc.username policy: allow 1: allow ich
Der Benutzer ich kann sich mit einem VNC-Client mit SASL-Unterstützung mit der Instanz verbinden. Der Zugang wir mit dem folgenden Befehl wieder gesperrt.
(qemu) acl_remove vnc.username ich acl: removed rule at position 1
Mit folgenden Befehl wird der Liste vnc.username die Zugangsberechtigung entzogen.
(qemu) acl_reset vnc.username acl: removed all rules (qemu) acl_show vnc.username policy: deny
[bearbeiten] Links
- Nützliche Tools
- -monitor stdio
- Network Block Devices
- http://de.wikipedia.org/wiki/Linux_Terminal_Server_Project
- http://www.fefe.de/netboot/how-to-netboot-installer.html
- http://de.wikipedia.org/wiki/Preboot_Execution_Environment
- http://rowa.giso.de/x-terminals/german/index.html
- http://alien.slackbook.org/dokuwiki/doku.php?id=slackware:qemu#pxe_booting_your_qemu_virtual_machine
- http://www.netboot.me/gettingstarted
- http://boot.kernel.org
- http://linuxwiki.de/rdesktop