j_edington's Posts

Update: some further research, the problem seems to have been a failed attempt to tighten the cipher security settings. The "solution" to this is described at VMWare KB74958, but it seems to require... See more...
Update: some further research, the problem seems to have been a failed attempt to tighten the cipher security settings. The "solution" to this is described at VMWare KB74958, but it seems to require shell access: To correct this issue, modify or restore the Ciphers line in /etc/ssh/sshd_config, or revert the file to its default parameters, as found in your running release of ESXi server. To modify the Ciphers line in /etc/ssh/sshd_config: Log into the ESXi server's shell. For additional instructions, see KB2004746 Navigate to /etc/ssh Make a backup copy of the sshd_config file: cp sshd_config sshd_config.bak Open the sshd_config file with vi editor. For additional instructions, see KB1020302 Correct the Ciphers line in sshd_config: Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc Note: This line's default contents varies between major ESXi releases. For ESXi 7.0 GA: Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr When finished, restart the SSH service: /etc/init.d/ssh restart Alternatively, if you have another ESXi server of the same update level that is not producing errors upon connecting, you can compare its /etc/ssh/sshd_config configuration file contents with the impacted server's, and make adjustments, accordingly, or even copy the working configuration file to a shared datastore for eventual overwriting on the affected ESXi server(s). Obviously, we do not have SSH access to get in and fix this. How can we get in instead? I tried googling around for the "ESXi shell" (formerly Tech Support Mode) client to get in even when SSH is broken, but can't find how to access it.
We have a host running ESXi 7.0.3.20036589. It is attached to a VCSA running on it. We are unable to log into the host via SSH due to what seems to be the host firewall, and we cannot seem to add a ... See more...
We have a host running ESXi 7.0.3.20036589. It is attached to a VCSA running on it. We are unable to log into the host via SSH due to what seems to be the host firewall, and we cannot seem to add a rule allowing this because that can only be done via SSH: With the security changes implemented in vSphere 7.0 (reference KB https://kb.vmware.com/s/article/78689) the only supported way to open up ports is through a partner-created VIB to open the ports or change the files needed. … Resolution … 1. Open an SSH connection to the host. Am I misinterpreting this, or have we bricked this host from being SSH accessed from here on out? How can I modify the ESXi host firewall to allow inbound SSH access [the service is running] when I don't currently have SSH access? We are still able to log in via the web client, and the VCSA (which we are also able to access the web client of) seems to be still successfully managing the host.
A popular security recommendation for vCenter 6.7 specifies that all Cron files should be owned by root:root, but I see that one of these files is owned by a system group on vCenter 7.0:   -rw-r---... See more...
A popular security recommendation for vCenter 6.7 specifies that all Cron files should be owned by root:root, but I see that one of these files is owned by a system group on vCenter 7.0:   -rw-r----- 1 root cis 93 Jul 22 07:18 /etc/cron.d/vpxd_periodic.cron   What does this do? What would the consequences (if any) to system stability, security, or functionality be of changing the group of this file from cis to root?
The solution turned out to be leaving the FQDN field empty. (I was previously putting "vsphere.local" into it, to match the hostname.) Leaving the field blank causes the FQDN to be autocalculated as... See more...
The solution turned out to be leaving the FQDN field empty. (I was previously putting "vsphere.local" into it, to match the hostname.) Leaving the field blank causes the FQDN to be autocalculated as hostname-else-IP (depending on rDNS, per the field's hint), and will therefore work on all of the following: Statically addressed networks with reverse DNS Statically addressed networks without reverse DNS Dynamically addressed networks with reverse DNS (I'm unclear on what the appropriate setting is for networks that use dynamic addressing and do not have reverse DNS. I suspect that, in that case, forward DNS becomes a requirement, and the vCS' resolveable hostname should then be entered as the FQDN, but I cannot confirm this at this time.) It's worth noting that entering the IP directly into the FQDN box (per André's suggestion above) may provide a slight speedup during installation, for networks that use static IP addressing and do not have reverse DNS. I'm unclear on whether doing so will introduce additional complexity during re-addressing, if IPs are changed in the future.
There is no DNS on this network. No external resolver access, and no local DNS server. The VCSA is the first node on this closed network only after the ESXi server it resides on.
I've got a Dell R540 server running ESXi version 7.0.7 (VMKernel Release Build 20036586). I'm trying to add the VCenter Server Appliance version 7.0.3-20150588 to the server. I downloaded and mount... See more...
I've got a Dell R540 server running ESXi version 7.0.7 (VMKernel Release Build 20036586). I'm trying to add the VCenter Server Appliance version 7.0.3-20150588 to the server. I downloaded and mounted the ISO per the instructions, ran the GUI from my Windows 10 workstation, and Stage 1 seemed to go fine. However, Stage 2 has been stuck since yesterday. The GUI hung, so I closed it and checked from the web browser—it's still stuck! The response from the server doesn't offer much insight: { "state": "CONFIG_IN_PROGRESS", "progress": { "total": 3, "completed": 2, "message": { "id": "install.ciscommon.component.starting", "default_message": "Starting VMware Appliance Configuration...", "args": [ "VMware Appliance Configuration" ] } }, "subtask_order": [ "rpminstall", "validate", "firstboot" ], "subtasks": [ { "key": "rpminstall", "value": { "progress": { "total": 100, "completed": 100, "message": { "id": "com.vmware.vcenter.deploy.task.complete.success", "default_message": "Task has completed successfully.", "args": [] } }, "description": { "id": "com.vmware.vcenter.deploy.task.description.rpminstall", "default_message": "Install required RPMs for the appliance.", "args": [] }, "service": "", "operation": "", "status": "SUCCEEDED", "cancelable": false, "start_time": "2022-08-10T22:20:39.125Z", "end_time": "2022-08-10T22:28:52.594Z" } }, { "key": "validate", "value": { "progress": { "total": 100, "completed": 100, "message": { "id": "com.vmware.vcenter.deploy.task.complete.success", "default_message": "Task has completed successfully.", "args": [] } }, "description": { "id": "com.vmware.vcenter.deploy.task.description.validate", "default_message": "Validate input parameters.", "args": [] }, "service": "", "operation": "", "status": "SUCCEEDED", "cancelable": false, "start_time": "2022-08-11T14:56:49.756Z", "end_time": "2022-08-11T14:56:49.758Z" } }, { "key": "firstboot", "value": { "progress": { "total": 100, "completed": 0, "message": { "id": "install.ciscommon.component.starting", "default_message": "Starting VMware Appliance Configuration...", "args": [ "VMware Appliance Configuration" ] } }, "description": { "id": "com.vmware.vcenter.deploy.task.description.firstboot", "default_message": "Run firstboot scripts.", "args": [] }, "service": "", "operation": "", "status": "RUNNING", "cancelable": false, "start_time": "2022-08-11T14:56:51.832Z" } } ], "description": { "id": "com.vmware.vcenter.deploy.task.description.op.install", "default_message": "Install vCenter Server appliance.", "args": [] }, "service": "", "operation": "INSTALL", "status": "RUNNING", "cancelable": false, "start_time": "2022-08-10T22:20:39.125Z" } Does anyone have insight or advice on this?