SSH: ¿Utiliza un par de claves privadas / públicas para cada máquina remota? ¿O un solo par para todos?


23

Cuando desea tener inicios de sesión ssh basados ​​en claves públicas para varias máquinas, ¿utiliza una clave privada y coloca la misma clave pública en todas las máquinas? ¿O tiene un par de claves privadas / públicas para cada conexión?


@Jim Zajkowski: No estoy seguro de cómo responder a tu comentario, pero esto es para ti. Los cuadros de salto permiten el acceso controlado a los servidores de Internet que se encuentran en una DMZ (detrás de un firewall). Digamos que tiene "server_a" y "server_b". A está en la red y B está fuera de la red. Los clientes externos se conectan a B. El tráfico que va de A a B necesita ser controlado y viceversa. Entonces agrega una caja de salto que tiene dos tarjetas de red. Uno que lo conecta a la red interna (A) y otro que lo conecta a la red externa (B). Entonces, desde A, vas a la caja de salto y luego a B. Uno de los beneficios de

@IMTheNachoMan: convertí tu respuesta en un comentario, aunque el mejor lugar para hacerlo sería como un comentario directamente dentro de la respuesta que contiene el comentario al que estás respondiendo (eso me mareó un poco). Si tiene alguna pregunta, vaya a meta y pregunte. Gracias por la aclaración de todos modos.
Kara Marfia

Respuestas:


27

Utilizo una clave por conjunto de sistemas que comparten un límite administrativo común. Esto limita la cantidad de máquinas que se abren si una clave se ve comprometida, mientras que no abruma por completo mi capacidad para almacenar y administrar varios miles de claves. Las diferentes frases de contraseña en cada clave significan que incluso si se roban todas sus claves privadas y se compromete una clave, el resto no se va al inodoro con ella. Además, si hace algo estúpido (como copiar una clave privada en una máquina no confiable), nuevamente no tiene que volver a escribir todo, solo las máquinas asociadas con esa clave.


4

La clave pública no importa mucho, ya que, por definición, puede publicarse. Entonces, el único problema es la privacidad de sus claves privadas. Están en su propia máquina, y todos juntos, por lo que si uno está comprometido, es probable que todos lo estén. Por lo tanto, múltiples pares de llaves es solo más trabajo para el mismo efecto.

La única vez que usaría diferentes claves es para diferentes cuentas o diferentes roles, que por definición no deberían tener una superposición completa en el acceso.


2

Si entiendo correctamente, cada servidor tendrá su propia clave pública.

Para un usuario determinado , puede generar una clave y usarla en todas partes, siempre que la clave privada se replique en todos los hosts iniciadores. (Esto sucedería automáticamente a través de directorios de inicio montados en red y un sistema de autenticación basado en directorios como OpenLDAP, ya que el usuario siempre será "el mismo", independientemente de la estación de trabajo desde la que inicien sesión).

Fuera de un sistema de usuario basado en directorios, creo que es una Mala Idea ™ usar las mismas claves en todas partes: terminas con una reducción neta en la seguridad del sistema, ya que cualquiera que pueda obtener una clave de cualquiera de las estaciones de trabajo puede autenticarse como ese usuario al servidor remoto.

Otra alternativa, vaciada por varias grandes corporaciones (y estoy seguro de que las pequeñas también) es nunca permitir que un "usuario" use claves previamente compartidas, sino que luego inicie sesión en un cuadro de "salto" o "hub" , sual usuario de conexión apropiado, y luego SSH desde allí a los servidores que necesitan administrar.

Además, si utiliza un sistema de administración como la plataforma de automatización de servidores de HP, la administración remota de servidores administrados se convierte en un proceso más simplificado.


1
Todos deberían mantener sus claves encriptadas. ¿Puede explicar los beneficios de seguridad de la "caja de salto", porque no lo veo.
Jim Zajkowski el

como se implementó en varios bancos a los que he estado expuesto, y en otros lugares, la idea detrás de una "caja de salto" es que no puede acceder a los servidores en una DMZ o subred, etc. con su usuario "normal". Usted se conecta a la caja de salto, luego, en forma registrada, su al usuario de administración para conectarse a la otra red.
warren

2
Beneficio de seguridad == 0, en otras palabras.
womble

@womble, tal vez eso sea correcto. Pero es lo que hacen muchas compañías paranoicas. Sin suembargo, dado que la sesión está registrada, es auditable.
warren

1
¿Por qué solo las susesiones son auditables y no las otras?
João Portela

1

Como han dicho otros, aunque la idea de múltiples pares de claves puede parecer más segura, si existe la posibilidad de que se usen de tal manera que todos estén en el mismo lugar, entonces es más complicado y no más seguro. Múltiples frases de contraseña lo harían más seguro, pero también un gran dolor de cabeza al tratar de recordar qué frase de contraseña va con qué clave y qué clave va con qué servidor.

La respuesta más razonable para mí sería aquella en la que se sugirió hacerlo SOLO si involucra roles administrativos separados sin mucha superposición. De modo que podrían ser diferentes personas manejando los diferentes roles, o en diferentes estaciones de trabajo o lo que sea. En ese caso, tiene más cosas únicas con las que lidiar para cada rol diferente de todos modos, por lo que es más justificable.


0

Para facilitar la administración de múltiples servidores con capacidad SSH, puede consultar cssh . Puede combinar cssh con claves SSH con contraseña para mejorar en gran medida su capacidad de administrar múltiples servidores simultáneamente.


2
¿Cómo se las arreglan para obtener "errores locos" en un bucle glorificado?
womble

Algo sobre eso parece muy mortal: si comete un error, arruina todos sus servidores a la vez en lugar de solo uno.
Nick el

@Nick - cierto, pero ese es casi siempre el caso cuando estoy a cargo de la caja =) @womble - ¿eh? ¿A qué "bichos locos" se refiere?
Greeblesnort el

1
En la parte superior de la página del proyecto al que se vinculó: "NOTA: volveré a este proyecto muy pronto para poder solucionar los errores locos". El hecho de que el aviso aún esté allí dos años después no aumenta más mi fe en él.
womble
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.