We have a host running ESXi 184.108.40.20636589. 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.
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.
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 firstname.lastname@example.org,email@example.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.