¿Cómo puedo evitar que las claves cargadas en ssh-agent se envíen a un servidor particular (inseguro)?

Question

¿Cómo puedo evitar que las claves cargadas en ssh-agent se envíen a un servidor particular (inseguro)?

#1 de cpast (8 votos)

1

Un servidor en particular con el que necesito interactuar tiene un sshd antiguo o dañado, y solo admite algoritmos SHA1 para el intercambio de claves. De la información en los documentos de Snowden, desconfío de que las claves intercambiadas con servidores con algoritmos de intercambio de claves débiles puedan ser interceptadas.

Mantengo una identidad separada que uso solo con este servidor, y tengo una entrada específica ~/.ssh/config para usar esa identidad al conectar; y mi ssh_config a nivel de máquina no permite los algoritmos de intercambio de claves inseguros.

Sin embargo, si agregué mi clave regular a ssh-agent , parece que mi clave con la esperanza de que sea más segura aún se enviará a través del intercambio de claves potencialmente inseguras.

¿Hay alguna forma de asegurar aún más mi configuración, de modo que pueda evitar que una clave que deseo mantener segura y privada se transmita con un algoritmo de intercambio de claves con fugas?

Si no, debería haber ? Parece que parte del contrato del agente es que "todos estos algoritmos de intercambio de claves son absolutamente seguros al 100%, por lo que está bien enviar cualquier clave". Dado que los algoritmos de intercambio de claves no son seguros, esto es (¿es?) Un problema.

Si bien los algoritmos de intercambio de claves se pueden bloquear en el nivel de la máquina, esto no siempre funciona en la práctica, y es bastante fácil anularlo accidentalmente / intencionalmente en la configuración por usuario. ¿Existe (o, de nuevo, debería haber) una manera de configurar "la identidad XYZ puede solo ser utilizada con KexAlgorithms / Ciphers / MACs?"

Detalles de Gory:

Tengo una identidad rsa id_insecure que quiero usar con el servidor inseguro, y una identidad ed25519 id_secure que uso por defecto.

Para evitar algunos algoritmos de intercambio de claves potencialmente débiles, mi /etc/ssh_config contiene:

Host *
    KexAlgorithms [email protected],diffie-hellman-group-exchange-sha256

Para permitir el acceso al servidor inseguro, ya que no pueden ponerse de acuerdo sobre un algoritmo de intercambio de claves con la configuración anterior, mi ~/.ssh/config contiene:

Host insecure_server
    IdentityFile path_to/id_insecure
    KexAlgorithms diffie-helmann-group14-sha1,and-some-other-icky-sha1-algorithms

Sin embargo, si carga id_secure en mi agente SSH y ssh -vvv insecure_server , la salida contendrá

debug1: Offering ED25519 public key: path_to/id_secure
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: ...

Comprendo que acabo de enviar mi identidad id_secure utilizando el algoritmo de intercambio de claves diffie-helmann-group14-sha1, que no es tan seguro como se pensaba. Si me equivoco sobre lo que se está transmitiendo ... también me parece que es información valiosa.

ssh

pregunta danwyand 09.01.2015 - 20:35

fuente

1 respuesta

Lea otras preguntas en las etiquetas ssh

Comprender la seguridad de mi red doméstica SSLv3 no se puede desactivar, ¿puedo usar un cifrado débil como solución alternativa?

score 8 · Accepted Answer

Tienes varios conceptos erróneos aquí.

Primero, el punto central de un par de claves público / privado es que no envía la clave privada al servidor. Lo único para lo que se usa tu clave es para firmar mensajes; El servidor no obtiene su clave privada en ningún momento durante el protocolo SSH. Incluso si usa el reenvío de agente (que le permite iniciar sesión en otros servidores desde el primero usando su clave), el servidor no obtiene su clave privada: solo pasa las cosas a ssh-agent en su computadora, que los firma y envía la firma al primer servidor para que la envíe por la línea.

En segundo lugar, "intercambio de claves" en este contexto no significa "transferir claves", significa "establecer un secreto compartido". La forma en que funciona Diffie-Hellman es que el cliente y el servidor elaboran una clave nueva , que no tiene ninguna relación con las claves que pudieron haber tenido antes. Las claves a largo plazo (es decir, los pares de llaves que se almacenan en archivos) solo se usan para firmar elementos del intercambio de claves, para que sepa que está hablando con el servidor con el que cree que está hablando.

Tercero, el intercambio de claves en SSH no tiene nada que ver con las claves cliente ( id_rsa y similares). El servidor se autentica a sí mismo durante el intercambio de claves utilizando la clave del host, pero la autenticación del cliente no se produce durante el intercambio de claves. Toda la clave de un cliente se usa para firmar una cadena en particular después de el intercambio de claves (y después de haber enviado el nombre de usuario al que desea iniciar sesión), para demostrar que puede firmar cosas con una clave privada correspondiente a una clave pública autorizada para ese usuario. Los algoritmos de intercambio de claves no tienen nada que ver con las claves del cliente.

Por lo tanto, el intercambio de claves débiles no plantea ningún problema para la seguridad de la clave privada. Esa seguridad no se basa en un fuerte intercambio de claves. El único ataque que podrías hacer es explotar el reenvío del agente, pero eso solo podría funcionar si a) lo habilitaste en primer lugar yb) sigues conectado (desconectando = no más reenvío de agente).

Cuarto, en realidad no tengo conocimiento de un problema con el uso de SHA-1 para el hash de intercambio. SHA-1 es débil para ataques de colisión , lo que significa que es más fácil de lo que debería ser crear dos cosas que tengan el mismo valor. Pero para MITM exitosamente la conexión, necesitarías un segundo ataque de preimagen , lo que significa crear una colisión con algo que no controlas. En un ataque de colisión, controlas ambas mitades de la colisión, lo cual es un problema si estás firmando algo y el atacante puede controlar lo que estás firmando, en cuyo caso el atacante podría crear un par en conflicto, conseguir que firmes una cosa. , y usar eso como una firma de la otra cosa. Si bien en general es mejor alejarse de él, considerarlo inseguro para los casos que solo necesitan resistencia en la segunda imagen es un poco exagerado.