Lösungen

ssh-Zugriff

1. ALT-F1 oeffnet die Console
2. 'unsupported' liefert einen Passwd:
3. Danach das root-PASSWD eingeben.
4. Danach erscheint eine root-Schell (ash)
5. Es gibt einen vi, grep, sed . find ... (: ist auf SHIFT-ö)

Zertifikatesaustausch

Austausch an sich

Mit obigen erzeilten ssh-Zugriff kann man ein neues Zertikikat in /etc/vmware/ssh als rui.crt und rui.key austauschen.

ESXi arbeitet intern mit den PAM-Modulen, die Grüchte, daß der Austausch der Schlüssel den Passwortalgorithmus beeinflussen und man sich dann aussperrt, sind gegenstandslos und sind nicht eintroffen.

Generieren des Zertifikats

Sieht man sich das Zertifikat mit openssl x509 -in rui.crt -noout -text an, so sieht man Extensionfelder. Die Externsinfelder kann man durch Modifikation der openssl-Konfigurationsdatei erreichen.

Ein Neugenerieren kann man einfach auf dem EXSi-Host durch Aufruf von /sbin/generate-certificates.sh erreichen

Weitere Wünsche an das Zertifikat

• Der Hostname muß richtig sein. Beim Einloggen auf der Clientseite muß man den ganzen Rechnernamen eingeben also: isssr.intern statt nur isssr. (isssr für ISS AG SuperRechner)
• es muss laut vSpereClientconsole eine mindest 2 stufige Kette da sein

Erzeugung eigenes ROOT-Zertifikat mit openssl:

cat > cert.cnf <<EOFCNF
RANDFILE = /dev/urandom

[ req ]
distinguished_name      = req_distinguished_name

encrypt_key             = no
prompt                  = no

string_mask             = nombstr
x509_extensions         = x509

[ req_distinguished_name ]
C                       = DE
L                       = Ravensburg
O                       = Infnet CERT
CN                      = Rudolf Weber

[ x509 ]
basicConstraints        = CA:true, pathlen:0
keyUsage                = keyCertSign
EOFCNF
openssl req -new -x509 -config cert.cnf -days 3650 -keyout ca.key -out ca.crt

Generierung Hostkey

#!/bin/bash
DISTNAME=isssr.intern
# This ID traces it lineage to the old days of the MUI, and it is far too random
# to not be important, so just trust it
UNIQUE_IDENTIFIER=564d7761726520496e632e
cat > host_cert.cnf << EOH
RANDFILE = /dev/urandom

[ req ]
default_bits            = 1024
default_keyfile         = rui.key
distinguished_name      = req_distinguished_name

encrypt_key             = no
prompt                  = no

string_mask             = nombstr
x509_extensions         = x509

[ req_distinguished_name ]
countryName             = DE
localityName            = Ravensburg
0.organizationName      = Informatik- und Netzwerkverein e.V
organizationalUnitName  = CERT
emailAddress            = ssl-certificates@infnet.verein.de

commonName              = ${DISTNAME}
unstructuredName        = $(date +'%s'),${UNIQUE_IDENTIFIER}

[ x509 ]
basicConstraints        = CA:false
keyUsage                = digitalSignature,keyEncipherment,dataEncipherment
extendedKeyUsage        = serverAuth,clientAuth
subjectAltName          = DNS:${DISTNAME}
EOH
openssl req -new -config host_cert.cnf -days 3650 -keyout rui.key -out rui_req.crt

Signierung:

openssl x509 -req -in rui_req.crt -CA ca.crt -CAkey ca.key -extfile host_cert.cnf -extensions x509  -CAcreateserial
 -days 3650 -out rui.crt

Fehlerprotokolle

Upgrade des VIclients

Das DocumentRoot des internen www-Servers ist /usr/lib/vmware/hostd/docroot/

Den client kann man auf Datenspeicher1 ablegen: Nach jedem Reboot muss der Link gelegt werden:

cd /usr/lib/vmware/hostd/docroot/
ln -s /vmfs/volumes/Datenspeicher1/VMware-viclient-all-4.1.0-258902.exe VMware-viclient.exe

VMware-Kommunikation mit den Konsolen

bischlauch isssr 902

220 VMware Authentication Daemon Version 1.10: SSL Required, ServerDaemonProtocol:SOAP, MKSDisplayProtocol:VNC , 

Consolen aktivieren

belegte Ports

• Windows firewall
• McAfee - Windows-Registry: regedit

      HKEY_LOCAL_MACHINE\SOFTWARE\McAfee\Redirector\Ports] 
  
  "902"="Ignore" 
  "912"="Ignore" 
  "8222"="Ignore" 
  "8333"="Ignore" 
  
  
  

(Bei einem Vista-Laptop konnte man nicht auf die Consolen kommen, von einem XP schon. Die Ursache war: vorinstalliertes McAfee !)