可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效,请关闭广告屏蔽插件后再试):
问题:
EDIT 2: TL;DR: the answer was yes in 2013, but this flaw has been fixed
By following the Getting Started instructions on vagrantup.com, I seem to end up with a virtual machine that is accepting SSH connections on port 2222 so that anyone can get root access to my VM and read my host working directory using the default credentials (username=password=vagrant or vagrant_insecure_private_key).
Is this true? If yes, why is it not considered a gaping security vulnerability? What if I had copied sensitive data to the VM?
EDIT: and for those who think anyone on the internet being able to read your sources and executing arbitrary code on your VM is not that bad, I recommend reading the "Breaking out" section in this blog post http://blog.ontoillogical.com/blog/2012/10/31/breaking-in-and-out-of-vagrant/
In a nutshell: running Vagrant "as intended" can also enable anyone to break into your host/development machine (e.g., by using a malicious git post-commit hook).
回答1:
The short answer is YES.
Why?
When building Vagrant base boxes (manually or using tools like Veewee to automate), builders follow the vagrant base boxes specifications which defines the following:
- User
root
and vagrant
use vagrant as password
- Public key authentication (password-less) for the user
vagrant
.
Vagrant project provides an insecure key pair for SSH Public Key Authentication so that vagrant ssh
works.
Because everyone has access to the private key, anyone can use the private key to login to your VMs (suppose they know your IP of the host machine, port is by default 2222 as forwarding rules in place.)
It is NOT secure OOTB. However, you can remove the trusted key from ~vagrant/.ssh/authorized_keys
and add your own, change password for vagrant
and root
, then it's considered relatively safe.
Update
Since Vagrant 1.2.3, by default SSH forwarded port binds to 127.0.0.1 so only local connections are allowed [GH-1785].
IMPORTANT Update
Since Vagrant 1.7.0 (PR #4707) Vagrant will replace the default insecure ssh keypair with randomly generated keypair on first vagrant up
.
See in the CHANGELOG: the default insecure keypair is used, Vagrant will automatically replace it with a randomly generated keypair on first vagrant up
. GH-2608
回答2:
I've raised this as an issue on the github repository for vagrant. The developer has said they'll fix the issue with the forwarded ports being externally available. The developer does not however accept the issue regarding compromise of the host environment from the VM. I think they're dangerously wrong.
https://github.com/mitchellh/vagrant/issues/1785
Breaking out of the vm is easier than the linked blog post suggests. You don't have to depend on git hooks to compromise the host, you just put arbitrary ruby code into the Vagrant file.
I'd run vagrant in a VM sandbox if I could. Since I can't, I make do with a firewall.
It's a good idea to have provisioning rules to add a secure ssh key, and to remove the insecure key and the default password.
回答3:
I wrote this simple inline shell provisioner to swap out the authorized_keys with my id_rsa.pub. Once provisioned the insecure_private_key cannot be used to authenticate.
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
回答4:
As of Vagrant 1.2.3 the default is to bind to localhost instead of the public interface, avoiding the external connection issue.
回答5:
Just wanted to add that there is a Vagrant plugin that solves this problem:vagrant-rekey-ssh. It changes the default password of the VM, and removes the insecure SSH key.
回答6:
I would like to explain why Vagrant is not necessarily as insecure as you might think.
I would like to start off by saying that as I am sure most of you are already aware, it is necessary to maintain open access to the Vagrant box because of the way these boxes are being shared. For that reason, I believe the main security concern is not changing the default credentials after the box is downloaded. Running such a machine in bridged mode would allow someone on the network to ssh in with default credentials.
It appears to me that the idea behind these boxes is that anyone can download it, and secure it once it is in their possession. My vagrant installation replaces default keys with a new, randomly generated ssh key. I am not sure if this is being done with a plugin, however I am curious to know if the password-less sudo and default password also present a security risk.