Claves públicas están diseñadas para compartir, leer el acceso o publicar una clave pública está bien

Claves privadas son secretas, solo deben ser accesibles para el propietario de dicha clave privada.

Para llevar este punto a casa, piense en cada sitio web de HTTPS que haya visitado. En cada caso, como parte de HTTPS, el sitio le proporciona su clave pública. Por lo tanto, no solo es seguro publicarlo, se pretende que sea así. Por ejemplo, si hace clic en el icono de candado verde en la barra de direcciones, puede encontrar la clave pública de este sitio web (si lo está viendo en HTTPS)

*.stackexchange.com

Modulus (2048 bits):
af 46 03 ce c7 13 e6 2e 93 d8 56 91 b1 31 8d 0a 
22 c1 f0 eb 4f 5e ef 0d f6 20 32 b9 a4 4e 87 f9 
d2 d2 44 51 b0 df 30 50 c9 35 4e 68 19 84 fb 98 
33 aa 05 4b 7e fb 57 c5 b6 2e a8 4b 04 ca cf 5e 
2e e5 9e 1b ca b7 60 c5 58 2c b0 df c4 6b 0d b1 
2c 33 97 73 54 61 2b 9a 1b b1 dc 5d 10 a9 c4 c8 
f7 6c e3 55 6e b5 0e 61 3b 35 24 0b 89 1e 32 a2 
75 69 4e 97 40 68 ee 23 48 f2 71 9f c7 7e e2 9d 
6c 22 55 36 24 64 a4 f0 b6 52 58 5a 9a 44 e7 3b 
2a d5 ed 95 63 f8 1d a8 4d 45 9b 5d c2 f2 f9 74 
81 06 18 d5 b1 fb b0 7e 5d 50 1f 63 5c a0 73 f5 
22 b2 57 64 03 e6 b7 0f 6f b7 58 0b 57 80 56 51 
65 9f f5 09 61 63 29 62 4d 30 02 3a 64 10 2d 95 
b8 12 36 04 58 c5 d7 1d 95 e2 21 3c b0 b3 93 35 
b2 b1 f9 6d 7e 20 66 b2 68 33 e9 50 a8 15 1e 0a 
80 9a 3c 19 dd cc 79 35 a8 8c 1b 61 33 5d 12 2f 

Exponent (24 bits):
65537

Se pueden encontrar más ejemplos de esto en github.com donde solicitan que adjunte una clave pública a su cuenta para usar con git clone [email protected]:<user>/<repo>

Puede verificar las claves públicas de cualquier usuario en github con la siguiente URL

https://api.github.com/users/<user>/keys

el mío aparece como:

[
  {
    "id": 18667533,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDraswAp7EbMwyYTzOwnSrsmr3nNMDaDf4e2YVaehLc9w6KN2ommomXZO8/V9N3yINNveGqrcVc9m2NTm04iILJUKd9o25ns8QIG6XSCt9SVx/Xw1J/SXfIWUKuEe0SgmIwVwkk8jetfG/Z7giSiU3dxxC4V9lHQCFgKOKBWGpNbINmqtmBWncX3HJKeXrpSddoePbZZ84IEFr4CWUlqoXyphpxqzpfA9sRpVTtyBPcUSj68j4+gKgEQN65G6LXys3q8BiwWxucci6s34vp4L8jKn7uYh26vLuT1oIbODJphCmpvMH+ABPkNQcFBk4rRLpCEAsoAhmvTk/NjnfZM+nd"
  },
  {
    "id": 21175800,
    "key": "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC5tPV481acCZ5wm2E15gXkVRaKCE3lic/O8licyzW+eDE9rPpG4rHRRH9K2ENmstUh5nLEenb0nNhEGnsf3pIJRZ07JXwv16+lsJBSS8+YiWeMBlwo+JNaxwSyUlYUgl1ruogr0nR0KBqsYSWXuG0s2jm2IOV+0B/0fzDR/tiLFLj50+iJ9qCDSk/8fAsXz2xG39KcUcxmCbDXb/qSdESWaZc+pafNRiCcVNfMkKeDViWlzI4VkiTcfVCraHUuYx4jgOBB526dRWSDG9bLchwlJiopgT+k4X/TNe2l01DPwYetwLvY6V8rcPrjjJL8ifRTMSof1zRIoBgJZhRzWc1D"
  }
]

