tl; dr : No, esto no funcionará. El hecho de que el servidor conozca su clave pública no autentica al servidor, incluso si intenta mantener la clave pública en secreto.
Esto parece ser prevenible si git usa las claves de implementación del repositorio o las claves ssh del usuario para cifrar la conexión
Varios problemas aquí:
-
git
no tiene un concepto como "clave de implementación de repositorio", esto es parte de GitLab. Parece ser simplemente una clave pública configurada para permitir el acceso de solo lectura al repositorio, diseñada para su uso en la implementación de código (es posible que ya lo entiendas, pero tu pregunta no está del todo clara para mí).
- El uso de su clave
ssh
para conectarse con algo que lo autentica usted al demostrar que tiene la clave privada. No autentica el servidor. Es por esto que las claves de host son necesarias.
-
Las claves
ssh
no se usan para cifrar la conexión, solo para autenticar una conexión segura ya establecida (establecer la conexión segura es una parte separada del protocolo ssh)
Las claves públicas se llaman públicas por una razón, nunca debe asumir que son privadas, incluso si las generó para agregarlas a GitLab a través de HTTPS y no utilízalo en cualquier otro lugar.
La autenticación
ssh
implica enviar la clave pública al servidor para ver si está permitida (llamada "blob de clave pública" en RFC 4252 sección 7 ). Esto se hace después de establecer una conexión segura para que no pueda ser interceptada, pero eso no importa si la sesión se estableció con un servidor malicioso. Un impostor podría simplemente responder con "¿Por qué sí, aceptaré esa clave para autenticar a ese usuario!" y engañarlo pensando que es el servidor legítimo. La forma correcta de only para autenticar un servidor con ssh
es usando su clave de host.