use las keys ssh con frase de contraseña en una configuration de vagrant + chef

Tengo un vm corriendo usando vagrant, y lo aprovisiono con Chef. Uno de los pasos implica clonar un git repo, pero mi ssh-key (en mi equipo host) tiene una frase de contraseña.

Cuando ejecuto vagrant up , el process falla en el paso de clonación git con el siguiente error:
Permission denied (publickey). fatal: The remote end hung up unexpectedly
(La key se ha agregado en el equipo host, con la frase de contraseña)

Traté de resolver esto con reenvío de agente ssh haciendo lo siguiente:
Se agregó config.ssh.forward_agent = true al VagrantFile
Defaults env_keep = "SSH_AUTH_SOCK agregados Defaults env_keep = "SSH_AUTH_SOCK a /etc/sudoers en la vm

Ahora, vagrant up aún falla cuando llega a la parte de clon de git, pero si ejecuto la vagrant provision después de eso, pasa. Supongo que esto se debe a que la configuration de ssh está configurada cuando se abre la vm y no se vuelve a cargar

Intenté volver a cargar ssh después de ajustar esas dos configuraciones, pero eso no me ayudó.

Alguna idea de como resolver esto?

Gracias.

Como ha notado, actualizar sudoers durante la ejecución inicial es demasiado tarde para ser beneficioso para esa ejecución ya que el chef ya se está ejecutando bajo sudo en ese punto.

En su lugar, escribí una receta hacky que encuentra el socket ssh apropiado para usar y actualiza el entorno SSH_AUTH_SOCK para que se adapte. También desactiva la comprobación estricta de la key del host para que la connection de salida inicial se apruebe automáticamente.

Guarde esto como una receta que se ejecuta en cualquier momento antes de la primera connection ssh (probado con Ubuntu, pero debería funcionar con otras distribuciones):

 Directory "/root/.ssh" do action :create mode 0700 end File "/root/.ssh/config" do action :create content "Host *\nStrictHostKeyChecking no" mode 0600 end ruby_block "Give root access to the forwarded ssh agent" do block do # find a parent process' ssh agent socket agents = {} ppid = Process.ppid Dir.glob('/tmp/ssh*/agent*').each do |fn| agents[fn.match(/agent\.(\d+)$/)[1]] = fn end while ppid != '1' if (agent = agents[ppid]) ENV['SSH_AUTH_SOCK'] = agent break end File.open("/proc/#{ppid}/status", "r") do |file| ppid = file.read().match(/PPid:\s+(\d+)/)[1] end end # Uncomment to require that an ssh-agent be available # fail "Could not find running ssh agent - Is config.ssh.forward_agent enabled in Vagrantfile?" unless ENV['SSH_AUTH_SOCK'] end action :create end 

De forma alternativa, cree un cuadro con la actualización sudoers ya incluida y base sus futuras VMs fuera de eso.

Puede que esta no sea la respuesta que está buscando, pero una solución fácil sería generar una key ssh de implementación dedicada sin una frase de contraseña. Prefiero keys de implementación separadas y dedicadas en lugar de una sola key para múltiples aplicaciones.

Puede ejecutar múltiples proveedores con Vagrant (incluso del mismo tipo), cada proveedor se ejecuta en su propia connection SSH. Por lo general, resuelvo este problema utilizando un aprovisionador de Shell que agrega Added Defaults env_keep = "SSH_AUTH_SOCK" a /etc/sudoers en la vm.

Aquí está el script Bash que uso para hacer justamente eso:

 #!/usr/bin/env bash # Ensure that SSH_AUTH_SOCK is kept if [ -n "$SSH_AUTH_SOCK" ]; then echo "SSH_AUTH_SOCK is present" else echo "SSH_AUTH_SOCK is not present, adding as env_keep to /etc/sudoers" echo "Defaults env_keep+=\"SSH_AUTH_SOCK\"" >> "/etc/sudoers" fi 

No he probado esto con el aprovisionador de Chef, solo con proveedores de Shell adicionales … pero por lo que entiendo, esto debería funcionar igual para su caso de uso.

La mayoría de los cuadros base vienen con keys ssh pnetworkingeterminadas / inseguras, es fácil habilitar el ssh auth sin contraseña para el vagrant, pero solo debe usarse para las testings.