Unable to log into ESXi host via SSH or SCP: Remote side unexpectedly closed network connection
search cancel

Unable to log into ESXi host via SSH or SCP: Remote side unexpectedly closed network connection

book

Article ID: 325697

calendar_today

Updated On:

Products

VMware vSphere ESXi

Issue/Introduction

Symptoms:
  1. You are unable to log into an ESXi host via SSH or SCP and see the following client error:
    Remote side unexpectedly closed network connection
     
  2. You see an event similar to the following, via shell in /var/log/auth.log, or via remote syslog:
    2019-09-30T18:01:17Z sshd[229828]: fatal: FIPS mode incompatible with SSH2 cipher spec 'TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256'.


Environment

VMware vSphere ESXi 6.5

Cause

This issue occurs because of an incompatible Ciphers line in the /etc/ssh/sshd_config file for the chosen ESXi server.

Resolution

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:
  1. Log into the ESXi server's shell. For additional instructions, see Using ESXi Shell in ESXi 5.x, 6.x and 7.x
  2. Navigate to /etc/ssh
  3. Make a backup copy of the sshd_config file: cp sshd_config sshd_config.bak
  4. Open the sshd_config file with vi editor. For additional instructions, see Editing files on an ESX host using vi or nano
  5. Correct the Ciphers line in sshd_config:
    Ciphers aes128-ctr,aes192-ctr,aes256-ctr,aes128-cbc,aes192-cbc,aes256-cbc
     
  6. Note: This line's default contents varies between major ESXi releases. For ESXi 7.0 GA:
    Ciphers [email protected],[email protected],aes256-ctr,aes192-ctr,aes128-ctr
     
  7. 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).