ssh - retrying - Vagrant atascado el tiempo de espera de la conexión reintentando

warning connection aborted retrying vagrant (30)

Mi vagabundo estaba funcionando perfectamente bien anoche. Acabo de encender la PC, golpeé vagrant up , y esto es lo que obtengo:

==> default: Clearing any previously set network interfaces... ==> default: Preparing network interfaces based on configuration... default: Adapter 1: nat default: Adapter 2: hostonly ==> default: Forwarding ports... default: 22 => 2222 (adapter 1) ==> default: Booting VM... ==> default: Waiting for machine to boot. This may take a few minutes... default: SSH address: 127.0.0.1:2222 default: SSH username: vagrant default: SSH auth method: private key default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying... default: Error: Connection timeout. Retrying...

¿Alguien ha tenido esto antes? vagrant aún no está ampliamente cubierto en la web y no puedo encontrar una razón por la que esto esté ocurriendo.

Cuando está atascado con su máquina errante de la manera descrita anteriormente, no hay necesidad de iniciar en modo gui (y es imposible sin un servidor X).

Mientras su máquina virtual se está iniciando, en una ventana de terminal separada, simplemente averigüe la ID de la máquina en ejecución.

vboxmanage list runningvms

Esto resultará en algo como esto:

"projects_1234567890" {5cxxxx-cxxx-4xxx-8xxx-5xxxxxxxxxx}

Con bastante frecuencia, la máquina virtual simplemente está esperando que seleccione una opción en el cargador de arranque. Puede enviar el código clave apropiado (en el caso, Ingresar ) a la controlvm con controlvm :

vboxmanage controlvm projects_1234567890 keyboardputscancode 1c

Eso es. Su máquina virtual continuará el proceso de arranque.

Descubrí que en MacOS con VirtualBox agregar esto a Vagrantfile te permitirá ir más allá:

config.vm.provider ''virtualbox'' do |vb| vb.customize [''modifyvm'', :id, ''--cableconnected1'', ''on''] end

El mío funcionaba bien y luego este "Aviso: desconexión de conexión remota. Reintentando ..." una y otra vez, quizás 20 veces, hasta que se conectó. Basado en las respuestas anteriores acabo de

vagrant destroy vagrant up

y todo estuvo bien. El mío era muy simple, pero lo hice de esa manera reduciendo el Vagrantfile a solo el config.vm.box = "ubuntu/trusty64" y aún lo estaba haciendo. Por eso, destruir y comenzar de nuevo parecía la mejor opción. Dada la naturaleza sin estado de estas imágenes Vagrant, no veo por qué eso no funcionaría en todos los casos. Me estoy metiendo en esto y aún puedo aprender que eso no es cierto.

El tiempo de espera de la conexión SSH durante el arranque inicial puede estar relacionado con una variedad de razones, tales como:

verifique si la virtualización está habilitada en BIOS (según el comment ),
el sistema espera la interacción del usuario (por ejemplo, compartir partición no está listo ),
falta de coincidencia de su clave privada (verifique la configuración a través de vagrant ssh-config ),
el proceso de arranque lleva mucho más tiempo (intente aumentar config.vm.boot_timeout ),
está arrancando desde la unidad incorrecta (por ejemplo, desde el instalador ISO),
Configuración incorrecta del cortafuegos de VM (por ejemplo, configuración de iptables ),
reglas de cortafuegos locales, conflicto de puerto o conflicto con un software de VPN,
sshd configuración.

Para solucionar el problema, ejecútelo con una opción --debug o como:

VAGRANT_LOG=debug vagrant up

Si no hay nada obvio, intente conectarse a él desde otro terminal, vagrant ssh o:

vagrant ssh-config > vagrant-ssh; ssh -F vagrant-ssh default

Si el SSH aún falla, intente ejecutarlo con una GUI (por ejemplo, config.gui = true ).

Si no es así, verifique los procesos en ejecución (por ejemplo vagrant ssh -c ''pstree -a'' ) o verifique su sshd_config .

