Information2 use cookies to help you have a superior and more admissible browsing experience on our website. Privacy Policy
Loading...
By:
When administrators try to connect to a VMware vCenter Server Appliance (VCSA) through SSH, they may encounter an error such as:
“Received disconnect from x.x.x.x: 2: Too many authentication failures”
Or
“Server sent disconnect message type 2 (protocol error): Too many authentication failures”
Don’t worry, this guide will explain why the error happens, how to troubleshoot it step by step, and the best practices VMware administrators can follow to prevent similar SSH authentication problems in production environments.
When you initiate an SSH connection, your SSH client automatically offers every public key it finds in ~/.ssh/ (and any keys loaded into your SSH agent) to the server, one by one. The vCenter Server Appliance (VCSA) runs on VMware’s Photon OS, which has a very low MaxAuthTries limit — often set to 2. That means after the server rejects just two offered keys, it terminates the connection before ever asking for your password.
The root cause is almost always client-side: your SSH client is offering too many invalid keys too quickly, exhausting the server’s limit before password authentication even gets a turn.
That said, there are also server-side causes: AllowGroups restrictions in sshd_config, a locked root account from pam_tally2 or faillock, or an expired root password. By default, the vCenter Appliance root password expires every 90 days.
The table below shows the symptom, likely cause, and fix; you can refer to it in the next section.
|
Symptom |
Likely Cause |
Recommended Fix |
|
Connection dropped immediately, no password prompt |
Client offering too many SSH keys |
Fix 1 or Fix 2 |
|
Password prompt appears, but authentication fails |
Root password expired, AllowGroups restriction, or wrong credentials |
Fix 3 or Fix 5 |
|
Message: “Account locked” or similar |
PAM tally or faillock lockout |
Fix 6 |
|
You can log in with SSO account but not root |
Root password expired or locked |
Fix 5 |
|
You’re completely locked out of SSH |
Multiple issues combined |
Fix 7 (VAMI) |
Run ssh -v root@vcenter-ip to see exactly what’s happening during the connection attempt. The verbose output will show you which keys are being offered and where the failure occurs.
Before getting down to any fixes, please back up your VMware VMs in case of any misoperation. Info2soft i2Backup is a robust backup solution that allows backup of all VMs from an intuitive interface. Support backup scheduling, agentless backup, immutable backup, and more. Click the button to get a 60-day free trial.
Before get down to any fixes, please back up your VMware VMs in case of any misoperation. Info2soft i2Backup is a robust VMware backup solution that allows backup all virutal machines from an intuitive interface. Support backup scheduling, agentless backup, immutable backup, and more.
This is the fastest fix to solve it. It tells your SSH client not to present any public keys, forcing it to proceed directly to password authentication.
One-liner command:
ssh -o PubkeyAuthentication=no root@vcenter-ipReplace vcenter-ip with your vCenter’s FQDN or IP address. You’ll be prompted for the root password immediately.
Permanent client configuration:
Add this to your ~/.ssh/config file:
Host vcenter-ip
PubkeyAuthentication noNow every SSH connection to that host will skip key authentication.
When this fix works: When the connection drops before the password prompt and you know the root password is correct.
Limitation: This only works if the root account is not locked and the password is valid. If you’re locked out due to failed password attempts, this won’t help.
If you want to keep using SSH keys for other hosts but stop your client from flooding vCener with irrelevant keys, use the IdentitiesOnly option.
This tells SSH to only use the key you explicitly specify, ignoring all others in ~/.ssh/ and your SSH agent.
Permanent configuration in ~/.ssh/config:
Host vcenter-ip
IdentitiesOnly yes
IdentityFile ~/.ssh/your-vcenter-keyOne-liner:
ssh -o IdentitiesOnly=yes -i ~/.ssh/your-vcenter-key root@vcenter-ipAlternative: Clean up your ~/.ssh/ directory. Remove old or unused keys — especially if you have both RSA and Ed25519 keys, as SSH will offer both. Each rejected key counts toward MaxAuthTries.
If the above fixes not working, the problem may be on the vCenter server itself.
AllowGroups wheel in /etc/ssh/sshd_config restricts SSH access only to members of the wheel group. If root isn’t in that group (or the line is present and uncommented), root login via SSH will fail.
How to check:
cat /etc/ssh/sshd_config | grep AllowGroupsIf you see AllowGroups wheel, that’s the root cause.
How to Fix:
Way 1. Comment out the restriction (widens access):
vi /etc/ssh/sshd_config
# Change this line:
# AllowGroups wheelWay 2. Add root to AllowGroups
AllowGroups wheel root
Restart SSH:
systemctl restart sshdYou can increase the MaxAuthTries limit to give your client more attempts before the connection is terminated. Photon OS defaults to 2, while STIG compliance requires 6.
How to check current value:
sshd -T | grep -i maxauthtriesHow to change it:
Edit /etc/ssh/sshd_config:
MaxAuthTries 6Restart SSH:
systemctl restart sshdIf you’ve lost or forgotten the root password, or it has expired, but you still have a working SSO administrator account, you can recover root access without a reboot.
Step 1. SSH in with your SSO account.
ssh administrator@administrator accountStep 2. Enable the shell:
shell.set --enable true
shellStep 3. Reset root password:
sudo passwd rootStep 4. Verify:
sudo -iEnter the new root password to confirm.
If you’ve attempted SSH login with the wrong password multiple times, the root account may be locked by PAM (Pluggable Authentication Modules).
Critical version difference:
|
vCenter Version |
Command |
|
8.0 U1 and earlier |
pam_tally2 –user root –reset |
|
8.0 U2 and later |
/usr/sbin/faillock –user root –reset |
Starting from 8.0 U2, the unlock policy in vCenter Server changed from pam_tally2 to faillock
Check failed login count:
# 8.0 U1 and earlier
pam_tally2 --user root
# 8.0 U2 and later
/usr/sbin/faillock --user root
Unlock the account:
# 8.0 U1 and earlier
pam_tally2 --user root --reset
# 8.0 U2 and later
/usr/sbin/faillock --user root –reset⚠️ Important lockout behavior in vCenter 8.0 U2+:
Workaround for appliance shell lockout: Switch root’s default shell to /bin/bash
chsh -s /bin/bash rootThis also enables key-based passwordless authentication.
You need existing SSH or console access to run these commands. If you’re completely locked out of SSH, use Fix 7 (VAMI) first to regain access, then run the unlock command.
If none of the client-side tricks worked, your account’s locked, or you fat-fingered sshd_config and broke SSH entirely. It happens. Don’t panic—you’ve still got a way in.
Fire up a browser and hit the VAMI web interface on port 5480. It’s the appliance’s management console, and it doesn’t care whether your SSH daemon is having a meltdown.
What is VAMI? The vCenter Appliance Management Interface runs on port 5480 and provides a web-based management console for the appliance.
Access VAMA:
https://vcenter-ip:5480Login credentials: Use your SSO Admin credentials (administrator@vsphere.local), not the root password.
What you can do from VAMI:
If the root user is locked and you need to unlock it via VAMI:
Step 1. Log in to VAMI with SSO Admin credentials.
Step 2. Enable the bash shell: shell.set –enable true
Step 3. Enter the bash shell: shell
Step 4. Unlock the root user:
1. SSH key management:
2. Client configuration:
3. Server hardening (documented):
4. Root shell configuration:
5. Password expiration management:
6. Monitoring:
7. Automation:
Administrators occasionally lose direct access to critical infrastructure due to authentication issues, configuration mistakes, or unexpected system failures.
Even if SSH access is temporarily unavailable, your ability to quickly recover VMware workloads should never depend on a single management interface. That’s why many organizations combine proactive troubleshooting with a comprehensive backup and recovery strategy.
For enterprises running VMware vSphere environments, i2Backup provides agentless backup and recovery for virtual machines, helping IT teams protect business-critical workloads against hardware failures, accidental deletion, ransomware attacks, and other unexpected incidents. Built on VMware’s native backup APIs, i2Backup supports consistent VM backups without installing agents inside guest operating systems, reducing administrative overhead while minimizing performance impact.
Key capabilities include:
Just hit the button below to request a 60-day free trial and we will contact you as soon as possible.
The “Too many authentication failures” error in vCenter is usually caused by the SSH client attempting too many authentication methods before reaching the correct credentials—not by an incorrect password. In most cases, the issue can be resolved by limiting SSH identities, cleaning up the SSH agent, or correcting the client configuration.
To minimize future authentication issues, follow SSH best practices such as using dedicated identity files, managing SSH keys carefully, and regularly reviewing access settings.
For VMware environments, it’s also important to be prepared for unexpected infrastructure issues beyond SSH access. A reliable VMware backup solution like Info2soft i2Backup helps protect virtual machines and enables fast recovery, ensuring business continuity even when administrative access is temporarily unavailable.
