Ошибку я впервые увидел в админке Zimbra, когда открыл статистику почтовых очередей: system failure: exception during auth {RemoteManager: mail4biz.ru->zimbra@mailserver:22} Код ошибки: service.FAILURE Method: [unknown] Детали: soap:Receiver. Тот же текст попадает в /opt/zimbra/log/mailbox.log. Причина была в том, что SSH на сервере переехал с 22-го порта на другой, а Zimbra об этом не знала.
Коротко: укажите Zimbra реальный порт SSH — zmprov ms $(zmhostname) zimbraRemoteManagementPort 2222 (или zmprov mcf … для всех серверов), затем при необходимости пересоздайте ключи zmsshkeygen и zmupdateauthkeys и проверьте, что пользователь zimbra может зайти по ключу на этот порт.
Откуда берётся ошибка
Часть операций — просмотр и управление очередями Postfix, резервная копия LDAP, некоторые команды статуса — mailbox-сервер выполняет на MTA-сервере через механизм RemoteManager. Он подключается по SSH под пользователем zimbra с ключом /opt/zimbra/.ssh/zimbra_identity и запускает /opt/zimbra/libexec/zmrcd. На однохостовой установке Zimbra ходит по SSH сама к себе.
Строка в фигурных скобках расшифровывается так: {RemoteManager: локальный_сервер->пользователь@хост:порт}. Хост — значение zimbraServiceHostname целевого сервера, порт — атрибут zimbraRemoteManagementPort. Если авторизация по SSH не прошла по любой причине, вы получаете exception during auth.
Связанные атрибуты (значения по умолчанию из схемы Zimbra):
zimbraRemoteManagementPort— 22;zimbraRemoteManagementUser—zimbra;zimbraRemoteManagementPrivateKeyPath—/opt/zimbra/.ssh/zimbra_identity;zimbraRemoteManagementCommand—/opt/zimbra/libexec/zmrcd.
Все они задаются глобально и на уровне сервера; значение сервера перекрывает глобальное.
Шаг 1. Посмотреть текущие значения
su - zimbra
zmprov gs $(zmhostname) zimbraRemoteManagementPort
zmprov gcf zimbraRemoteManagementPort
И на каком порту реально слушает sshd (от root):
ss -tlnp | grep sshd
Если порты расходятся — причина найдена.
Шаг 2. Указать правильный порт
Для одного сервера (рекомендуемый вариант из wiki Zimbra):
su - zimbra
zmprov ms $(zmhostname) zimbraRemoteManagementPort 2222
Если SSH перенесён на всех серверах кластера, можно поменять глобальное значение:
zmprov mcf zimbraRemoteManagementPort 2222
Глобальное значение не подействует на сервер, у которого порт уже задан явно, — тогда нужен zmprov ms. В схеме атрибута отмечено, что изменение требует перезапуска mailbox. У меня в своё время всё заработало сразу, но если ошибка осталась, перезапустите только эту службу:
zmmailboxdctl restart
Шаг 3. Пересоздать ключи SSH
Если порт правильный, а ошибка осталась, чаще всего проблема в ключах: их удалили, испортили права или при переносе сервера скопировали старые. Пересоздание выполняется от пользователя zimbra:
su - zimbra
zmsshkeygen
zmupdateauthkeys
zmsshkeygen создаёт новую пару RSA 2048 в /opt/zimbra/.ssh/zimbra_identity и записывает публичный ключ в LDAP (атрибут zimbraSshPublicKey). zmupdateauthkeys собирает ключи всех серверов из LDAP и пересобирает /opt/zimbra/.ssh/authorized_keys; каждая строка начинается с command="/opt/zimbra/libexec/zmrcd", то есть по этому ключу можно запускать только zmrcd. В многосерверной установке zmupdateauthkeys нужно выполнить на каждом узле.
Права, без которых sshd отвергнет ключ:
chown -R zimbra:zimbra /opt/zimbra/.ssh
chmod 700 /opt/zimbra/.ssh
chmod 600 /opt/zimbra/.ssh/zimbra_identity
Каталог /opt/zimbra тоже не должен быть доступен на запись группе или всем — иначе при StrictModes yes (так по умолчанию) sshd не примет authorized_keys.
Шаг 4. Проверить SSH вручную
Проверка из wiki Zimbra, с указанием вашего порта:
su - zimbra
ssh -i .ssh/zimbra_identity -o StrictHostKeyChecking=no -p 2222 zimbra@$(zmhostname)
Пароль спрашиваться не должен. Если спрашивает — ключ не принят. Обычного приглашения командной строки не будет из-за принудительной команды zmrcd, выйти можно по Ctrl+C. Подробный вывод даёт ключ -v: ssh -v -i .ssh/zimbra_identity -p 2222 zimbra@$(zmhostname). Подключение к localhost тоже стоит проверить, но RemoteManager ходит именно на имя из zmhostname, а оно может резолвиться во внешний IP.
Шаг 5. Настройки sshd и файрвола
- Если в
/etc/ssh/sshd_configестьAllowUsersилиAllowGroups, добавьте тудаzimbra(wiki Zimbra приводит примерAllowUsers admin zimbra). - Не должно быть
PubkeyAuthentication no. - Файрвол и fail2ban не должны блокировать подключение сервера к собственному адресу на порту SSH.
- После правки:
sshd -t, затемsystemctl reload ssh(Debian/Ubuntu) илиsystemctl reload sshd(AlmaLinux/Rocky).
Причину отказа sshd пишет в /var/log/auth.log (Debian/Ubuntu) или /var/log/secure (AlmaLinux/Rocky); на любом дистрибутиве работает journalctl -u ssh или journalctl -u sshd. Если при переносе SSH вы заодно перекладывали файлы между серверами, пригодится заметка про scp, sftp и rsync.
| Симптом | Причина | Решение |
|---|---|---|
В ошибке :22, а SSH на другом порту | Не обновлён zimbraRemoteManagementPort | zmprov ms $(zmhostname) zimbraRemoteManagementPort <порт> |
| Порт правильный, ручной ssh просит пароль | Нет ключа в authorized_keys или неверные права | zmsshkeygen, zmupdateauthkeys, проверить права |
Ручной ssh: Permission denied (publickey), в логе sshd «not listed in AllowUsers» | Пользователь zimbra не разрешён в sshd | Добавить zimbra в AllowUsers |
Ручной ssh висит или Connection refused | Файрвол, sshd слушает другой адрес | Проверить ss -tlnp и правила файрвола |
Частые вопросы
Нужно ли перезапускать Zimbra целиком?
Нет. Достаточно изменить атрибут; если ошибка сохраняется, перезапустите только mailboxd командой zmmailboxdctl restart. Полный перезапуск описан в статье Перезапуск Zimbra: команды zmcontrol.
Чем отличаются zmprov ms и zmprov mcf?
ms (modifyServer) меняет атрибут конкретного сервера, mcf (modifyConfig) — глобальную конфигурацию, которую наследуют серверы без собственного значения.
Можно ли вернуть SSH на 22 порт только для Zimbra?
sshd умеет слушать несколько портов (несколько строк Port), но тогда 22-й снова открыт снаружи, если не закрыть его файрволом. Проще один раз прописать нестандартный порт в Zimbra.