流浪汉默认不安全？

Question

编辑2:TL; DR:2013年答案是肯定的,但这个缺陷已得到修复

通过遵循vagrantup.com上的入门说明,我似乎最终得到了一个接受端口2222上的SSH连接的虚拟机,这样任何人都可以获得对我的VM的root访问权限并使用默认凭据读取我的主机工作目录(用户名) = password = vagrant或vagrant_insecure_private_key).

这是真的？如果是,为什么它不被视为一个巨大的安全漏洞？如果我将敏感数据复制到VM怎么办？

编辑:对于那些认为互联网上的任何人能够阅读你的资源并在你的虚拟机上执行任意代码并没有那么糟糕的人,我建议你阅读这篇博客文章http://blog.ontoillogical中的"突破"部分. COM /博客/ 2012/10月31日/磨合和-外的流浪汉/

简而言之:"按预期"运行Vagrant也可以让任何人进入您的主机/开发机器(例如,通过使用恶意git post-commit钩子).

Answer 1

简短的回答是肯定的.

为什么？

当建立流浪基座箱(手动或使用工具,如Veewee自动),助洗剂按照流浪基座箱规格定义了以下内容:

1. 用户root并vagrant使用vagrant作为密码
2. 用户的公钥认证(无密码)vagrant.

Vagrant项目为SSH公钥认证提供了一个不安全的密钥对,因此vagrant ssh可行.

因为每个人都可以访问私钥,所以任何人都可以使用私钥登录到您的虚拟机(假设他们知道您的主机IP,默认情况下端口是2222,因为转发规则已就位.)

这不是安全的OOTB.但是,您可以删除受信任的关键~vagrant/.ssh/authorized_keys,并添加自己,为更改密码vagrant和root,然后它被认为是相对安全的.

更新

从Vagrant 1.2.3开始,默认情况下SSH转发端口绑定到127.0.0.1,因此只允许本地连接[GH-1785].

重要更新

由于流浪1.7.0(PR#4707)流浪将替换与第一随机生成的密钥对的默认不安全的ssh密钥对vagrant up.

看到在CHANGELOG:默认不安全密钥对时,流浪将自动与第一随机生成的密钥对代替它vagrant up.GH-2608

Answer 2

我已经把这个作为一个问题在github存储库中为vagrant提出了.开发人员表示,他们将解决转发端口外部可用的问题.但是,开发人员不接受有关从VM中破坏主机环境的问题.我认为他们是危险的错误.

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

打破vm比链接的博客帖子更容易.您不必依赖git钩子来破坏主机,只需将任意ruby代码放入Vagrant文​​件即可.

如果可以的话,我会在VM沙箱中运行vagrant.由于我不能,我用防火墙做.

最好使用配置规则来添加安全的ssh密钥,并删除不安全的密钥和默认密码.

Answer 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

Answer 4

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