Lo contrario es exactamente lo que ocurre con Claves privadas , que deberían estar protegidas en todo momento y nunca entregadas a terceros ni intercambiadas por correo electrónico sin encriptarlas.

Si alguien ha accedido a su clave privada, tiene la capacidad de acceder a cualquier dispositivo o archivo cifrado que esté protegido con su clave pública. También significa que pueden firmar cosas en su nombre. Es MUY malo si alguien ha obtenido acceso a su clave privada.

En muchos casos, los Clientes SSH no funcionarán si se detecta que los permisos del archivo de clave privada son tales que otros usuarios además de usted tienen acceso de lectura.

  

¿Es completamente seguro publicar una clave pública ssh?

No, pero puede hacerlo de todos modos sin preocupaciones (mucha gente lo hace, solo mire enlace o enlace )

La razón por la que no es completamente segura es que si conozco su clave pública, puedo, con una buena parte de las matemáticas, calcular su clave privada. Su clave pública contiene un gran número n, que básicamente es el producto de dos números primos, y si encuentro estos dos números primos, puedo encontrar fácilmente su clave privada.

La razón por la que no tiene que preocuparse: es fácil encontrar los factores de n cuando n = 21, pero es mucho más difícil cuando n es una Número de 4096 bits de longitud. Ningún matemático actualmente vivo o muerto ha publicado una manera de tener en cuenta un número tan grande en el tiempo aceptable. Usando el método más conocido, todos estaríamos muertos mucho antes de que todos encontraran los factores que conformaban su n .

No es del todo imposible que alguien encuentre un atajo para factorizar números grandes. Si eso sucede, RSA no tendrá ningún valor. Hasta entonces, no tienes que preocuparte.

SSH usa tanto RSA (u otro esquema de firma) como Diffie Hellman (para intercambio de claves de sesión). 1024 bits para el intercambio de claves Diffie Hellmann (que matemáticamente funciona de forma un poco diferente a RSA) puede que ya no sea lo suficientemente grande. Esto se debe a que algunas implementaciones de ssh (y las implementaciones de ssl, si recuerdo correctamente) que usan Diffie Hellman reutilizan algunas constantes en lugar de elegirlas al azar y una vez que alguien construyó una máquina para hacer los cálculos necesarios, podrían romper todo el cifrado basado en estas constantes. Los 1024 bits aún requieren una increíble potencia informática para factorizar o calcular logaritmos discretos (y miles de millones de dólares para construir máquinas para hacerlo rápido), pero puede valer la pena para ciertos actores a nivel estatal, porque solo se rompen algunos problemas. las instancias romperán un número tan grande de sesiones encriptadas. Sin embargo, 2048 y 4096 bits aún se consideran seguros.

Lo mismo ocurre con las claves RSA; No creo que un número de 1024 bits haya sido factorizado todavía en público, pero probablemente esté en el horizonte, lo que significa que es probable que las instituciones con presupuestos muy grandes tengan en cuenta los números de 1024 bits ahora , aunque No en grandes cantidades.

(Ediciones: aclaró el significado del último párrafo y corrigió el error señalado por RobIII)

Nada es "completamente seguro"; La pregunta es si agrega algún riesgo adicional .

El protocolo SSH envía la clave pública del cliente encriptada , solo después de haber negociado una clave de encriptación de sesión simétrica con el servidor. Por lo tanto, un adversario que escucha a escondidas la conexión no aprende la clave pública del cliente. Esto significa que publicarlo le da al adversario una información adicional que de otra manera no tendrían.

