VMware-Forum

Hallo,
habe die ssh-Verbindung zw. meinem putty und der ESXi 4.1 über ssh-Key eingerichtet und möchte die Lösung nun rebootsicher machen.
Hierfür werden im Web zwei Lösungen vorgeschlagen:
1. oem.tgz
2. eine eigene xxx.tgz und diese dann noch in die boot.cfg eintragen
(siehe: http://mail-archives.apache.org/mod_mbo ... ton.edu%3E)

Die oem.tgz möchte ich nicht anfassen. Und die zweite Lösung hat bei mir nicht funktioniert.

Nun frage ich mich aber, ob dies nicht viel einfacher geht:
1) ich kopiere die .ssh/authorized key in ein reboot sicheres Verzeichnis (zur Not auf den Datastore) oder packe die Datei in ein .tgz, und diese dann in ein reboot sicheres Verzeichnis
2) ich füge an die /etc/rc.local eine Zeile an, die die gesicherte authorized_keys oder die .tgz per cp oder tar nach / kopiert. So wie es auch für die rebootsichere Erstellung der crontab gemacht wird

Ist das zu einfach gedacht?

esxstarter hat geschrieben:Hallo,
habe die ssh-Verbindung zw. meinem putty und der ESXi 4.1 über ssh-Key eingerichtet und möchte die Lösung nun rebootsicher machen.
Hierfür werden im Web zwei Lösungen vorgeschlagen:
1. oem.tgz
2. eine eigene xxx.tgz und diese dann noch in die boot.cfg eintragen
(siehe: http://mail-archives.apache.org/mod_mbo ... ton.edu%3E)

Die oem.tgz möchte ich nicht anfassen. Und die zweite Lösung hat bei mir nicht funktioniert.

Nun frage ich mich aber, ob dies nicht viel einfacher geht:
1) ich kopiere die .ssh/authorized key in ein reboot sicheres Verzeichnis (zur Not auf den Datastore) oder packe die Datei in ein .tgz, und diese dann in ein reboot sicheres Verzeichnis
2) ich füge an die /etc/rc.local eine Zeile an, die die gesicherte authorized_keys oder die .tgz per cp oder tar nach / kopiert. So wie es auch für die rebootsichere Erstellung der crontab gemacht wird

Ist das zu einfach gedacht?

wenn rc.local bootfest ist und du die Erreichbarkeit der Dateien jederzeit garantieren kannst sollte das gehen.
Was ist dein Problem mir oem.tgz?
Datei entpacken, änden/ ergänzen, wieder packen und einspielen. Das ist mit ein wenig Übung nachher noch nicht einmal mehr eine Fingerübung.

Gruß

rprengel hat geschrieben:Was ist dein Problem mir oem.tgz?
Datei entpacken, änden/ ergänzen, wieder packen und einspielen. Das ist mit ein wenig Übung nachher noch nicht einmal mehr eine Fingerübung.

Gruß

Mein Problem mit oem.tgz ist (war), dass ich zum ersten Mal höre, dass der alte Inhalt in die neue oem.tgz rüber gerettet wird. Denn alle Anleitungen, die ich bisher gefunden habe (z.B: http://blog.verfriemelt.com/index.php/2 ... ob-backup/ ) haben die oem.tgz ersetzt. Begründung - den Inhalt brauchen nur die OEMs. Und das war mir dann doch etwas unsicher.

Habe gestern eine sshkey.tgz erstellt und die boot.cfg entsprechend abgeändert. Ergebnis: mein ESXi ist beim booten hängen geblieben. Da ich von Stick boote, musste ich daraufhin den Stick erst mal an meinen Laptop hängen und die boot.cfg wieder in den alten Zustand versetzen.
Daher bin ich hier ein etwas gebranntes Kind. Mit meiner Lösung würde das Booten immer klappen, da an den Boot-Modulen nichts verändert wird. Und wenn der cp für die SSH Files nicht klappt, dann melde ich mich eben mit passwort an der Console an. Aber mein ESXi und die Gäste laufen in jedem Fall.

Zur Lösung mit oem.tgz:
Habe gerade nachgeschaut, die Pfade in der oem.tgz sind relativ. D.h. ich kann die Datei z.B. nach /tmp/oem entpacken, meine .ssh Files dort reinkopieren und dann das Verzeichnis /tmp/oem mit relativen Pfaden wieder zu einer oem.tgz packen. Richtig?

esxstarter hat geschrieben:

rprengel hat geschrieben:Was ist dein Problem mir oem.tgz?
Datei entpacken, änden/ ergänzen, wieder packen und einspielen. Das ist mit ein wenig Übung nachher noch nicht einmal mehr eine Fingerübung.

Gruß

Mein Problem mit oem.tgz ist (war), dass ich zum ersten Mal höre, dass der alte Inhalt in die neue oem.tgz rüber gerettet wird. Denn alle Anleitungen, die ich bisher gefunden habe (z.B: http://blog.verfriemelt.com/index.php/2 ... ob-backup/ ) haben die oem.tgz ersetzt. Begründung - den Inhalt brauchen nur die OEMs. Und das war mir dann doch etwas unsicher.

Habe gestern eine sshkey.tgz erstellt und die boot.cfg entsprechend abgeändert. Ergebnis: mein ESXi ist beim booten hängen geblieben. Da ich von Stick boote, musste ich daraufhin den Stick erst mal an meinen Laptop hängen und die boot.cfg wieder in den alten Zustand versetzen.
Daher bin ich hier ein etwas gebranntes Kind. Mit meiner Lösung würde das Booten immer klappen, da an den Boot-Modulen nichts verändert wird. Und wenn der cp für die SSH Files nicht klappt, dann melde ich mich eben mit passwort an der Console an. Aber mein ESXi und die Gäste laufen in jedem Fall.

Zur Lösung mit oem.tgz:
Habe gerade nachgeschaut, die Pfade in der oem.tgz sind relativ. D.h. ich kann die Datei z.B. nach /tmp/oem entpacken, meine .ssh Files dort reinkopieren und dann das Verzeichnis /tmp/oem mit relativen Pfaden wieder zu einer oem.tgz packen. Richtig?

Fast:
ssh gehört in /.ssh (aus dem Gedächtnis. Punkt ist wichtig)
Entpacke eine oem.tz in einen Ordner. Dann hast du die Struktur die du brauchst. In dem Ordner legst du den Ordner .ssh an und schiebst deine Keys rein (Rechte beachten).
Danach packst du das alles wieder inc. der Ordnerstruktur.

Zum testen bau dir einen virtuellen ESX Server nach der Anleitung aus dem Forum hier.
Dann zersäbelst du dir auch nichts.

Gruß

Nur der Vollständigkeit halber:

Ich habe das jetzt mit der /etc/local.rc gelöst und es funktioniert tadellos.