Too Many Authentication Failures when trying to ssh to SRM

With the release of the Photon based SRM server there were bound to be some issues pop up. One of these has to do with the sshd service and configuration.

What’s the issue?

Specifically the issue is with the MaxAuthTries option in the sshd.config, in which I found that it’s commented out. What does that mean? That means that even on the first attempt to ssh to the SRM server, the attempt will fail with the following error, ” Too Many Authentication Failures ” even though the sshd server is enabled.

Now that I know that it’s enabled, I will try to ssh in and find the failure.

$ ssh admin@
 The authenticity of host ' (' can't be established.
 ECDSA key fingerprint is SHA256:RQRJTht1Nrx3xaTOacPvar9PHi2rOeJlZ+9Swq5TSdw.
 Are you sure you want to continue connecting (yes/no)? yes
 Warning: Permanently added '' (ECDSA) to the list of known hosts.
 Welcome to VMware Site Recovery Manager Virtual Appliance
 Received disconnect from port 22:2: Too many authentication failures
 Disconnected from port 22

Which is interesting, considering I have never logged into the SRM server as it was just spun up minutes ago.

How do we fix it?

To fix it we will need to log into the SRM server via the Console. I’m logging in just with the web console in vCenter for the VM.

Once logged in as admin, we’ll want to edit the sshd config file with sudo, in this example I’m using vim.

Navigate down to the Authentication section and notice that the MaxAuthTries is commented out. Which means that we can’t even attempt to ssh to the SRM server, as there isn’t a try that is accepted.

In my case, there are going to be a couple of people that will need to access via ssh so I increased the MaxSessions to 3 and dropped the MaxAuthTries to 5. Ultimately I just need to remove the # from MaxAuthTries though.

Now that I have that completed, next is to restart the sshd service.

Once sshd has been restarted I am able to ssh into the SRM server successfully.

 $ ssh admin@
 Welcome to VMware Site Recovery Manager Virtual Appliance
 admin@'s password:
 Last login: Thu Oct 17 18:43:48 UTC 2019 on tty1
 Last login: Thu Oct 17 18:46:22 2019 from
 admin@ac-srm-1 [ ~ ]$

There we have it. Now myself and my colleagues can access the SRM server via SSH. I’m always partial to accessing the SRM server directly when needing to troubleshoot SRM workflows and failures.

Currently I have a partner case open with VMware to get this corrected ina future SRM release. Hopefully this helps out anyone else hitting this issue!

Posted in Site Recovery Manager, VMware.

Leave a Reply

Your email address will not be published.