¿Pero qué puede hacer el adversario con esa información adicional? Bueno, todo depende de si el atacante puede romper RSA. Consideremos dos subcasos. (Supondré que tanto el servidor como las claves RSA del cliente son lo suficientemente grandes para estar seguras en primer lugar, 2048 bits o más).

El adversario tiene un ataque general en RSA que requiere el conocimiento de la clave pública

Por ataque general, me refiero a uno que rompe RSA independientemente de la clave que uses. Por ejemplo, esto sería algo así como un algoritmo eficiente para resolver el problema RSA (por ejemplo, un algoritmo de factorización primaria de tiempo polinómico ) o construyendo una computadora cuántica .

En este caso, no importa si publica la clave pública de su cliente o no, porque SSH y cualquier otra aplicación que use RSA se rompería por completo. Así que no hay riesgo adicional.

El atacante tiene un ataque contra un subconjunto de claves públicas RSA "débiles"

Este es un problema de la vida real. Hay algunos sistemas que, debido a algoritmos de generación de claves defectuosos o generadores de números aleatorios defectuosos, eligen claves RSA que son realmente vulnerables al ataque. El ejemplo más notable es que la distribución Debian GNU / Linux se distribuyó con un generador de números aleatorios débil durante casi dos años (de septiembre de 2006 al 13 de mayo de 2008) . Una encuesta en 2011 de 7.1 millones de RSA las claves en la Internet pública encontraron que alrededor del 0.4% de las 1024 claves públicas RSA que vieron eran débiles.

Si la clave pública de su cliente es una clave tan débil y usted la publica, entonces un atacante que la obtenga puede saberlo y explotar este hecho. Luego podrían iniciar sesión en los servidores SSH en los que utiliza esa clave para autenticarse. Eso sería un riesgo adicional.

Si su servidor tiene una clave pública tan débil, entonces ese servidor es inseguro; un atacante puede espiar las conexiones, lo que les permite aprender su clave pública de todos modos. Así que en este caso no hay riesgo adicional.

Conclusión

El riesgo adicional de publicar su clave pública de cliente SSH es pequeño pero no es cero. El mayor riesgo es que la clave pública de su cliente sea débil, algo causado por un software defectuoso. Si va a publicar una clave pública de cliente, es posible que desee tomar medidas para asegurarse de que su clave no sea débil. Por ejemplo:

• Compare su clave pública con una herramienta de prueba de clave débil
• Genere su par de llaves de cliente en un sistema donde haya realizado la diligencia debida para asegurarse de que no le dará claves débiles. Por ejemplo:
  • Aplique todos los parches de seguridad a su sistema operativo, especialmente aquellos que abordan problemas con su generador de números aleatorios, SSH o cualquier biblioteca de la que dependa SSH.
  • Tome medidas para asegurarse de que el sistema tenga acceso a una buena fuente de entropía. (Tema complicado.)

No, a menos que use uno único por servicio. Permite a los atacantes identificarte.

Si usa la misma clave pública para el servicio A y el servicio B, y su clave pública se filtra para ambos, esto entrecruzará sus dos cuentas.

Esperemos que ninguno de los dos servicios sea embarazoso. Pero incluso en ese caso, esto le dará al atacante una mejor pista para averiguar qué cuentas (s) hackear algún día, si él quiere atacarte.

Existe un ligero riesgo de revelar su identidad si su clave pública contiene su nombre de host como un comentario al final, por ejemplo. %código%. Si su nombre es poco común, es posible que lo identifique.

Ver esta pregunta & conteste para obtener más detalles: ¿Debo publicar mi clave SSH pública con el usuario @ nombre de host al final?

Sí, pero ...

Si su seguridad se basa en la privacidad de la clave pública, está haciendo algo subóptimo. Esto no es para lo que está diseñado el cifrado asimétrico.

Todas las respuestas anteriores señalan algunas vulnerabilidades

• que tienen un mayor riesgo si se conoce su clave pública,
• o muestran alguna defensa adicional que tienes, se mantiene en secreto.

