ZIMBRA – system failure: exception during auth

Mensagem: system failure: exception during auth {RemoteManager: corp-lnx-mb-04.grupo.net.br->zimbra@corp-lnx-mb-04.grupo.net.br:22} Código de erro: service.FAILURE Method: [unknown] Detalhes:soap:Receiver

Comandos Utilizados…
/opt/zimbra/bin/zmcertmgr createca -new
/opt/zimbra/bin/zmcertmgr createcrt -new -days 365
/opt/zimbra/bin/zmcertmgr deploycrt self
/opt/zimbra/bin/zmcertmgr deployca
/opt/zimbra/bin/zmcertmgr viewdeployedcrt

ssh-keygen -t rsa

Mail Queue Overview
Incoming and outgoing mail is processed by postfix in a series of queues; normally, mail moves from the incoming queue to the active queue, from which it is delivered. If delivery is deferred, mail is moved to the deferred queue, and automatically reprocessed later.

Additionally, mail can be put in the hold queue, which will prevent it from being delivered until it is manually removed from the hold queue.

Monitoring Queues

Queues can be monitored from within the admin console; select Manage Mail Queues from the left sidebar and your queue information will be shown.

Troubleshooting Queue Monitoring

Common Errors

The most common problem is authentication to the mta server. This shows in the mailbox.log logfile as:

Message: system failure: exception during auth {RemoteManager: MAIL.DOMAIN.COM->zimbra@MAIL.DOMAIN.COM:22}

com.zimbra.cs.service.ServiceException: system failure: exception during auth {RemoteManager:


at com.zimbra.cs.service.ServiceException.FAILURE(ServiceException.java:174)

at com.zimbra.cs.rmgmt.RemoteManager.getSession(RemoteManager.java:197)

at com.zimbra.cs.rmgmt.RemoteManager.execute(RemoteManager.java:134)



Regenerating keys may very well fix this however, one other place to look is your /var/log/secure file. If you see something similar to:

sshd[16312]: Authentication refused: bad ownership or modes for directory /opt/zimbra

It’s possible you only need to fix your ownership and permissions.

su – zimbra

zmcontrol stop


Now login as root — this command must be run as root, run zmfixperms, and start zimbra back up:


su – zimbra

zmcontrol start

If this doesn’t fix any errors you’ll probably need to regenerate your keys.

Regenerating Keys

To regenerate the ssh keys, on all hosts (as the zimbra user):


To deploy the keys, on all hosts (as the zimbra user):


Verifying sshd configuration

The authentication method assumes that sshd on the mta is running on port 22, and that RSA Authentication is enabled. You can test the ssh command with:

ssh -i .ssh/zimbra_identity -o strictHostKeyChecking=no zimbra@MAIL.DOMAIN.COM

(Swap MAIL.DOMAIN.COM for your hostname, as it appears in the error).

You should NOT be prompted for a password; if you are, recreate the ssh keys and retry the test.

If you’re not running sshd on port 22, modify the zimbraRemoteManagementPort attribute on the server:

zmprov ms MAIL.DOMAIN.COM zimbraRemoteManagementPort 2222

Verify in /etc/sshd_config (or /etc/ssh/sshd_config) that the zimbra user is an allow user

AllowUsers admin zimbra

Note: applying this change resulted in not being to ssh as root. Should we add root to the list of AllowUsers!


The Zimbra hostname may be different than the system. Add the Zimbra hostname to /etc/hosts.allow .

ALL: zimbra.domain.tld

Zimbra account has been disabled

If the above steps do not work then enable verbose output for ssh with:

ssh -vi .ssh/zimbra_identity -o strictHostKeyChecking=no zimbra@MAIL.DOMAIN.COM

If the output from ssh indicates that Next authentication method: password as below, then the Zimbra account may be locked.

debug1: Next authentication method: publickey

debug1: Offering public key: /opt/zimbra/.ssh/zimbra_identity

debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive

debug1: Next authentication method: keyboard-interactive

debug1: Authentications that can continue: publickey,gssapi-with-mic,password,keyboard-interactive

debug1: Next authentication method: password

zimbra@MAIL.DOMAIN.COM’s password:

To verify this, as root check /etc/shadow. Locate the zimbra account. If the account has one or more ! in the line then the account is locked. zimbra:!!:13634:0:99999:7:::

Use this command to unlock the zimbra account (or you can edit the shadow file directly and remove them).

usermod -U zimbra

Then check /etc/shadow again, there should be no ! for the zimbra account. You may need to do this multiple times to remove the ! and unlock the account.

Once the account is unlocked, this command should work (it did for us!).

ssh -i .ssh/zimbra_identity -o strictHostKeyChecking=no zimbra@MAIL.DOMAIN.COM

SSH doesn’t allow Public Key Authentication

Edit the /etc/ssh/sshd_config (or other sshd config file) and look for the following line

PubkeyAuthentication no

This must be set to yes. Restart the SSH daemon and try again

Disable SELinux

Edit /etc/selinux/config

# This file controls the state of SELinux on the system.

# SELINUX= can take one of these three values:

# enforcing – SELinux security policy is enforced.

# permissive – SELinux prints warnings instead of enforcing.

# disabled – No SELinux policy is loaded.


# SELINUXTYPE= can take one of these two values:

# targeted – Only targeted network daemons are protected.

# strict – Full SELinux protection.


…and then reboot the system. For the other Linuxes which don’t have the /etc/selinux/config file, you just need to edit the kernel boot line, usually in /boot/grub/grub.conf, if you’re using the GRUB boot loader. On the kernel line, add selinux=0 at the end.

SSH bruteforce blockers

Note also that if you run a daemon of any sort to block SSH bruteforce attacks, any of the above SSH failures will probably cause that daemon to have tripped, in whatever fashion, and you’ll have to reset it, in /etc/hosts.allow or wherever else it may block. fail2ban can probably cause this as well.