Gerenciar chaves SSH

Question

Temos cerca de 2500 servidores Linux. Temos um servidor Jumpstart, a partir do qual podemos SSH para qualquer servidor para tarefas relacionadas ao administrador do sistema. Nós implantamos um único arquivo de identidade e usamos a mesma chave pública em todos os servidores. Mas esta é uma enorme ameaça à segurança.

Queremos implantar uma chave diferente para cada servidor. Mas isso criaria um grande número de chaves e dificultaria o gerenciamento. Por favor, sugira uma maneira de fazer isso facilmente.

    

Answer 1

Para 2.500 hosts, você pode já ter um sistema de gerenciamento de configuração, mas você pode usar o SaltStack se não tiver. Nós temos isso para autenticação de raiz:

user1auth:
  ssh_auth:
    - present
    - user: root
    - source: salt://resources/ssh_keys/user1

user2auth:
  ssh_auth:
    - present
    - user: root
    - source: salt://resources/ssh_keys/user2

Você não precisa ter a chave privada no host de salto. Basta usar o encaminhamento de agentes ao efetuar login: ssh -A root@host .

Existem outros sistemas também (Pupet, cfengine, por exemplo).

    

Answer 2

O problema que vejo ao usar a mesma chave SSH em todos os lugares é a falta de responsabilidade.

Em vez disso, gostaria que cada usuário tivesse suas próprias chaves ou chaves SSH e usasse um sistema centralizado de autenticação e autorização.

Dessa forma, as chaves públicas nem precisam ser distribuídas para os sistemas de destino e podem ser armazenadas em um serviço de diretório central como FreeIPA .

Além de obter responsabilidade, você também tem a capacidade de definir políticas RBAC (Role-Based Access Control) refinadas.

    

Answer 3

O FreeIPA faz o gerenciamento de chaves SSH muito bem. Eu o uso com sucesso em casa, mas muitas empresas o usam em produção (a lista de discussão do freeipa-users é hiperativa). É o projeto de software livre upstream no qual se baseia a solução de Gerenciamento de Identidade da Red Hat. Há também desenvolvedores da Red Hat moderando e ajudando na lista de discussão do freeipa-users.

Basicamente, é um serviço semelhante ao Active Directory para ambientes Unix / Linux. Também pode sincronizar com o AD. Ele possui recursos nix * nix como montagens automáticas do NFS, políticas centralizadas do sudo, etc.

Cada usuário pode adicionar sua chave SSH ao seu perfil FreeIPA. Em seguida, o sshd pode ser configurado para usar um AuthorizedKeysCommand fornecido pelo pacote sssd que seria configurado para consultar o servidor FreeIPA. Combinado com as políticas do sudo, você obtém escalonamento de privilégios e auditoria (quem sudo'ed).

Sendo um projeto RedHat, é um one-liner para instalar no Fedora ou no CentOS, mas eu instalei e configurei com sucesso as caixas do Debian como clientes FreeIPA. Eu instalei o servidor de autenticação em um servidor Fedora, que é sua plataforma suportada nativamente.

link

    

Answer 4

Copiar a chave pública para todos os servidores nos quais você está efetuando login geralmente é o modo como as coisas são feitas com o SSH. Se o que você fez é criar um keypar privado / público no servidor do Jumpstart e copiou a chave pública para o arquivo ~/.ssh/authorized_keys no host que você deseja ssh, então isso é (parcialmente) o forma aceita de proteger um login remoto via ssh. Outras coisas a considerar para proteger ainda mais o ssh são:

• altere /etc/ssh/sshd_config e defina PasswordAuthentication No e PubkeyAuthentication yes
• altere LogLevel em /etc/ssh/sshd_config para VERBOSE e monitore /var/log/auth.log para anomalias.
• edite /etc/security/access.conf para permitir somente logins por usuário de determinado IP
• edite /etc/pam.d/login e defina account required pam_access.so para ativar as alterações feitas em access.conf

A implantação de uma "chave diferente para cada servidor" parece significar que você deseja uma chave pública diferente no ~/.ssh/authorized_keys em cada servidor. A razão para isso não é clara para mim, mas se você precisar, eu criaria um arquivo de texto no servidor Jumpstart com um host em cada linha. Use um for loop para analisar o arquivo e execute ssh-keygen -f $line_from_file para criar um par de chaves para cada host. Você também pode usar o mesmo for loop para ssh em cada host e adicionar o pubkey a ~/.ssh/authorized_keys usando sed -i ou algo assim.

    

Answer 5

Um único arquivo de identidade em cada servidor viola a maioria das estruturas de segurança, incluindo PCI, HIPAA, etc. Cada usuário humano precisa de sua própria conta, e essas contas precisam poder ser removidas.

Existem muitas soluções comerciais e de código aberto que podem lidar com isso para você. Por exemplo, Userify (onde eu trabalho), Universal Key Manager, Caixa de Chaves SSH, etc.

Sua escolha deve depender de quais são suas necessidades e orçamento, além dos recursos que você considera importantes. Por exemplo, muitos sistemas centralizados são tão centralizados a ponto de você não conseguir entrar em nenhum de seus servidores, se, digamos, o servidor LDAP estiver inativo. É importante poder gerenciar suas permissões de SSH centralmente, enquanto descentraliza a operação real para maior confiabilidade e controle.

Veja também esta discussão do Slant:

link

    

Answer 6

Experimente o KeyBox - link

Fácil de instalar, os usuários gerenciam suas próprias chaves SSH com base nos perfis que foram atribuídos a eles.

link

(Divulgação: Este é um produto que eu desenvolvi. É open source e livre para usar sob a AGPL ou você pode comprar uma licença comercial)

    

Answer 7

Se você não tiver restrições orçamentárias, procure soluções proprietárias como o Dell TPAM ou Cyberark (não gosto de nenhuma delas)

Otherwhise, você pode usar uma chave SSH para cada usuário com um agente ssh ou gpg-agent