Zimbra quebrado após proteger o SSH

Question

Eu tenho um servidor CentOS 5.7 com o Zimbra instalado e tudo funcionando bem.

Acabei de proteger o SSH por:

• mudando para outra porta
• negando o login da raiz
• ativando StrictModes
• alterou AllowUsers para apenas 1 usuário (não zimbra)
• desativando RSAAuthentication
• ativando PubkeyAuthentication
• desativando PasswordAuthentication
• desativando ChallengeResponseAuthentication

O acima funciona para o SSH ao servidor como o usuário permitido e su'ing ao root / sudoing.

No entanto, quando eu faço login no meu webmail, não consigo mais enviar / receber mensagens. Eeek!

Ao fazer algumas buscas na web, parece que o Zimbra usa o ssh internamente para conversar com outros módulos Zimbra.

Alguém sabe como consertar isso?

    

Answer 1

Eu não posso testar isso porque eu não tenho uma configuração de teste do Zimbra para trabalhar, mas eu suspeitava que adicionar o zimbra user a AllowUsers e configurar a porta ssh de volta para 22 deveria ser suficiente.

Se você está nervoso em expor o ssh em uma porta padrão, deve ser possível configurar sshd para ouvir em sua porta alternativa, bem como na porta 22, e usar iptables para limitar o acesso à porta 22 ao Apenas endereço IP local. (Pessoalmente, prefiro deixar o ssh em sua porta padrão e limitar os endereços IP de origem, mas isso pode não ser prático se você não tiver um endereço IP de origem fixo.)

Se você está nervoso em expor o usuário zimbra para o mundo, talvez você queira procurar em pam_access para limitar de quais endereços IP o usuário zimbra pode usar o SSH.

Dito isso, tenho a sensação de que, de acordo com os sintomas que você listou, há mais coisas acontecendo com o seu servidor do que apenas o acesso SSH quebrado. O Zimbra não requer o ssh para si mesmo para tarefas de rotina como enviar e-mail, mas principalmente para propósitos administrativos. Você provavelmente deseja verificar os registros em /var/log e /opt/zimbra/log .

    

Answer 2

Sugiro que você volte para a configuração original e ative um recurso por vez.

A principal coisa que você pode fazer é definir o login root como "sem senha" para impedir o login de senha para o root (enquanto permite a autenticação de chave, se necessário).

Para portas ssh, você tem um hardware ou firewall externo em seu ambiente? Se assim for, você pode ter ssh ouvir várias portas. 22 e 2222, por exemplo. Apenas limite o acesso de entrada do mundo para sua porta alternativa.

Acho que a diretiva AllowUsers pode fazer parte do problema. Você poderia determinar isso através do exame de seus registros / var / log / secure.

    

Answer 3

Não há necessidade de voltar para a porta 22 (eu uso 1234 aqui):

# su - zimbra
$ zmprov ms domain.tld zimbraRemoteManagementPort 1234
$ ssh -vi .ssh/zimbra_identity -o strictHostKeyChecking=no [email protected] -p 1234