Una clave privada corresponde a una "identidad" única para un usuario determinado, lo que sea que eso signifique para usted. Si, para usted, una "identidad" es una sola persona o una sola persona en una sola máquina, o tal vez una sola instancia de una aplicación que se ejecuta en una sola máquina. El nivel de granularidad depende de usted.

En lo que respecta a la seguridad, usted no compromete su clave de ninguna manera, usándola para iniciar sesión en una máquina (como lo haría con una contraseña), por lo que tiene claves separadas para destinos separados no lo hace más seguro desde una perspectiva de autenticación / seguridad.

Aunque tener la misma clave autorizada para varias máquinas demuestra que el mismo titular de la clave tiene acceso a ambas máquinas desde una perspectiva forense. Normalmente, eso no es un problema, pero vale la pena señalarlo.

Además, mientras más lugares se autorice una sola clave, más valiosa será esa clave. Si esa clave se ve comprometida, se ponen en riesgo más objetivos.

Además, mientras más lugares se almacene la clave privada (por ejemplo, su computadora de trabajo, su computadora portátil y su almacenamiento de respaldo), más lugares habrá para que un atacante vaya a agarrar una copia. Así que también vale la pena considerarlo.

En cuanto a las directrices universalmente aplicables sobre cómo ejecutar su seguridad: no hay ninguna. Cuanta más seguridad adicional agregue, más comodidad le dará. El único consejo que puedo dar es categóricamente: mantenga su clave privada encriptada. La seguridad agregada allí es bastante importante.

Creo que esta pregunta puede considerarse desde dos ángulos diferentes: seguridad y conveniencia .

Cuando creamos un par de claves SSH, se nos solicita que proporcionemos una frase de contraseña para agregar una capa más para proteger la clave privada, de la siguiente manera:

$ ssh-keygen -t rsa -b 4096 -C 'With_OR_Without_Passwd'
Generating public/private rsa key pair.
Enter file in which to save the key (/Your/HomeDir/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):

Aunque hay un mensaje explícito que solicita una frase de contraseña, pero algunas (o muchas) personas aún se centran más en la información entre paréntesis: (vacío para no usar frase de contraseña) , y siguen esa sugerencia.

Combinando si usamos varios pares de claves SSH y ingresando o no una contraseña adicional , tenemos Al menos cuatro maneras de ir. Y asumamos que todos los pares de claves y el archivo config están almacenados en ~/.ssh/ .

Ahora no consideremos seguridad primero.

La siguiente tabla proporciona una clasificación simple sobre seguridad (un número más grande significa más seguro):

Security     Ways to go
   1         One   SSH key-pair  (NO passwd)
   1         Multi SSH key-pairs (NO passwd)
   2         One   SSH key-pair  (WITH passwd)
   2         Multi SSH key-pairs (WITH passwd) (SAME passwd)
   3         Multi SSH key-pairs (WITH passwd) (DIFF passwds)

Sin contraseña , si nuestro sistema es invadido por alguien, entonces el interruptor puede obtener todas nuestras claves privadas y configuración, también la autenticación de servidores remotos. Entonces, en esta situación, un par de llaves y varios pares de llaves son iguales. La forma más segura es usar diferentes contraseñas para diferentes pares de claves ssh.

Entonces no pensemos en conveniencia .

Pero más pares de claves y más contraseñas también hacen que nuestra vida sea menos conveniente, la siguiente tabla proporciona un rango simple sobre seguridad (un número más grande significa más seguro):

Convenient  Security  Ways to go
   5           1      One   SSH key-pair  (NO passwd)
   4           2      One   SSH key-pair  (WITH passwd)
   3           1      Multi SSH key-pairs (NO passwd)
   2           2      Multi SSH key-pairs (WITH passwd) (SAME passwd)
   1           3      Multi SSH key-pairs (WITH passwd) (DIFF passwds)

Entonces, en una situación general, si tenemos que intercambiar con seguridad y conveniencia al mismo tiempo, podemos multiplicar las dos puntuaciones, y tal vez Un par de claves SSH (CON contraseña) es el mejor para elegir.

