Is it really necessary to encrypt state.tgz ?

[continuum]

In the past we had two reasons to deal with the archive state.tgz in /bootbank
Reason 1 was to look up or reset the root password.
Reason 2 was to reset settings made per accident - for example failed PassThru parameters.
Now with 7.0.3 state.tgz is encryped and instead of a manageable archive we now get
- encryption.info
- state.tgz.ve

Content of encryption.info may look like:
.encoding = "UTF-8"
includeKeyCache = "FALSE"
mode = "NONE"
ConfigEncData = "keyId=MrDAL2oJRmKafevVyriaHA%3d%3d:data1=DqN3HKeeTTGvMfX39grAcg%3d%3d:data2=xxBsv3gPQ2Go0TZX7IJceg%3d%3d:version=1"

Does this file has such a high attack risk that it makes sense to make emergency trouble-shooting a lot harder than it already was ???
Does anybody know how to decript the state.tgz.ve ?

Are we supposed to simply reinstall ESXi when ever a small issue - that we used to fix in earlier versions - occurs ?

Thanks Ulli

[aakalan]

I never saw someone editing this file.

for both problems you faced, there are other ways to solve them. I'm not sure editing this file or decrypting is supported.

[continuum]

>> I never saw someone editing this file.
Consider yourself lucky that you never needed to - but there are lots of reasons to work with this file.
Just an example ...
https://www.vmwareblog.org/forgot-esxi-root-password-no-problems-4-ways-reset/

I used this files many many times to look up ESXi - settings after a crash.
Or to remove references to datastores that no longer exist and resulted in a super slow ESXi boot - time.

Ulli

[Kinnison]

Comment removed...

[Chris_Ha]

Hi, if the state.tgz don't contain the shadow file, where is the "root" password stored?

to decrypt / encrypt the local.tgz.ve maybe the crypto-util can be used...

Decrypt or Re-Encrypt an Encrypted Core Dump (vmware.com)

but, to do this maybe we need a clean and fresh esxi installation, then bring the old local.tgz.ve into the system, decrypt the file with the tool, replace the shadow if still exists, encrypt the file with the same key(s) the replace the "old" with the "modified" ....

but i've still a question what is the alternative way if the system is stand alone and no other admin (root) user can be used...

before the system was used with AD Accounts, but the ad controller was removed...

there must be a way with a special "recovery-tool" by vmware...

best wishes

Chris

[EpicLPer]

This is probably done to comply with more higher-security-demanding companies such as government agencies and alike.

[Chris_Ha]

Yes, true but....

if i can re-attach the vm's with reinstallation of the ESXi --> lost of config / users and lost of licence informations...

it makes no sense for me... 

[Kinnison]

Comment removed...

[Chris_Ha]

im all fine with the idea...

but what brings a good documentation if there is no update or someone with permissions change the root password?

but if i can recover the mashines if i reinstall the ESXi and can access the unencryptet storage / VM'Guest so, it makes no sense for me to encrypt the shadow-file...

i'm clear to understand why its done but. the root don't secure the VM and don't secure the data...
and to reset the root, i need to reboot the system / to mount the partitions "offline" and if you can take the ESXi server 30 minutes down.
i a production environment, and nobody takes notice, it must be weekend, or a poor monitoring...

all is fine, but if i would like to steal the data, reinstall esxi put your own root, or better start the system with a own usb stick, grab access to the storage and copy the data to ....

i can do the test in a few days... i'll try to install a fresh install to a usb drive... and try to get access... to the vmdk or try to attach and run a vm from this server...

regards,

chris

[Kinnison]

Comment removed...

[GregChristopher]

I am dealing with this now too.

My challenge is that lately, I've seen esx randomly lose its network configuration. I have to go back in with F2 and reconfigure the network.  This has been related to adding network interfaces via USB, but it does stay stable. However something unpredictable and seemingly unrelated can knock it off its rock. If you are securely dealing with the network interfaces by creating extra dvs and kNics ... It's not so easy to recover the networking.

Now we can not edit the configuration offline, EVEN with physical access to the machine. Monitor has also been disabled unfortunately in my case, so no console.  Now I'm thoroughly hosed. Yet if I have physical access and the console is enabled ; does this really prevent me from getting the information off the device? Potentially.

These are the sort of changes that keep us from upgrading- then vmware claims it's our fault when we get hit by ESXiArgs for not upgrading/patching. It does not help that took several patches to get a stable update to ESXi 7.0.3. What's your appetite for applying patches immediately at this point? I think you're a fool if you don't try it out carefully first.

Stability is king in this business. That is ALL that matters. Backups should be necessary to keep my data safe, NOT to recover from vmware bugs.

[Avalon_Dante]

Sooo, is there anyway to actually unecrypt local.tz.ve on different esxi host\Linux VM?