SSH: Você usa um par de chaves pública / privada para cada máquina remota? Ou um único par para todos?


23

Quando você deseja ter logins ssh baseados em chave pública para várias máquinas, você usa uma chave privada e coloca a mesma chave pública em todas as máquinas? Ou você tem um par de chaves públicas / privadas para cada conexão?


@ Jim Zajkowski: Não sei como responder ao seu comentário, mas isso é para você. As caixas de salto permitem acesso controlado aos servidores da Internet que estão em uma DMZ (atrás de um firewall). Digamos que você tenha "server_a" e "server_b". A está na rede e B está fora da rede. Clientes externos se conectam a B. O tráfego que vai de A a B precisa ser controlado e vice-versa. Então você adiciona uma caixa de salto com duas placas de rede. Um que o conecta à rede interna (A) e outro que o conecta à rede externa (B). Então, de A, você vai para a caixa de salto e depois para B. Um dos benefícios de

@IMTheNachoMan - converti sua resposta em um comentário, embora o melhor lugar para isso seja como um comentário diretamente na resposta que contém o comentário ao qual você está respondendo (isso me deixou um pouco tonto). Se você tiver alguma dúvida, vá até a meta e pergunte. Obrigado pelo esclarecimento, independentemente.
Kara Marfia 27/02

Respostas:


27

Eu uso uma chave por conjunto de sistemas que compartilham um limite administrativo comum. Isso limita o número de máquinas que são acionadas se uma chave for comprometida, sem sobrecarregar completamente minha capacidade de armazenar e gerenciar milhares de chaves. Senhas diferentes em cada chave significa que, mesmo que todas as suas chaves privadas sejam roubadas e uma delas esteja comprometida, o restante não vai ao banheiro com ela. Além disso, se você fizer algo estúpido (como copiar uma chave privada em uma máquina não confiável), novamente não precisará digitar tudo novamente, apenas as máquinas associadas a essa chave.


4

A chave pública não importa muito, pois, por definição, pode ser divulgada. Portanto, o único problema é a privacidade de suas chaves privadas. Eles estão em sua própria máquina e todos juntos; portanto, se um estiver comprometido, é provável que todos estejam comprometidos. Portanto, vários pares de chaves são apenas mais trabalho para o mesmo efeito.

A única vez em que eu usaria chaves diferentes é para contas ou funções diferentes, que por definição não devem ter sobreposição completa no acesso.


2

Se bem entendi, cada servidor terá sua própria chave pública.

Para um determinado usuário , você pode gerar uma chave e usá-la em qualquer lugar, desde que a chave privada seja replicada para todos os hosts iniciantes. (Isso aconteceria automaticamente por meio de diretórios pessoais montados em rede e de um sistema de autenticação baseado em diretório, como o OpenLDAP, já que o usuário sempre será "o mesmo", independentemente da estação de trabalho em que fizer login.)

Fora de um sistema de usuário baseado em diretório, acho que é uma Bad Idea ™ usar as mesmas chaves em todos os lugares - você acaba com uma redução líquida na segurança do sistema, pois qualquer pessoa que possa obter uma chave de qualquer estação de trabalho poderá se autenticar como esse usuário para o servidor remoto.

Outra alternativa, sugerida por várias grandes empresas (e tenho certeza de que também são pequenas) é nunca permitir que um "usuário" use chaves pré-compartilhadas, mas faça login em uma caixa de "salto" ou "hub" , suao usuário de conexão apropriado e, em seguida, SSH a partir daí para os servidores que eles precisam gerenciar.

Além disso, se você usar um sistema de gerenciamento como a plataforma Server Automation da HP, a administração remota de servidores gerenciados se tornará um processo mais simplificado.


1
Todos devem manter suas chaves criptografadas. Você pode explicar os benefícios de segurança da "caixa de salto", porque eu não a vejo.
9117 Jim Zajkowski

conforme implementado em vários bancos aos quais fui exposto, e em outros lugares, a idéia por trás de uma "caixa de salto" é que você não pode acessar servidores em uma DMZ ou sub-rede etc com o usuário "normal". Você se conecta à caixa de salto e, em um formulário registrado, su ao usuário de gerenciamento para se conectar à outra rede.
Warren

2
Benefício de segurança == 0, em outras palavras.
Womble

@ womble - talvez isso esteja correto. Mas é o que muitas empresas paranóicas fazem. Como a susessão é registrada, no entanto, é auditável.
Warren

1
por que apenas as susessões são auditáveis ​​e não as outras?
João Portela

1

Como outros já disseram, embora a ideia de vários pares de chaves possa parecer mais segura, se houver uma chance de que eles sejam usados ​​de tal maneira que estejam todos no mesmo lugar, é apenas mais complicado e não mais seguro. Várias senhas a tornariam mais segura, mas também uma grande dor de cabeça ao tentar lembrar qual senha passava com qual chave e qual chave acompanha qual servidor.

A resposta mais razoável para mim seria aquela em que foi sugerido fazer isso SOMENTE se envolver funções administrativas separadas sem muita sobreposição. De modo que possa haver pessoas diferentes lidando com os diferentes papéis, ou em diferentes estações de trabalho ou o que for. Nesse caso, você tem coisas mais exclusivas para lidar com cada função diferente, então é mais justificável.


0

Para facilitar o gerenciamento de vários servidores compatíveis com SSH, consulte o cssh . Você pode combinar o cssh com as chaves SSH passphrased para aprimorar bastante sua capacidade de gerenciar vários servidores simultaneamente.


2
Como você consegue obter "bugs loucos" em um loop for glorificado?
Womble

Algo sobre isso parece muito mortal - Se você cometer um erro, estrague todos os seus servidores de uma só vez, em vez de apenas um!
Nick

@ Nick - verdade, mas isso é sempre o caso quando eu estou no comando da caixa =) @womble - hein? a que "insetos malucos" você se refere?
Greeblesnort #

1
Na parte superior da página do projeto, você vinculou a: "OBSERVAÇÃO: voltarei a esse projeto muito em breve para que eu possa corrigir os erros malucos nele". O fato de o aviso ainda estar lá dois anos depois não aumenta mais minha fé nele.
Womble
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.