Solo necesita una clave, ya que la clave pertenece a su usuario.

No hay necesidad (ni mejora en la seguridad) al tener una clave por host.

Siempre que su clave privada se mantenga privada, puede utilizar esta clave única y utilizarla para autenticarse ante múltiples hosts.

  

¿Cuál es la mejor práctica: separar ssh-key por host y usuario VS una ssh-key para todos los hosts?

No sé si entendí bien tu pregunta, ¿qué quieres decir con "clave"? ¿Te refieres a criptografía asimétrica?

al usar criptografía asimétrica tienes un par de claves pública y privada. La clave pública de cada usuario se almacena en el servidor ssh (host). Esto permite autenticar al usuario porque para cada clave pública solo debe haber una clave privada.

¿qué quieres decir con tener una clave ssh para todos los hosts?

El beneficio principal de las claves separadas es lo que sucede en el peor de los casos: alguien obtiene su clave privada.

1. MISMA clave en todos los hosts: los malos ahora tienen acceso a todo .
2. Clave DIFERENTE en cada host: los malos solo tienen acceso a una cosa.

Entonces, ¿más seguro? Claves únicas para cada host.

Esto puede llegar un poco tarde, pero creo que vale la pena mencionarlo: Desde la perspectiva de la seguridad y la comodidad, cuando se administran usuarios humanos, es conveniente tener una clave por usuario.

Las ventajas vienen cuando necesita revocar el acceso a un solo usuario.

Digamos que está usando una clave para todos los usuarios y sin contraseña (o con la misma contraseña). Puede deshabilitar al usuario en el servidor (la "cuenta"), pero todas las necesidades humanas son el usuario y la clave para obtener acceso. Él / ella ya tiene la clave, ya que es un archivo, usted no puede controlar esto, y luego solo necesita un nombre de usuario (quizás el usuario (las cuentas) esté hecho con un algoritmo estándar (por ejemplo, la primera letra del nombre + el apellido)) para obtener Acceder como otro usuario. Entonces, por razones de seguridad, tendría que crear un nuevo par de claves (y entregarlo a los usuarios) y desactivar el antiguo par de claves.

Es mucho más sencillo si tiene una clave por usuario, ya que simplemente deshabilita al usuario (y la clave si lo desea).

Cuando se administran sistemas o servidores que manejan datos confidenciales, donde el grupo de usuarios es variable (y seguramente lo será, lo que varía es la velocidad de rotación), esto se convierte en una buena práctica en términos de seguridad y conveniencia.

Como regla general, estoy de acuerdo con las otras respuestas: una sola clave por usuario suele ser la forma más práctica de hacerlo. Sin embargo, no es bueno como un enfoque único para todos.

Aquí hay algunas consideraciones adicionales.

• Si está utilizando un agente SSH, más de tres o cuatro claves se vuelven problemáticas, porque al conectarse a un servidor, su cliente SSH puede probar una de las claves almacenadas después de la otra. Esto puede llevar a varios inicios de sesión fallidos en el lado del servidor, y es posible que descubra que su cuenta está bloqueada antes de que SSH intente la clave correcta. Este aspecto favorece el enfoque de una tecla por usuario.

• Si está sirviendo a varias entidades independientes (como un consultor que atiende a múltiples clientes), considere una clave SSH separada para cada cliente. No es extraño que cuando la relación termina, el cliente puede exigir la entrega de todas las contraseñas y claves SSH. A veces, explicar por qué no es una buena idea funciona, pero si el cliente recibe algo como una orden judicial, es posible que tenga un problema.

• Si su clave privada SSH está comprometida, es posible que deba cambiarla en muchos sistemas. ¿Incluso recuerda todos los sistemas que haya configurado en los últimos diez años con esa clave SSH? ¿Recordarías eliminar tu clave SSH comprometida de Github? ¿O desde el enrutador en algún armario de la oficina, un par de personas dice que usted administra de forma remota? ¿Qué pasa con los sistemas que ya no puede tocar porque ya no trabaja para ese cliente en particular?

Al final, todo se reduce a comprender las implicaciones de los dos enfoques y a compararlos con las preocupaciones particulares de su situación.