Si es VM desechable, siempre puedes intentar destroy y volver a subirla.

También debe considerar actualizar su Vagrant y Virtualbox.

Para obtener más información, consulte la página de depuración y solución de problemas .

Eliminar el archivo:

C:/Users/UserName//.vagrant.d/insecure_private_key

Entonces corre:

vagrant up

En lugar de hacer ctrl-d-ing fuera de la caja virtual, como siempre lo hago cuando hago algo, creo que vagrant preferiría que te metieras en otra terminal y hagas una:

vagrant halt

para detener la caja. Entonces no habrá problemas para volver al VB.

Estaba probando una carpeta montada en mi máquina virtual vagrant agregando una nueva entrada en /etc/fstab . Más tarde cerré la sesión, corrí la detención de los vagabundos, pero cuando me encontré con los vagrant up obtuve

SSH auth method: private key Warning: Remote connection disconnect. Retrying...

Leí todos estos mensajes y probé todos los que parecían relevantes para mi caso (excepto por vagrant destroy, que sin duda habría solucionado mi problema, pero fue el último recurso en mi caso). La publicación de @Kiee me dio la idea de intentar iniciar mi VM directamente desde la GUI de VirtualBox. Durante el proceso de arranque, la VM se detuvo y me preguntó si quería omitir el montaje de la carpeta de prueba que había agregado anteriormente a /etc/fstab . (Es por eso que vagrant no pudo iniciar la máquina virtual). Después de responder "NO", la máquina virtual no inició ningún problema. Me conecté, quité la línea traviesa de mi fstab y cerré la máquina virtual.

Después de eso vagrant fue capaz de arrancar muy bien.

¿Para llevar? Si de repente, vagrant no puede volver a iniciar en su máquina virtual, intente iniciar directamente desde el proveedor (VirtualBox en mi caso). Es probable que su bota esté colgando de algo que no esté relacionado con SSH.

Experimenté el mismo problema en una máquina con Windows 8.1. El tiempo de espera de la conexión y la habilitación de la interfaz gráfica de usuario no fueron útiles en absoluto, la pantalla era negra. La solución en mi caso fue deshabilitar "Hyper V"

Cita de la documentación de Vagrant https://docs.vagrantup.com/v2/hyperv/index.html

Advertencia: la activación de Hyper-V hará que VirtualBox, VMware y cualquier otra tecnología de virtualización dejen de funcionar. Vea esta publicación del blog https://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx para una manera fácil de crear una entrada de arranque para iniciar Windows sin Hyper-V habilitado, si es posible que haya otros hipervisores.

FWIW-- Mi problema se debió al uso de un archivo de configuración realmente antiguo en lugar de uno más nuevo. El uso del nuevo archivo de configuración (y por lo tanto, modificó / modificó el DSL) solucionó mis problemas al instante.

Hay muchas respuestas buenas aquí, y no pude leerlas todas, pero también vine para dar mi pequeña contribución. Tuve 2 problemas diferentes:

vagrant up no pudo encontrar mi ssh '' id_rsa '' (porque todavía no la tenía): corrí ssh-keygen -t rsa -b 4096 -C "[email protected]" , basado en este artículo de GitHub , y voilá, paso a través de eso;
Luego, tuve el mismo problema de esta pregunta: " Advertencia: se agotó el tiempo de conexión. Reintentando ... ", eternamente ...: Entonces, después de leer mucho, reinicié mi sistema y miré mi BIOS (F2 para obtener allí, en la PC), y se deshabilitó la virtualización . He habilitado eso, guardé e inicié el sistema una vez más, para comprobar si ha cambiado algo.

Después de eso, vagrant up funcionó a la perfección! Son las 4 de la madrugada pero se está ejecutando! Que genial, hã? : D Como sé, hay muy pocos desarrolladores masoquistas como yo, que intentarían esto en Windows, especialmente en Windows 10 , simplemente no pude dejar de venir aquí y dejé mi palabra ... otra información importante, es que, Estaba tratando de configurar Laravel 5 , usando Homestead, VirtualBox, compositor, etc. Ha funcionado. Entonces, espero que esta respuesta ayude, como esta pregunta y las respuestas me ayudaron. Mis mejores deseos. G-bye!

