if .vagrant/machines/*/*/private_key exists, config.ssh.private_key_path in the Vagrantfile is ignored

[deltamualpha]

This is just my guess based on behavior, but I've been going nuts trying to track down issues here and this seems like the root of it.

I was able to ssh into my virtualbox environment using vagrant ssh --plain and another key I knew was in the authorized_keys file, as well as set as the config.ssh.private_key_path, but normal vagrant ssh would not work. Vagrant had generated a private key, however, that I had removed (via configuration management) from authorized_keys. Deleting the key itself from the .vagrant directory for the environment suddenly restored my ability to log in.

Additionally, having ~/.vagrant.d/insecure_private_key in your config.ssh.private_key_path array means that Vagrant will continue to try and generate and insert a fresh generated key, even if it's only there as a fallback option for bootstrapping.

Vagrant should never discard explicit user settings in a Vagrantfile.

[deltamualpha]

I guess this is coming at #4967 from a different direction?

[mitchellh]

If the private_key file exists, it uses that as a highest priority because it means that it was set/created by Vagrant itself. If you have private_key_path set, it shouldn't make this, but if you add the private key path later, it won't work...

I think we need to think about this more. Tagging as a bug to think on.

[jtreminio]

PuPHPet implemented its own key generator several months ago, before Vagrant 1.7 came out.

It uses the insecure key on initial $ vagrant up, then runs a bash file inside the VM to generate a new, custom SSH key. Afterward it deletes all instances of the insecure key from within the VM so it will no longer work and only the new generated key will work.

PuPHPet's solution is more 'powerful' because a custom SSH key is generated even if the host is a Windows machine.

This bug breaks puphpet in that the custom SSH key does not exist on initial $ vagrant up - it gets generated via provisioning.

You can see how this is implemented here: https://github.com/puphpet/puphpet/blob/master/src/Puphpet/Extension/VagrantfileLocalBundle/Resources/views/Vagrantfile.rb.twig#L232

This breaks it because, as you mentioned, it ignores private_key_path if private_key exists.

My solution is unfortunately hacky. I check if the custom key has been generated, delete the Vagrant key, replace it with the custom, and go on from there.

It would be much cleaner if Vagrant respected private_key_path at all times.

[ian-s-mcb]

I agree with what @deltamualpha wrote:

Vagrant should never discard explicit user settings in a Vagrantfile.

I personally found vagrant's treatment of config.ssh.private_key_path very confusing. It wasn't until I found this issue, I that understood why vagrant ssh-config didn't display the key that I specified in my Vagrantfile.

[zlangbert]

Just want to give this another +1. Ran into the same issue and was confused.

[bravo-kernel]

👍 for:

• giving private_key_path (and the order of keys in it's array) the highest priority
• using .vagrant/machines/default/virtualbox/private_key as fallback

Especially useful when setting your own private key on a later moment.

[acesuares]

aha.

[sSeewald]

Hi,
i stumbled across the same problem. In my setup are multiple machines and it was nice to share one private key, because it's only a dev environment - like it was in 1.6x. Otherwise i understand the design decision to generate unique keys for each machine, especially for the security specialists ;). It would be nice to have an option for your own "insecure" key - but it is nice to have.

For me the setting works perfect for what it is meant to be - I setup a custom Box with my private key and define it in the private_key_path and it works.

[acesuares]

For me, it only works if in the install script, I delete the private key inside .vagrant.
The config directive is ignored, so I have to do that.

[mitchellh]

Fixed on master!

[bravo-kernel]

:clap

[acesuares]

yay!