Don't use a password. Generate a passphrase-less SSH key and push it to your VM.
If you already have an SSH key, you can skip this step…
Just hit Enter for the key and both passphrases:
$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.
Copy your keys to the target server:
$ ssh-copy-id id@server
id@server's password:
Now try logging into the machine, with ssh 'id@server', and check-in:
.ssh/authorized_keys
Note: If you don't have .ssh dir and authorized_keys file, you need to create it first
to make sure we haven’t added extra keys that you weren’t expecting.
Finally, check to log in…
$ ssh id@server
id@server:~$
You may also want to look into using ssh-agent if you want to try keeping your keys protected with a passphrase.
I managed to fix this moments after posting the question.
It turns out that the /etc/shadow entries for the affected MD5 password users had somehow had the field after the hashed password duplicated, causing PAM to be unable to interpret the line. In other words, a bad cut and paste job.
I haven't had enough coffee...
Best Answer
OK the problem is a bug in VMWare ESXi 5.5 : If you change a password to something longer than 30 characters it will not complain but your password will be changed anyway to only the first 30 chars of the provided password ! To be able to login again, you have to use the first 30 chars of your password.