He enfrentado el mismo problema. Arreglé esto habilitando la Virtualization desde la configuración del BIOS .

Instalar un bit ubuntu32 en un bit AMD64 hizo el truco. No tengo acceso a las BIO ya que es un entorno restringido, pero aún pude hacerlo funcionar con ubuntu / trusty32 en lugar de ubuntu / trusty64

Uso de Vagrant 1.6.3 con VirtualBox 4.3.15 en Windows 7 SP1

Espero que ayude.

La solución que he encontrado es comprobar la opción de conexión del cable en el adaptador 1 que está conectado a NAT. Realmente no lo sé, esta es mi cuarta caja errante, pero esta es la única con la opción de conexión de cable que no está marcada, y al verificarla, funciona.

Lo que funcionó para mí fue permitir la virtualización de 64 bits en un sistema operativo de 64 bits (Ubuntu 13.10) de BIOS.

Lo que me ayudó fue habilitar la virtualización en BIOS, porque la máquina no arrancó.

Me enfrenté al mismo problema, sin embargo, ninguna de las soluciones mencionadas funcionó para mí. ¡Lo resolví bajando Vagrant a 1.6.2 y ahora funciona!

Obtuve esto cuando ejecuté vagrant / VirtualBox dentro de VirtualBox. Resolví esto ejecutando la máquina errante en la máquina host.

Para mí fue la compatibilidad entre vagrant y virtual box.

Estoy en Windows 10 y lo que hice desinstalé vagrant y virtual box

Luego instale una versión anterior de virtual box específicamente la versión 4.3.38 (Instale también el paquete de extensión para esta versión)

Luego instaló la última copia de vagrant (1.8.5 en este momento)

Después de eso funcionó.

Resolví este problema y responderé en caso de que alguien más tenga un problema similar.

Lo que hice fue: habilité la GUI de la caja virtual para ver que estaba esperando la entrada en el inicio para seleccionar si quería iniciar directamente a ubuntu o safemode, etc.

Para activar la GUI, debe poner esto en su configuración Vagrantfile :

config.vm.provider :virtualbox do |vb| vb.gui = true end

Si está trabajando en Windows 8 o 10, esto es lo que funcionó para mí:

Cambiar la configuración del BIOS para permitir la virtualización de 64 bits.
Aquí es cómo:
- Reinicie la PC usando Inicio avanzado (Vaya a Inicio avanzado - ''reiniciar ahora'' - ''solucionar problemas'' - ''opción avanzada'' - ''Configuración de firmware UEFI'' - ''Reiniciar'')
- Ventana BIOS interna: vaya al menú / pestaña ''Avanzado'' - Habilite ''Tecnología virtual Intel''
- Guardar la salida.

Si no desea habilitar la GUI y luego tiene que deshabilitarla más tarde, también puede instalar el paquete de extensión de Oracle:

http://www.oracle.com/technetwork/server-storage/virtualbox/downloads/index.html#extpack

Luego coloque esto en su Vagrantfile para habilitar VRDP:

vb.customize ["modifyvm", :id, "--vrde", "on"]

Ahora puede usar RDP para conectarse a su caja a pedido sin necesidad de que SSH esté en ejecución o la GUI abierta todo el tiempo.

Tal vez esta es una respuesta demasiado simple para ayudar a mucha gente, pero vale la pena intentarlo si no lo ha hecho: haga un "alto errante" en lugar de un "vagrant suspend" y reinicie la VM con "vagrant up".

Creo que mi problema se debió a que el proceso de "kworker" se llenó de buggy y se agitó constantemente en la máquina virtual, por lo que al hacer un reinicio completo parecía que el proceso se volvía a cargar correctamente, mientras que guardar y restaurar solo estaba restaurando el proceso roto en su estado roto.

