ssh - tutorial - Obteniendo GitLab CI para clonar repositorios privados

gitlab tutorial windows

Question

Tengo GitLab y GitLab CI configurados para alojar y probar algunos de mis repositorios privados. Para los módulos de mi compositor bajo este sistema, he configurado Satis para resolver mis paquetes privados.

Obviamente, estos paquetes privados requieren una clave ssh para clonarlos, y tengo esto funcionando en el terminal: puedo ejecutar la instalación del compositor y obtener estos paquetes, siempre y cuando tenga la clave agregada con ssh-add en el shell.

Sin embargo, al ejecutar mis pruebas en GitLab CI, si un proyecto tiene alguna de estas dependencias, las pruebas no se completarán, ya que mi instancia de GitLab necesita autenticación para obtener los deps (obviamente), y la prueba falla y dice que la Host key verification failed .

Mi pregunta es ¿cómo puedo configurar esto para que cuando el corredor ejecute la prueba pueda autenticarse en gitlab sin una contraseña? He intentado poner una clave ssh-password sin contraseña en la carpeta ~/.ssh mis corredores, sin embargo, la compilación ni siquiera agrega la clave, "eval ssh-agent -s " seguida de ssh-add parece fallar y dice que el agente no está t corriendo

Answer 1

Aquí un howto completo:

Diseño general

• generando un par de claves SSH
• Agregando el privado como una variable de entorno segura de su proyecto.
• haciendo que el privado esté disponible para tus scripts de prueba en GitLab-CI
• agregando una pública como clave de implementación en cada una de sus dependencias privadas

Generando un par de claves SSH públicas y privadas.

Genere un par de claves SSH públicas y privadas sin frase de contraseña:

ssh-keygen -b 4096 -C "<name of your project>" -N "" -f /tmp/name_of_your_project.key

Agregando la clave SSH privada a su proyecto

Debe agregar la clave como una variable de entorno segura a su proyecto de la siguiente manera:

• navegue https://<gitlab_host>/<group>/<project_name>/variables
• haga clic en "Agregar una variable"
• rellene la Key campo de texto con SSH_PRIVATE_KEY
• rellene el campo de texto Value con la propia clave SSH privada
• haga clic en "Guardar cambios"

Exponiendo la clave SSH privada a tus scripts de prueba

Para que su clave privada esté disponible para sus scripts de prueba, debe agregar lo siguiente a su archivo .gitlab-ci.yml :

before_script:
  # install ssh-agent
  - ''which ssh-agent || ( apt-get update -y && apt-get install openssh-client -y )''
  # run ssh-agent
  - eval $(ssh-agent -s)
  # add ssh key stored in SSH_PRIVATE_KEY variable to the agent store
  - ssh-add <(echo "$SSH_PRIVATE_KEY")
  # disable host key checking (NOTE: makes you susceptible to man-in-the-middle attacks)
  # WARNING: use only in docker container, if you use it with shell you will overwrite your user''s ssh config
  - mkdir -p ~/.ssh
  - echo -e "Host */n/tStrictHostKeyChecking no/n/n" > ~/.ssh/config

El fragmento de código viene de la documentación de GitLab

Agregar la clave SSH pública como clave de implementación a todas sus dependencias privadas

Debe registrar la clave SSH pública como clave de implementación en todas sus dependencias privadas de la siguiente manera:

• navegue https://<gitlab_host>/<group>/<dependency_name>/deploy_keys
• haga clic en "Nueva clave de despliegue"
• Rellene el campo de texto Title con el nombre de su proyecto
• rellene la Key campo de texto con la propia clave SSH pública
• haga clic en "Crear clave de despliegue"

Answer 2

Estoy publicando esto como una respuesta ya que otros no fueron completamente claros o detallados.

A partir de GitLab 8.12+, suponiendo que el repositorio de submódulos se encuentre en el mismo servidor que el que lo solicita, ahora puede:

1. Configura el repositorio con los submódulos de git como es habitual ( git submodule add git@somewhere:folder/mysubmodule.git )

2. Modifique su archivo .gitmodules la siguiente manera

   [submodule "mysubmodule"]
     path = mysubmodule
     url = ../../group/mysubmodule.git

   donde `../../group/mysubmodule.git ''es una ruta relativa desde su repositorio hasta la del submódulo.

3. Añade las siguientes líneas a gitlab-ci.yml

   variables:
     GIT_SUBMODULE_STRATEGY: recursive

   para dar instrucciones al corredor para obtener todos los submódulos antes de la construcción.

Advertencia: si su corredor parece ignorar la directiva GIT_SUBMODULE_STRATEGY , probablemente debería considerar actualizarla .

(fuente: https://docs.gitlab.com/ce/ci/git_submodules.html )

Answer 3

Parece que finalmente hay una solución razonable .

En resumen, a partir de GitLab 8.12 todo lo que necesita hacer es usar rutas relativas en los .submodules y la git submodule update --init simplemente funcionará

Answer 4

Se solucionó esto agregando la clave a los hosts conocidos con ssh-keyscan -H ''localgitlab.co.uk'' >> ~gitlab_ci_runner/.ssh/known_hosts

Answer 5

Si no quiere jugar con claves o submódulos ssh, puede anular el repositorio en la configuración de git para autenticar con el token de trabajo (en gitlab-ci.yml ):

before_script:
  - git config --global url."https://gitlab-ci-token:${CI_JOB_TOKEN}@gitlab.example.com/group/repo.git".insteadOf [email protected]:group/repo.git

Answer 6

Tuve un escenario en el que tuve que usar mi clave ssh en 3 scripts diferentes, así que coloqué los elementos de la clave ssh en un solo script de shell y lo llamé primero, antes de los otros 3 scripts. Esto no funcionó, creo que debido a que ssh-agent no persiste entre los scripts de shell, o algo por el estilo. En realidad, acabo de enviar la clave privada al archivo ~/.ssh/id_rsa , que seguramente se mantendrá en otros scripts.

.gitlab-ci.yml

script:
    - ci/init_ssh.sh
    - git push # or whatever you need ssh for

ci / init_ssh.sh

# only run in docker:
[[ ! -e /.dockerenv ]] && exit 0

mkdir -p ~/.ssh
echo "$GITLAB_RUNNER_SSH_KEY" > ~/.ssh/id_rsa
chmod 400 ~/.ssh/id_rsa
echo -e "Host */n/tStrictHostKeyChecking no/n/n" > /.ssh/config

¡Funciona a las mil maravillas!

Answer 7

Utilicé tokens de implementación para resolver este problema, ya que la configuración de las claves SSH para un corredor de prueba parece un poco larga.

git clone http://<username>:<deploy_token>@gitlab.example.com/tanuki/awesome_project.git

Los tokens de despliegue son por proyecto y son de solo lectura.