Vagrant insecure by default?

Question

EDIT 2: TL;DR: the answer was yes in 2013, but this flaw has been fixed

By following the Getting Started instructions on vagrantup.

Answer 1

As of Vagrant 1.2.3 the default is to bind to localhost instead of the public interface, avoiding the external connection issue.

Answer 2

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.

Answer 3

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.

Answer 4

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

Answer 5

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:

1. User root and vagrant use vagrant as password
2. 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

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