Tuve el mismo problema cuando estaba usando x64 box (chef / ubuntu-14.04).

Cambié a x32 y funcionó (hashicorp / precise32).

Tuve el mismo problema después de eliminar esta línea de mi Vagrantfile:

config.vm.network "private_network", type: "dhcp"

VM cargado bien después de que puse esta línea de nuevo.

Tuve el mismo problema, pero ninguna de las otras respuestas resolvió completamente mi problema. La respuesta de @Kiee fue útil, aunque todo lo que pude ver en la GUI fue una pantalla en negro (con el subrayado en la parte superior izquierda, este problema en Virtual Box también se planteó por separado en el desbordamiento de pila, de nuevo, nada ayudó).

Finalmente, una solución resultó ser muy simple: verifique la versión de su máquina virtual.

Más precisamente, tenía una caja de otra persona con Debian de 64 bits, pero Virtual Box insistió en tratarlo como de 32 bits, lo que no noté. Para cambiarlo, abra Virtual Box, luego abra la terminal y ejecute

vagrant up

espera la linea

default: SSH auth method: private key

ahora puede presionar ctrl + C (o esperar un tiempo de espera) y ejecutar

vagrant halt

su máquina virtual no se destruirá, por lo que puede verla en el menú de Virtual Box, pero se apagará y podrá cambiar la configuración. Elija su máquina en el menú, haga clic en ''Configuración'' -> ''General'' y elija la ''Versión'' correcta, para mí fue ''Debian (64 bits)''. Después de este tipo vagrant up nuevo.

Si este es un caso para usted (o los diferentes cambios en ''Configuración'' solucionaron su problema), puede crear un nuevo cuadro a partir del que está reparado escribiendo

vagrant package --output mynew.box

Algunos detalles más: host Ubuntu 32.04 de 32 bits, Debian 8.1 de 64 bits invitado, Virtual Box 5.0.14, Vagrant 1.8.1

Tuve exactamente el mismo problema. Pensé que el problema podría ser con las claves SSH (localización incorrecta del archivo u otra cosa, pero lo revisé muchas veces), pero siempre puede agregar en la sección de configuración del nombre de usuario y la contraseña (sin usar las claves ssh) y ejecutar gui, por lo que el código en Vagrantfile debería Parezca más o menos como a continuación:

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config| config.ssh.username = "vagrant" config.ssh.password = "vagrant" config.vm.provider "virtualbox" do |vb| vb.gui = true end end

En mi caso, incluso si se mostró GUI, obtuve una pantalla en negro (sin errores o posibilidad de inicio de sesión o cualquier otra cosa) y en la consola obtuve el Error: Connection timeout. Retrying... Error: Connection timeout. Retrying... muchas veces. Me aseguré de tener VT-x (virtualización) habilitada en BIOS, verifiqué muchas combinaciones de versiones de Virtual Box y Vagrant juntas y muchas cajas de Vagrant (para algunas de ellas no tenía pantalla negra en la GUI pero aún tengo conexión) problemas). Finalmente, volví a actualizar VirtualBox y Vagrant a las últimas versiones y el problema seguía ocurriendo.

Lo crucial fue mirar los iconos en VirtualBox después de ejecutar vagrantup (con GUI en Vagrantfile como se muestra arriba) como en la imagen de abajo

Aunque no tenía errores en VirtualPC (no hay advertencias de que VT-x no esté habilitado), mi icono V estaba antes en gris, lo que significa que VT-x estaba deshabilitado. Como dije, lo tenía activado en mi BIOS todo el tiempo.

Finalmente, me di cuenta del problema por HYPER-V que también instalé y habilité para probar sitios en Internet Explorer más antiguo. Fui al Control Panel -> Programs and functions / Software Windows Control Panel -> Programs and functions / Software y seleccioné del menú de la izquierda Turn on or Turn off Windows functions (espero que las encuentre, uso Windows en polaco, así que no sé los nombres exactos en inglés). Apagué Hyper-V, reinicié la PC y, después de ejecutar Virtual Box y vagrant up , finalmente no tuve errores, en la GUI tengo la pantalla de inicio de sesión y mi icono de V detuvo para aparecer en gris.

