SSH doesn't work on fresh install

[abedard]

Performing a fresh install of VME on new hosts.

After the initial install we can log into the console directly, but SSH doesn't work.

SSH answers, but the username and password don't work.

[SergeMe]

I assume you are talking about SSH on the Morpheus appliance, in which case the following are likely causes:

1. SSH password auth disabled globally: There is a setting in the VM Essentials appliance to “Disable SSH Password Authentication” so that only SSH keys are allowed for logins. If this is enabled by default in your build or was enabled during setup, any username/password will be rejected over SSH even though the same credentials work on the console
2. Different user account for SSH vs UI: VM Essentials manages its own user model and credentials, including Linux/SSH users and keypairs. The account you use for the web UI or the initial console configuration may not correspond to an OS-level user allowed to log in over SSH
3. SSH only permitting key‑based auth for provisioned hosts: The same appliance setting also affects VMs and hosts that the platform provisions, where it can intentionally block password-based SSH and only push keys. If you are testing SSH to those new hosts, you may be hitting this policy rather than a bad password

Here are a couple of things you could try to troubleshoot this:

1. From the local console (where you can log in): Verify the SSH daemon’s  PasswordAuthentication  setting in  sshd_config  and confirm whether it is set to  no in which case you want to change this to yes. 
2. In the VM Essentials UI, go to the main Settings / Appliance Settings and look for the option that disables SSH password authentication, and temporarily turn it off if you intend to use passwords
3. From the local console (where you can log in): Confirm which actual Linux user exists for SSH (sudo cat /etc/passwd), and reset that user’s password from the console if needed (sudo passwd <account>)

Hope that helps!

[abedard]

No, SSH on the hypervisor doesn't work

We haven't installed the UI yet

[SergeMe]

Could it be a keyboard mismatch?

Just checked on my HVM hosts and the default is to allow PasswordAuthentication for the user you create during setup. The root account is configured to prohibit-password. So if you are trying to login with root through SSH that won't work.

[abedard]

This is a fresh install

When I spun this up in my lab a month ago the user created during the install process could SSH in just fine without any other settings.

But it looks like they changed something in this new version, because that isn't the default behaviour anymore. SSH answers but the admin user created during the setup cannot login.

[Arnout_Verbeken]

What ssh client are you using?  I know from experience some clients do not have the corret cypher to connect.

Try with a different client, or try from another linux box with ssh -vvv  .  It will give you more output and tell you where it's stuck.

[lsantiagos01]

Hi,

Based on the thread and on the currently available HPE documentation, I don’t see evidence that SSH itself is unsupported on a fresh HVM install. Port 22 is part of the documented communication model, and SSH is documented as enabled in Linux-related workflows.

From the forum details, the key point is that SSH is responding, so this looks more like an authentication or client negotiation issue than a basic network/service issue. The two most likely checks are:

Make sure you are not trying to log in as root over SSH. In this thread it was already noted that root is configured as prohibit-password, while the user created during setup should be the one used for password-based SSH.

Validate the SSH client side with a verbose connection test (ssh -vvv user@host) from another Linux system, as cipher / auth negotiation issues were also raised in the discussion.

I would suggest confirming the following from the local console of the host:

exact username being used for SSH

whether password entry could be affected by keyboard layout mismatch

/etc/ssh/sshd_config values for PasswordAuthentication and PermitRootLogin

result of an ssh -vvv test from a different client

At this point, I do not see enough evidence to conclude that there was a documented product change in the new version regarding SSH default behavior. The thread suggests that possibility, but it is not confirmed by the documentation referenced here.

[abedard]

This issue magically fixed itself after a reboot