Vagrant "Autenticazione fallita" durante up, ma "vagrant ssh" può andare bene

Question

Sono perplesso. Sto cercando di eseguire un cluster vagabondo/virtualbox/core su Windows 8.1 per sviluppare il cluster per l'esecuzione nel cloud. Ho provato questo su quattro macchine (tutte sono Windows 8.1 con gli ultimi aggiornamenti e tutte con l'ultima VirtualBox, Vagrant, Git, e la stessa configurazione per Vagrant. Sto controllando la configurazione di Vagrant da un repository su tutti e 4 i sistemi sono sicuro i file di configurazione sono gli stessi per ogni ottengo 2 successi e 2 fallimenti

due macchine riescono in questo modo:..

Bringing machine 'core-01' up with 'virtualbox' provider... 
==> core-01: Checking if box 'coreos-stable' is up to date... 
(snip) 
    core-01: SSH address: 127.0.0.1:2222 
    core-01: SSH username: core 
    core-01: SSH auth method: private key 
    core-01: Warning: Connection timeout. Retrying... 
==> core-01: Machine booted and ready! 
==> core-01: Setting hostname... 
==> core-01: Configuring and enabling network interfaces... 

ssh vagabondo e battuta d'arresto vagabondo entrambi funzionano bene su questi due sistemi

Altre due macchine Windows falliscono così:

Bringing machine 'core-01' up with 'virtualbox' provider... 
==> core-01: Importing base box 'coreos-stable'... 
==> core-01: Matching MAC address for NAT networking... 
==> core-01: Checking if box 'coreos-stable' is up to date... 
==> core-01: Setting the name of the VM: coreos-vm-cluster_core-01_1422899531630_88904 
==> core-01: Clearing any previously set network interfaces... 
==> core-01: Preparing network interfaces based on configuration... 
    core-01: Adapter 1: nat 
    core-01: Adapter 2: hostonly 
==> core-01: Forwarding ports... 
    core-01: 22 => 2222 (adapter 1) 
==> core-01: Running 'pre-boot' VM customizations... 
==> core-01: Booting VM... 
==> core-01: Waiting for machine to boot. This may take a few minutes... 
    core-01: SSH address: 127.0.0.1:2222 
    core-01: SSH username: core 
    core-01: SSH auth method: private key 
    core-01: Warning: Connection timeout. Retrying... 
    core-01: Warning: Authentication failure. Retrying... 
    core-01: Warning: Authentication failure. Retrying... 
    core-01: Warning: Authentication failure. Retrying... 
    core-01: Warning: Authentication failure. Retrying... 
    core-01: Warning: Authentication failure. Retrying... 
    core-01: Warning: Authentication failure. Retrying... 

nota come entrambi i sistemi non-lavoro lavoro e sperimentare un timeout di connessione, ma poi quelli di successo in realtà si connettono e finire il fanalino di VM, mentre i quelli falliti solo rimanere bloccati con un ciclo di tentativi di autenticazione.

In seguito al fallimento di autenticazione, se lascio a tempo fuori o anche se mi Ctrl + C, posso correre "ssh vagabondo core-01" e mi porta direttamente in:

CoreOS (stable) 
core@localhost ~ $ 

'arresto vagabondo' riesce anche a fare una connessione ssh su questi sistemi:

==> core-01: Attempting graceful shutdown of VM... 
    core-01: Guest communication could not be established! This is usually because 
    core-01: SSH is not running, the authentication information was changed, 
    core-01: or some other networking issue. Vagrant will force halt, if 
    core-01: capable. 
==> core-01: Forcing shutdown of VM... 

posso usare con successo stucco o altri client ssh per accedere al VM usando insecure_private_key per l'autenticazione, quindi presumo che la VM stessa abbia la configurazione corretta, e il problema risiede nell'abilità di Vagrant di chiamare ssh per entrare. Se "Vagrant up" non può ssh in, non può finire la configurazione di avvio per la VM, quindi mi piacerebbe risolvere questo principalmente per questo motivo.

Questa è la configurazione di ssh che mi permette di entrare in con altri client SSH e credo che deve essere utilizzato da Vagrant:

Host: 127.0.0.1 
Port: 2222 
Username: core 
Private key: C:/Users/Mike/.vagrant.d/insecure_private_key 

Ho anche attivato GUI per la VM e la console non mostra eventuali errori ; arriva fino a un prompt di login bene (che è anche coerente con il fatto che posso ssh e usare la VM in altro modo).

credo (ma non so come verificare) che Vagrant sta chiamando il client OpenSSH in C: \ Program Files (x86) \ Git \ bin

Tutti sono in esecuzione Vagrant versione 1.7.2 e git 1.9.5. Ruby 2.0.0p353.

Il mio% PATH% è lungo circa 500 caratteri. Sono fiducioso che Vagrant stia trovando un client ssh di qualche tipo a causa di almeno uno o due timeout seguiti da un errore di autenticazione.

Grazie in anticipo per qualsiasi idea!

Aggiornamento: sepolto nel profondo l'uscita di "Vagrant fino --debug" è questo piccolo gioiello:

D, [2015-02-02T23:11:10.755468 #3920] DEBUG -- 
    net.ssh.authentication.session[14661cc]: trying publickey 
E, [2015-02-02T23:11:10.756472 #3920] ERROR -- 
    net.ssh.authentication.key_manager[1473e1c]: 
    could not load public key file 
    `C:/Users/Mike/.vagrant.d/insecure_private_key': 
    Net::SSH::Exception (public key at 
    C:/Users/Mike/.vagrant.d/insecure_private_key.pub is not valid) 

Quella finale "insecure_private_key.pub non è valido" sembra un indizio solido .

Ho provato a modificare quel file per assicurarmi che abbia solo LF per terminazioni di linea e CRLF e non fa differenza. Visivamente sembra a posto. È anche al 100% byte per byte identico al file che funziona su uno degli altri sistemi. Perché sarebbe invalido? Ho verificato che l'utente corrente disponga di autorizzazioni di controllo completo sul file e che abbia anche provato vagabondo come amministratore. Nessun cambiamento nel comportamento. :(

Answer 1

Il file .pub creato da Puttygen (forse durante la creazione di una chiave privata nel formato di Putty)? L'ho fatto e ha impedito al vagabondo di connettersi alla scatola, ma potevo connettermi usando Putty e Puttygen. file.

Cambiare l'estensione sulla chiave pubblica Putty lavorato per me, presumibilmente perché Vagrant non provare a utilizzare più.

Answer 2

Quando ho creato il file PPK del file insecure_private_key, ho anche --out di abitudine-- creò una versione .pub. Questo sembrava causare il problema.come Jon, quando rimossi il file insecure_private_key.pub, vagabondo su era in grado di eseguire fino in fondo.

Se è stato creato un file insecure_private_key.pub utilizzando puttygen ed è possibile eseguire questo problema, suggerisco di rimuoverlo. Non è necessario per i vagabondi e si è solo intromesso.

Answer 3

Rimuovere
C: /Users/Mike/.vagrant.d/insecure_private_key

sul prossimo vagabondo riavviarlo verrà nuovamente creato (questa volta dovrebbe essere corretto)