How to acquire Vagrant insecure password

[rdickert]

The documents instruct you to include this in your .profile or .zshrc:

ssh-add ~/.ssh/insecure_private_key &>/dev/null

However, it does not instruct you on where to find the insecure_private_key. Without this, you cannot run ansible-playbook as the vagrant user (they fail because Ansible is not allowed in without Vagrant's private key).

Solution: The repo for Vagrant private key can be found here and is the file named vagrant. If you rename this file insecure_private_key and place it in your ~/ssh/ directory (and restart your shell or paste the above ssh-add), the additional ansible-playbook scripts should work.

The documents will be updated for the next version.

[disassembler]

Why not just add your public key to the vagrant user's authorized_keys file? That seems a better way than adding an untrusted private keypair to your keychain.

[rdickert]

You are right that it's probably not great to add that keypair to your keychain, and it's not required at all if you provision with vagrant provision. There is a bootstrapping issue when you first provision (which is why Vagrant uses the insecure key in the first place); after that there are options. The original choice came from just trying to get Ansible to work the first time, but I think your idea is better.

There has also been a suggestion that the 'lead' program be Ansible, not Vagrant. In other words, Let Ansible request the vm from Vagrant, rather than having Vagrant call Ansible when it's done setting up the vm. This would have certain advantages regarding setting up local vms alongside live staging & prod systems. Perhaps in that case we would use the vagrant user only long enough to set up a user-defined master user (be it webmaster or other), which would obviate the need for modifying the vagrant user or the local keychain and keep vagrant off of live servers altogether. Note that the vagrant account set up by the Digital Ocean plugin does use a private key, not the insecure one, so the vagrant account is secure on DO – but there's always the chance that someone will make some bad choices to hook up another provider if we keep this structure.