Vagrant“身份验证失败"在 up 期间，但是“vagrant ssh"可以进去就好了 [英] Vagrant "Authentication failure" during up, but "vagrant ssh" can get in just fine

问题描述

我被难住了.我正在尝试在 Windows 8.1 上运行 vagrant/virtualbox/coreos 集群来开发在云中运行的集群.我已经在四台机器上尝试过这个(都是带有最新更新的 Windows 8.1，并且都带有最新的 VirtualBox、Vagrant、Git 和相同的 Vagrant 配置.我正在从所有 4 个系统的 repo 中检查 Vagrant 配置，所以我相信每个配置都相同.我有 2 次成功和 2 次失败.

I'm stumped. I'm trying to run a vagrant/virtualbox/coreos cluster on Windows 8.1 to develop the cluster for running in the cloud. I've tried this on four machines (all are Windows 8.1 with latest updates and all with the latest VirtualBox, Vagrant, Git, and the same config for Vagrant. I'm checking the Vagrant config out of a repo on all 4 system so I'm confident the configs are the same for each. I get 2 successes and 2 failures.

两台机器成功是这样的:

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...

vagrant ssh 和 vagrant halt 在这两个系统上都可以正常工作.

vagrant ssh and vagrant halt both work fine on these two systems.

另外两台 Windows 机器失败如下:

Two other Windows machines fail like this:

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...

注意工作和非工作系统如何经历一次连接超时，但成功的系统实际上确实连接并完成了启动虚拟机，而不成功的系统只会卡在身份验证重试循环中

Note how both the working and non-working systems experience one timeout connecting, but then the successful ones actually do connect and finish bringing up the VM, whereas the unsuccessful ones just get stuck with an authentication retry loop.

在身份验证失败后，如果我让它超时，或者即使我按 ctrl+C，我可以运行vagrant ssh core-01"并直接进入:

Following the authentication failure, if I leave it to time out or even if I ctrl+C, I can run "vagrant ssh core-01" and it takes me straight in:

CoreOS (stable)
core@localhost ~ $

'vagrant halt' 也无法在这些系统上建立 ssh 连接:

'vagrant halt' also fails to make an ssh connection on these systems:

==> 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...

我可以成功地使用 putty 或其他 ssh 客户端使用 insecure_private_key 进行身份验证来访问 VM，所以我假设 VM 本身具有正确的配置，问题在于 Vagrant 的调用能力ssh 进入.如果Vagrant up"无法进入，则无法完成虚拟机的启动配置，所以我想主要解决这个问题.

I can successfully use putty or other ssh clients to access the VM using insecure_private_key for authentication, so I'm assuming the VM itself has the correct config, and the problem lay with Vagrant's ability to call ssh to get in. If "Vagrant up" can't ssh in, it cannot finish the startup config for the VM, so I'd like to solve this primarily for that reason.

这是 ssh 配置，它让我可以使用其他 ssh 客户端，我相信 Vagrant 应该使用它:

This is the ssh config that lets me get in with other ssh clients and I believe should be used by Vagrant:

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

我还为虚拟机启用了 GUI，控制台没有显示任何错误；它一直到登录提示都很好(这也与我可以通过 ssh 进入并以其他方式使用 VM 的事实一致).

I have also enabled GUI for the VM's and the console does not show any errors; it gets all the way to a login prompt just fine (which is also consistent with the fact that I can ssh in and otherwise use the VM).

我相信(但不知道如何验证)Vagrant 正在调用 C:\Program Files (x86)\Git\bin 中的 openssh 客户端

I believe (but don't know how to verify) that Vagrant is calling the openssh client in C:\Program Files (x86)\Git\bin

所有人都在运行 Vagrant 版本 1.7.2 和 git 1.9.5.红宝石 2.0.0p353.

All are running Vagrant version 1.7.2 and git 1.9.5. Ruby 2.0.0p353.

我的 %PATH% 大约有 500 个字符长.我相信 Vagrant 正在寻找某种 ssh 客户端，因为它至少会遇到一两次超时，然后身份验证失败.

My %PATH% is about 500 chars long. I'm confident Vagrant is finding an ssh client of some sort due to getting at least one or two timeouts followed by an authentication failure.

提前感谢您的任何想法！

Thanks in advance for any ideas!

更新: 深埋在 "vagrant up --debug" 的输出中的是这个小宝石:

Update: Buried deep in the output of "vagrant up --debug" is this little gem:

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)

最后的insecure_private_key.pub 无效"似乎是一个可靠的线索.

That final "insecure_private_key.pub is not valid" seems like a solid clue.

我已经尝试修改该文件以确保它只有用于行尾的 LF 和 CRLF，并且没有任何区别.视觉上看起来不错.它也与在其他系统之一上工作的文件 100% 逐字节相同.为什么会无效?我已经验证当前用户对文件具有完全控制权限，并且还尝试以管理员身份使用 vagrant.行为没有变化.:(

I've tried modifying that file to ensure it has just LF for line endings as well as CRLF and it makes no difference. Visually it looks fine. It's also 100% byte-for-byte identical to the file that's working on one of the other systems. Why would it be invalid? I have verified the current user has full control permissions on the file and also tried vagrant up as Administrator. No change in behavior. :(

推荐答案

移除
C:/Users/Mike/.vagrant.d/insecure_private_key

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

下次 vagrant 重启时会再次创建(这次应该是正确的)

on next vagrant restart it will be created again (this time should be correct)

这篇关于Vagrant“身份验证失败"在 up 期间，但是“vagrant ssh"可以进去就好了的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！