Perdí mucho tiempo resolviendo este problema (y muchos reinicios de PC), así que espero que esto pueda ser útil para cualquier persona que tenga un problema en Windows. Asegúrese de que tiene desactivado Hyper-V en su Panel de Control.

Tuve un problema con esto con una caja existente (no estoy seguro de lo que cambió), pero pude conectarme a través de SSH, a pesar de que la caja Vagrant no se pudo iniciar. Como sucedió mi clave SSH había cambiado de alguna manera.

Desde la carpeta raíz de vagrant ejecuté vagrant ssh-config que me dijo dónde estaba el archivo clave. Abrí esto con puttygen y luego me dio una nueva clave.

En mi invitado Linux, ~/.ssh/authorized_keys y dejé caer la nueva clave pública allí.

¡Todo vuelve a funcionar, por ahora!

Una cosa para volver a verificar es si la virtualización de hardware está habilitada en el BIOS de su máquina.

Mi problema es la misma serie de tiempos de espera, pero solo pude ver una pantalla negra en la GUI.

Una computadora portátil que estaba configurando seguía mostrando el mismo problema. Después de horas de búsqueda, finalmente encontré una sugerencia para ver si el BIOS tenía habilitada la virtualización de hardware.

Aquí está el contenido del post que encontré:

Veo que todavía hay algunos usuarios que están experimentando este problema. Por lo tanto, intentaré resumir una lista a continuación de algunas posibles soluciones al problema del tiempo de espera de SSH:

Asegúrese de que su firewall o antivirus no esté bloqueando el programa (lo cual dudo que suceda a menudo)
Dale a tu máquina errante algo de tiempo para que se den los tiempos muertos. Si no tiene una PC / Mac muy rápida, la VM tardará en iniciarse en un estado listo para SSH, por lo que se producirán tiempos de espera.
Por lo tanto, primero trate de dejar el tiempo de espera errante COMPLETAMENTE antes de concluir que hay una falla.
Si vagrant se agota completamente, aumente el límite de tiempo de espera en el archivo vagrant a unos pocos minutos e intente nuevamente.
Si eso todavía no funciona, intente limpiar su máquina errante a través de la interfaz de VirtualBox y habilite la GUI de la máquina de antemano. Si la GUI no muestra nada de lo que está sucediendo (es decir, solo una pantalla negra, no hay texto) mientras se está iniciando, entonces su máquina errática tiene problemas.
Destruye toda la máquina a través de la interfaz VB y reinstala.
Elimine los archivos de imagen de ubuntu en la carpeta Vagrant Images en la carpeta del usuario y vuelva a descargar e instalar.
¿Incluso tiene un procesador Intel que admita la virtualización de hardware de 64 bits? Buscalo en Google. Si lo hace, asegúrese de que no haya ninguna configuración en su Bios que deshabilite esta función.
Deshabilite la función hyper-v si está ejecutando Windows 7 u 8. Google cómo deshabilitarlo.
Asegúrese de que está ejecutando a través de un cliente habilitado para SSH. Utilice Git bash. Descargar: http://git-scm.com/downloads
Instale una versión de ubbit de 32 bits como trusty32 o precise32. Simplemente cambie la versión en el archivo vagrant y vuelva a instalar vagrant en el nuevo directorio.
Asegúrese de que está utilizando las últimas versiones de vagrant y virtualbox. Últimos recursos: formatee su computadora, reinstale Windows y compre un procesador de Intel Core Isomething.

Espero que ayude.

Una solución más posible para los usuarios del proveedor de VMware: para mí, el problema se resolvió después de eliminar una instalación paralela de VirtualBox en la misma máquina host. Las interfaces de red entre VMware y VirtualBox aparentemente eran conflictivas

Verifique que la virtualización de su CPU en la configuración del BIOS esté habilitada.