编辑2：TL; DR：答案是在2013年是，但此缺陷已得到修复
按照vagrantup.com上的《入门指南》，我似乎最终得到了一个虚拟机，该虚拟机在端口2222上接受SSH连接，以便任何人都可以使用默认凭据（用户名）对我的VM进行root访问，并读取我的主机工作目录。 = password = vagrant或vagrant_insecure_private_key）。
这是真的？如果是，为什么不将其视为巨大的安全漏洞？如果我已将敏感数据复制到虚拟机怎么办？
编辑：对于那些认为互联网上的任何人都可以读取您的源代码并在您的VM上执行任意代码的人来说，还不错，我建议阅读此博客文章http：//blog.ontoilologic中的“突破”部分。 com / blog / 2012/10/31 / in-of-and-of-vagrant /
简而言之：“按预期”运行Vagrant也可以使任何人闯入您的主机/开发计算机（例如，通过使用恶意的git post-commit钩子）。
Answers:
简短的答案是“是”。
为什么？
在构建Vagrant基本框时（手动或使用诸如Veewee之类的工具进行自动化），构建者将遵循vagrant基本框规范，该规范定义了以下内容：
root并vagrant使用流浪汉作为密码vagrant。Vagrant项目为SSH公钥身份验证提供了不安全的密钥对，因此可以vagrant ssh正常工作。
因为每个人都可以访问私钥，所以任何人都可以使用私钥登录到您的VM（假设他们知道您的主机IP，默认情况下，端口为2222，作为转发规则。）
这不是安全的OOTB。但是，您可以从可信的密钥~vagrant/.ssh/authorized_keys和添加自己的，更改密码vagrant和root，然后认为它是相对安全的。
更新资料
从Vagrant 1.2.3开始，默认情况下SSH转发的端口绑定到127.0.0.1，因此仅允许本地连接[GH-1785]。
重要更新
由于Vagrant 1.7.0（PR＃4707），Vagrant将首先使用随机生成的密钥对替换默认的不安全ssh密钥对vagrant up。
请参阅CHANGELOG中的内容：使用默认的不安全密钥对，Vagrant会在first上自动将其替换为随机生成的密钥对vagrant up。GH-2608
我已经将它作为问题在github存储库上提出给流浪汉。开发人员表示，将通过外部可用的转发端口来解决此问题。但是，开发人员不接受有关VM损害主机环境的问题。我认为他们是错误的错误。
https://github.com/mitchellh/vagrant/issues/1785
脱离虚拟机比链接的博客文章建议的容易。您不必依赖git钩子来破坏主机，只需将任意的ruby代码放入Vagrant文件中即可。
如果可以的话，我会在VM沙箱中运行流浪汉。既然我做不到，我就使用防火墙。
最好有设置规则以添加安全的ssh密钥，并删除不安全的密钥和默认密码。
我编写了这个简单的内联shell配置程序，以将我的id_rsa.pub换成authorized_keys。设置后，不能使用insecure_private_key进行身份验证。
VAGRANTFILE_API_VERSION = "2"
Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
# ...
config.ssh.shell = "bash -c 'BASH_ENV=/etc/profile exec bash'" # avoids 'stdin: is not a tty' error.
config.ssh.private_key_path = ["#{ENV['HOME']}/.ssh/id_rsa","#{ENV['HOME']}/.vagrant.d/insecure_private_key"]
config.vm.provision "shell", inline: <<-SCRIPT
printf "%s\n" "#{File.read("#{ENV['HOME']}/.ssh/id_rsa.pub")}" > /home/vagrant/.ssh/authorized_keys
chown -R vagrant:vagrant /home/vagrant/.ssh
SCRIPT
end
只是想补充一点，有一个Vagrant插件可以解决此问题：vagrant-rekey-ssh。它更改虚拟机的默认密码，并删除不安全的SSH密钥。