vagrant does not remove insecure ssh key

[ted23p]

It adds a generated key, but fails to remove the insecure one.

Using config.vm.box = "puppetlabs/debian-8.2-64-puppet"

Contents of /home/vagrant/.ssh/authorized_keys

# HEADER: This file was autogenerated at 2015-12-09 04:18:39 -0800
# HEADER: by puppet.  While it can still be managed manually, it
# HEADER: is definitely not recommended.
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzIw+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9HZyN1Q9qgCgzUFtdOKLv6IedplqoPkcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIFo9D8HfdOV0IAdx4O7PtixWKn5y2hMNG0zQPyUecp4pzC6kivAIhyfHilFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NOTd0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcWyLbIbEgE98OHlnVYCzRdK8jlqm8tehUc9c9WhQ== vagrant
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC13+sHAbp8N+E0yvBcETKGltUCP9c9swtC0UGZFzePwTVBVPdMBBqCvS6RbnoA9usG/jIVz1os8Ppq8F6vVe5AOn8Npok0yHjpt3zOGab9PbNEVbb8CwciSWIAW7JO/7aYlqeuYS2kzn88EdGspLk3Vb6VizcUxiBkfshPGFGMNGvW+ejLAiD3lcIYpIxRyagDM5MWHuBMmzlxcv7kvf8alLXXLYq8y7n9cAJ3Th/HM5ypOX1VMv8TrAuQnkBfxnp6HKca138hOXrtplDVd4t7ObPvkhTpVsj8ScGCdijzizuabeAHoj6j2hEgN+fmgJQUg48fZgpoAVn725LWlPcT vagrant

Some relevant lines from command:

==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address: 127.0.0.1:2222
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Warning: Connection timeout. Retrying...
    default: Warning: Remote connection disconnect. Retrying...
    default:
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default:
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!

Running on vagrant 1.7.4 on windows 7 with rsync and openssh from msys2

[evancox10]

Is this still present? This is a pretty serious security vulnerability, but no response in 6 months?

Also a question, what's the point of going through the process of switching out the insecure public key with a secure one (either user-provided or randomly generated) if we still have the vagrant user with password vagrant? ditto for root We are not adding any security here in this case.

Why does this matter? Well if you're just running the VM locally with no internet access, then maybe insecure access is ok. However if you are pushing this VM to the cloud with one of the cloud providers, then there must be some public network exposure, and then what is to stop someone from logging in as the vagrant or even root user? And since I have most likely mounted my proprietary source code/assets into the Vagrant VM, these too are now exposed.

I am trying to follow the directions here and here in order to create a CentOS 6.8 Hyper-V base box (and after evaluating that, possibly move on to a cloud provider base box). I am concerned that there is hardly any information on the security ramifications of the default vagrant and root users/passwords.

I would think that, for cloud providers at least, you would want to turn off password-based SSH access by default.

Sorry if this is derailing the bug note. Once I have my VM up, I will double check this issue and see if I can repro it.

Edit: See these discussions for some background as well
https://github.com/mitchellh/vagrant/pull/4707
https://github.com/mitchellh/vagrant/issues/5005

[sethvargo]

Hi @evancox10

Thank you for your reply. Vagrant is not designed to be a "secure" tool. We call out, multiple times, in the documentation that Vagrant is a local development tool that sometimes uses insecure defaults to provide a better out-of-the box experience for developers.

If you are looking for a more secure want to manage cloud resources, I would recommend you take a look at Terraform. Terraform is designed to manage cloud resources. You can also build your own Vagrant boxes that do not use the default username, password, and public key using Packer or vagrant package.

I don't think Vagrant has ever boasted to be a secure tool (quite the opposite actually), but I apologize if this is causing you confusion. I also don't believe this is the best place to discuss this type of issue either. I would recommend posting these things on the Vagrant mailing list, since we try to keep the issue tracker reserved for bug reports and feature requests. Thanks!

[evancox10]

Thanks Seth, I will move this discussion to the mailing list and/or IRC

[astoltz]

I ran into this issue on AWS. What I found was the comment has to be "vagrant insecure public key" or else the insecure public key doesn't get removed. In your example, the comment is simply "vagrant".

The logic for this happens in https://github.com/mitchellh/vagrant/blob/master/plugins/communicators/ssh/communicator.rb#L179 which looks for a line that exactly matches the contents of https://github.com/mitchellh/vagrant/blob/master/keys/vagrant.pub, including the comment.

[chrisroberts]

The functionality exists if the guest is properly configured. Cheers!

[martinandersson]

Chris, say what?

Whatever that statement "properly configured" means, then I discovered the insecure key is left behind on a Ubuntu Budgie 18.10 VM (and the key has a trailing comment "vagrant insecure public key"). As has been pointed out already, this is a serious security issue. And never mind the cloud and deployments, many VMs are still exposed to Internet despite being a development environment. Who develops without Internet these days??

[chrisroberts]

Hi there. If the guest is properly configured, meaning that the public key included within the authorized_keys file matches the vagrant insecure public key found here: https://github.com/hashicorp/vagrant/blob/master/keys/vagrant.pub then it will be removed. If the value is modified within the authorized_keys file (including modifying the comment) then it will not match and the public key will not be removed.

[hashibot[bot]]

I'm going to lock this issue because it has been closed for _30 days_ ⏳. This helps our maintainers find and focus on the active issues.

If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.