Mike Spragg
-
Posts
13 -
Joined
-
Last visited
-
Days Won
1
Posts posted by Mike Spragg
-
-
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.
-
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
-
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
-
Correction VMWare 7.0.2, not 7.0.1
-
As per topic - looks like the old (March 2021) bug is back - can't connect to inventory. This is via QNAP (.qpkg). Anyone else seeing this - have raised ticket.
-
34 minutes ago, Axel said:
Hello,
@Mike Spragg can you please explain how exactly the "sshd_config" file is modified?
Is ist possible to make the changes remote? Maybe you can explain the necessary steps?
Thank you in advance!
Axel
Either remotely collect it using Win SCP and edit it locally. Or use Vi. You just alter the 3 lines shown in the thread. You can do it remotely if you can ssh into box remotely (switch this on in VMWare).
- 1
-
2 minutes ago, Official Moderator said:
@Ponord59, hi! Just in case you need more information, please refer to this article:
https://helpcenter.nakivo.com/display/KB/SSH+Requirements+for+NAKIVO+Backup+and+Replication
Hi - is it possible that this article is modified - it doesn't say what to change only what requirements are and a little vague. Just needs direction to modify /etc/ssh/sshd_config and to modify those lines mentioned above e.g.
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,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512,ssh-rsa,ssh-dss
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1,hmac-md5-96,hmac-md5This adds the right KexAlgorithm, HostKeyAlgorithms and Ciphers
That way, it's more specific to the solution. Thanks !!
- 1
-
1 hour ago, Ponord59 said:
Hi
# running from inetd
# Port 22what is inetd, a program? I do it via putty
thanks
That's not the relevant part - the "file" (as I can't attach it) are shown above - you only need to modify the lines:
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,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512,ssh-rsa,ssh-dss
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1,hmac-md5-96,hmac-md5This adds the right KexAlgorithm, HostKeyAlgorithms and Ciphers (the original shows what they are now in 7.0U1)
The file you need to modify is /etc/ssh/sshd_config
- 1
-
Is this downgradeable to 10.3 if things go wrong?
-
1 minute ago, gianni said:
Thank you very much. I solved the problem, but i don't understand. This problem shows up with the latest version of vmware (7.02) because with 7.0 i never had this problem.
Correct, you didn't. In 7.0U2 they [VMWare] uprated/hardened the security requirements through ssh. By doing this change you've reverted that change by VMWare.
- 1
-
3 minutes ago, Official Moderator said:
Hey, @Mike Spragg!
What an awesome response. Thank you for contributing to NAKIVO forum!
Thank you ! I hit this problem pretty much straight away as soon as 10.3 came out. Unfortunately, there is a down side insofar as you are weakening what was a hardened system so hopefully fixed in 10.4 without the need to do this.
- 1
-
You have to modify VMWare itself:
https://helpcenter.nakivo.com/display/KB/SSH+Requirements+for+NAKIVO+Backup+and+Replication
without the mods to sshd_config - it will never see it.
KexAlgorithms
HostKeyAlgorithms
CiphersI've include the original and replacement files.
Changed:
# 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, 1HSyslogFacility auth
LogLevel infoPermitRootLogin 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,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
HostKeyAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-256,rsa-sha2-512,ssh-rsa,ssh-dss
Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr
MACs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1,hmac-md5-96,hmac-md5UsePAM yes
# only use PAM challenge-response (keyboard-interactive)
PasswordAuthentication noBanner /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
Original
# 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, 1HSyslogFacility auth
LogLevel infoPermitRootLogin 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-512UsePAM yes
# only use PAM challenge-response (keyboard-interactive)
PasswordAuthentication noBanner /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
- 1
10.4.1.59487 doesn't work with free VMWare 7.0.1
in VMware backup
Posted
Hi, not sure what's happening here. Original issue was that 10.4.1 doesn't work with 7.0 U2. However, upon checking and reverting the changes I'd made previously in March to support 10.4.0 and 7.0 U2 it now works. So, there's nothing further to do here. All good !