Jump to content
NAKIVO Community Forum

10.4.1.59487 doesn't work with free VMWare 7.0.1


Mike Spragg
 Share

Recommended Posts

Problem resolved - if you applied the March fix (adjust sshd_config) then you need to revert those changes as per enclosed. Once done, stop/start ESXi ssh service and all works fine 

Unfortunately, I can't attach the file but here it is below as text.

# Version 7.0.2.1

# running from inetd
# Port 22
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_ecdsa_key

# Fips mode restricts ciphers to only FIPS-permitted ciphers
FipsMode yes

# vPP FCS_SSH_EXT.1.7: rekey after 1GB, 1H (instead of default 4GB for AES)
RekeyLimit 1G, 1H

SyslogFacility auth
LogLevel info

PermitRootLogin yes

PrintMotd yes

TCPKeepAlive yes

# Key algorithms used in SSHv2 handshake
# (ed25519 not allowed by current FIPS module)
KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-256,hmac-sha2-512

UsePAM yes
# only use PAM challenge-response (keyboard-interactive)
PasswordAuthentication no

Banner /etc/issue

Subsystem sftp /usr/lib/vmware/openssh/bin/sftp-server -f LOCAL5 -l INFO

AuthorizedKeysFile /etc/ssh/keys-%u/authorized_keys

# Timeout value of 10 mins. The default value of ClientAliveCountMax is 3.
# Hence, we get a  3 * 200 = 600 seconds timeout if the client has been
# unresponsive.
ClientAliveCountMax 3
ClientAliveInterval 200

# sshd(8) will refuse connection attempts with a probability of "rate/100"
# (30%) if there are currently "start" (10) unauthenticated connections.  The
# probability increases linearly and all connection attempts are refused if the
# number of unauthenticated connections reaches "full" (100)
MaxStartups 10:30:100

# ESXi is not a proxy server
AllowTcpForwarding no
AllowStreamLocalForwarding no

# The following settings are all default values. They are repeated
# here to simplify auditing settings (for example, DoD STIG).
IgnoreRhosts yes
HostbasedAuthentication no
PermitEmptyPasswords no
PermitUserEnvironment no
StrictModes yes
Compression no
GatewayPorts no
X11Forwarding no
AcceptEnv
PermitTunnel no

# The following settings are disabled during the OpenSSH build.
# They are commented out to avoid spurious warnings in log files.
#GSSAPIAuthentication no
#KerberosAuthentication no


 

Link to comment
Share on other sites

These are the particular lines that need reverting back:

KexAlgorithms ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256
HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-256,hmac-sha2-512
Link to comment
Share on other sites

Hi, @Mike Spragg!

Could you please clarify if your VMWare host is the Free ESXi version? If yes, with the Free ESXi version, we have some limitations, and they come from VMWare.

When we make any changes or update Nakivo, we should check the 'sshd_config' file again inside the ESXi host to make connections and inventory from the Nakivo application.

If you need any further assistance, please let me know.

Link to comment
Share on other sites

Hi, yes - it is the free ESXi version (not full vSphere). Actually, the limitations were there up until v10.4.0 and you had to make changes to 'sshd_config' to make it work - however, with the v10.4.1 release those limitations were removed and customers who had already made this change need to revert back to the ordinary/vmware supplied sshd_config - otherwise, it no longer works and has issues with inventory on VMWare. In other words, in 10.4.1 you fixed the original bug that required VMWare to be run with less security for SSH than VMWare was expecting. 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...