Vagrant 默认不安全？答案

【问题标题】：Vagrant insecure by default?Vagrant 默认不安全？
【发布时间】：2013-01-20 20:39:26
【问题描述】：

编辑 2：TL；DR：2013 年的答案是肯定的，但这个缺陷已经修复

按照 vagrantup.com 上的入门说明，我似乎最终得到了一个在端口 2222 上接受 SSH 连接的虚拟机，这样任何人都可以获取我的 VM 的 root 访问权限并使用默认设置读取我的主机工作目录凭据（用户名=密码=vagrant 或 vagrant_insecure_private_key）。

这是真的吗？如果是，为什么不认为它是一个巨大的安全漏洞？如果我将敏感数据复制到 VM 会怎样？

编辑：对于那些认为互联网上的任何人都能够阅读您的源代码并在您的 VM 上执行任意代码的人来说，我建议您阅读本文中的“突破”部分博文http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/

简而言之：“按预期”运行 Vagrant 还可以让任何人闯入您的主机/开发机器（例如，通过使用恶意 git post-commit 挂钩）。

【问题讨论】：

闯入和退出流浪者的链接已损坏。以下目前有效：blog.ontoillogical.com/blog/2012/10/31/…
web.archive.org/web/20160714220643/http://…
如何防范“爆发”漏洞？还是现在已经过时了，因为它可以防止闯入？

标签： security vagrant

【解决方案1】：

简短的回答是YES。

为什么？

在构建 Vagrant 基础盒（手动或使用 Veewee 等工具自动化）时，构建者遵循 vagrant base boxes specifications 定义以下内容：

用户 root 和 vagrant 使用 vagrant 作为密码
用户vagrant 的公钥身份验证（无密码）。

Vagrant 项目为 SSH 公钥身份验证提供了不安全的 key pair，以便 vagrant ssh 工作。

因为每个人都可以访问私钥，所以任何人都可以使用私钥登录您的虚拟机（假设他们知道您的主机 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 将在第一个 vagrant up 上用随机生成的密钥对替换默认的不安全 ssh 密钥对。

参见CHANGELOG：使用默认的不安全密钥对，Vagrant 会在第一个vagrant up 上自动将其替换为随机生成的密钥对。 GH-2608

【讨论】：

OOTB 配置并未完全受到威胁，但 OOTB 确实包括为在主机环境中运行 virtualbox 的用户提供对 VM 中具有 root 访问权限的任何人的有效访问权限。这是一个相当严重的缺陷，但仅靠其本身不足以危害主机。
还有无密码的 sudo！看来你不能忽视这一点？

【解决方案2】：

我在 github 存储库中提出了这个问题，用于 vagrant。开发人员表示他们将解决转发端口在外部可用的问题。但是，开发人员不接受有关从 VM 破坏主机环境的问题。我认为他们大错特错。

https://github.com/mitchellh/vagrant/issues/1785

脱离虚拟机比链接的博客文章建议的要容易。您不必依赖 git 挂钩来破坏主机，只需将任意 ruby 代码放入 Vagrant 文件即可。

如果可以的话，我会在虚拟机沙箱中运行 vagrant。既然不能，我就凑合着用防火墙吧。

最好有配置规则来添加安全的 ssh 密钥，并删除不安全的密钥和默认密码。

【讨论】：

【解决方案3】：

我编写了这个简单的内联 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”和“root”的密码“vagrant”这一事实无关，对吧？

【解决方案4】：

从 Vagrant 1.2.3 开始，默认是绑定到 localhost 而不是公共接口，避免了外部连接问题。

【讨论】：

【解决方案5】：

只是想补充一下，有一个 Vagrant 插件可以解决这个问题：vagrant-rekey-ssh。它会更改 VM 的默认密码，并删除不安全的 SSH 密钥。

【讨论】：

好东西。谢谢。但是，主机环境对 vagrant box 的暴露仍然存在，以防那里存在任何其他漏洞。
仅供参考：此功能现在包含在 Vagrant 1.7+ 中。该插件已过时。

【解决方案6】：

我想解释一下为什么 Vagrant 不一定像你想象的那样不安全。

首先我想说的是，我相信你们中的大多数人已经意识到，有必要保持对 Vagrant 盒子的开放访问，因为这些盒子是共享的。出于这个原因，我认为主要的安全问题不是在下载盒子后更改默认凭据。在桥接模式下运行这样的机器将允许网络上的某人使用默认凭据进行 ssh。

在我看来，这些盒子背后的想法是任何人都可以下载它，并且一旦拥有它就可以保护它。我的 vagrant 安装用一个新的、随机生成的 ssh 密钥替换了默认密钥。我不确定这是否是通过插件完成的，但是我很想知道无密码 sudo 和默认密码是否也存在安全风险。

【讨论】：