As chaves privadas SSH nunca devem sair da máquina em que foram geradas, a menos que sejam movidas para uma plataforma mais segura, como um HSM. Da mesma forma, eles nunca devem ser acessíveis a ninguém além da pessoa que os gerou e os usará, por exemplo. estação de trabalho de um administrador, ou melhor, um HSM / smartcard. Se você for acessar um servidor de várias máquinas, gere uma chave exclusiva em cada máquina e implemente as chaves públicas de acordo ou coloque uma chave pública de um cartão inteligente ou outro autenticador strong nas chaves autorizadas.
Para começar, eu sempre recomendo proteger chaves privadas com uma frase secreta. Isso reduzirá as chances de uso não autorizado de chaves se cair em mãos erradas. Uma medida de segurança mais alta é incorporar a chave privada em um cartão inteligente e fazer uso das funções criptográficas através de um middleware. O Redhat facilita tudo isso.
How do you protect your private ssh keys? I read about ssh-agent but I am not sure how to use it or if it can be used in this situation.
ssh-agent é usado em uma sessão de terminal para armazenar em cache a versão não criptografada da chave privada, tornando desnecessário digitar a frase secreta da chave toda vez que for usada. Você também pode usar um autenticador externo pelo qual você faz uso de um desafio / resposta de autenticação, mas nunca tem acesso ao texto não criptografado. Por favor, dê uma olhada em link para revisar como você pode usar o ssh com um autenticador seguro.
If a sysadmin leaves and he copies all the private ssh keys, then he has access to all the servers. How do you deal with this situation?
Este é um argumento muito strong a respeito de porque chaves privadas devem nunca ser compartilhadas, e certamente porque as chaves de múltiplos usuários devem nunca ser armazenadas juntas. Puro e simples, não há razão para fazê-lo. Ninguém mais tem negócios recebendo sua chave privada. Dito isso, mesmo se você estivesse em uma situação em que alguém colocasse as mãos em um punhado de chaves privadas ativas, se elas estivessem protegidas com senha por uma frase-senha strong, seria em grande parte um problema.
Novamente, ao credenciar seus usuários com um autenticador strong com funções criptográficas, você pode evitar completamente essa situação. Quando uma máquina precisa executar funções criptográficas, em vez de armazenar uma chave privada no sistema de arquivos, você pode armazená-la em um HSM para evitar a exfiltração (roubo) das chaves privadas.
Chaves privadas de chaves SSH podem ser um componente do sistema de autenticação multifator, como um cartão inteligente ou outro tipo de módulo de segurança de hardware (formato USB, placa PCIe, strongzza, HSM em rede, etc.) Agora, para as empresas conscientes da segurança, os governos e os militares operam simplesmente porque um compromisso pode levar a uma exposição massiva; as senhas são muito fracas.
Um cartão inteligente, dependendo da segurança dele, pode ser (A) não validado, um dispositivo (B) FIPS 140-2 nível 2, até um dispositivo criptográfico controlado (C), que pode ser usado como Top Secret. Informações SCI e algoritmos do Conjunto B. No caso de (B), um laboratório autorizado pelo governo validou a criptografia de forma independente, e (C), a NSA avaliou o dispositivo em questão. B é considerado equivalente à melhor segurança de nível comercial, e C é considerado grau de comunidade militar / de inteligência. Os preços sobem para o material robusto!