En ambos casos, la verdadera razón es que no usa la clave pública para la cual fue diseñada. Por ejemplo, el conocimiento de su clave pública hace posible su identificación. Esto puede manejarse mediante una clave pública oculta, pero se puede hacer mejor si usa algún mecanismo adicional (por ejemplo, una capa de cifrado adicional con pares de claves aleatorios generados automáticamente por sesión) para esta tarea.

Pero, todo puede usarse también para otras tareas, incluso puede ser fructífero, especialmente si no estamos en el lado defensivo.

  

Ahora mismo no tengo mi directorio .ssh bajo el control de versiones. Pero   guardaría un paso si pudiera mantener .ssh / authorized_keys en el archivo de puntos   repositorio.

Aunque debería ser seguro hacer pública la clave pública, no creo que sea una buena idea:

La clave privada también se almacena en el directorio .ssh y existe el riesgo de que no tenga cuidado de excluirla del repositorio de archivos de puntos y publicarla accidentalmente.

Una preocupación adicional respecto a compartir su clave pública es si se generó de forma insegura. Se han publicado numerosos documentos sobre las formas en que las claves RSA y Diffie Hellman pueden ser ocultas, pero por lo demás parecen perfectamente normales. En este caso, proporcionar su clave pública le daría a un atacante toda la información necesaria para obtener su clave privada.

Referencias:

enlace enlace

Hay varias amenazas que puedes considerar. Uno discutido por otros respondedores es el de un usuario malintencionado que intenta descifrar la clave pública. Otra amenaza que vale la pena considerar es que este usuario malintencionado reemplaza sus claves públicas con las suyas. Si cambia las claves y no se da cuenta de esto, entonces puede configurar un sistema utilizando las claves del usuario malintencionado, de modo que se despliega su clave pública para la que posee el par privado.

Sí

Si RSA funciona según lo diseñado, esto no debería ser un problema de seguridad. Puede revelar un poco de información sobre su identidad, pero nada que esta pregunta no muestre también.

¿Por qué ?

Para AES, solo necesita 256 bits porque la clave es completamente secreta. Con RSA, le estás dando a un adversario algo de información (la clave pública), pero se puede demostrar que todavía es tan difícil de descifrar. Pero el factoring es cada vez más rápido que las contraseñas de fuerza bruta.

De manera simplista, dos números primos elegidos al azar son la clave privada y se multiplican juntos de la clave pública. (Esto es factible porque los números primos son bastante comunes). RSA se basa en la suposición de que factorizarlos de nuevo a los dos números primos es difícil. Ha habido un gran progreso en los algoritmos de factorización numérica, y si aparecen computadores cuánticos completos, el algoritmo de Shor será el final de RSA

En términos de la teoría de los sistemas PKI, no. El sistema está diseñado para ser "seguro" o, más exactamente, no es más débil , cuando el algoritmo y la clave pública son conocidos por el mundo.

En la práctica, posiblemente podría haber alguna exposición a usted por otras razones. En resumen, no comprometa su propia seguridad a través de errores; y es mejor crear pares de llaves diferentes para cada propósito individual.

• Si olvida y confirma accidentalmente la clave privada, o un certificado de revocación, y alguien lo ve, podrían ser utilizados en su contra. Al cometer cualquier cosa dentro de su carpeta .ssh , usted acepta el riesgo de un posible error humano; debes tener cuidado (Y si esto sucede, simplemente eliminarlo nuevamente puede que no lo elimine de la historia. No en los sistemas más populares de la actualidad. Dependiendo del sistema de control de versiones, es posible que tenga dificultades para purgarlo por completo).
• Dependiendo de qué tan público sea su repositorio, y para qué más usa esa clave pública, es posible que las partes hostiles puedan rastrear la actividad realizada con esa clave pública y, por lo tanto, construir un historial de sus acciones. Concebidamente, identificándote en el proceso. Tiro largo.