Last time, I shared a happy story of vagrant being easy to set up. When I was done using vagrant ssh in my git bash window, I dutifully typed logout, scheduled the post on WordPress, and did some dishes.
I wanted to start my next post and keep experimenting, so in the same git bash window, I typed vagrant ssh, which had worked a moment ago. I was prompted for a password which is weird because (1) vagrant is supposed to use private key SSH authentication and the keyfile was still there and (2) vagrant made this account and I don’t know what the password is. Hmm. Try a blank password. No dice.
Update – this part works
I’m leaving the steps below because they mirror a lot of the searching I was doing, and describe a lot of the symptoms, so they might make this post easier to find, but I learned a much simpler fix: Don’t vagrant up from Powershell; do it from git bash instead. At least in my case, I think because Powershell doesn’t have an SSH client configured on my machine, I can’t vagrant up with correct key insertion from Powershell. In the solution below, I hard-code a path to a private key, which fixes the symptoms of not being able to generate and insert one, but doesn’t really fix the issue. If I remove the hard-coded path, change the insert private key setting back to true, and re-provision the machine from git bash, I don’t have any problems.
Original Post – works but not ideal
I tried vagrant halt to stop the VM. It failed to shut down properly, and vagrant killed it. Then vagrant up hung trying to initialize SSH. Not a great sign.
Then I went back to git bash, typed vagrant ssh again, and just guessed vagrant for the password, and it worked, but now my synced folders aren’t showing up, so I try vagrant halt again. Again it has to force a shutdown, and vagrant up starts to print default: Warning: Authentication failure. Retrying... over and over.
I did some googling and found a thread that suggested I try adding config.ssh.insert_key = false to the Vagrantfile. This apparently tells vagrant not to generate and ssh key if it doesn’t find one.
The box I’m trying to boot doesn’t have anything more secret than a typo-ridden early draft of this post, so I don’t mind the reduced security much right now. Running vagrant up gives me a nice message telling me that the box is already provisioned, and that I should run vagrant up --provision to for a re-provision. So I try that. Annnd default: Warning: Authentication failure. Retrying...
Sigh. Last time was so easy.
Anyway, the thread I found had a lot of sensible sounding chatter about the private key that came with the box image working, but not actually being secure. One of the suggested workarounds was putting the path to a private key in the config file. I tried that, pointinng at the local private key file vagrant made in Project\.vagrant earlier, but that didn’t work.
More googling. Apparently lots of people have this problem, and many different things are suggested. The general opinion seems to be “the boxes are bad at dealing with SSH keys, so just tell them to use the insecure key that shipped with Vagrant and whatever. This does not make me happy. I can find github issues from previous version of vagrant that claim this has been resolved, but I encountered it following the base tutorial on their site.
Anyway, to make a long story short, at %UserProfile%\.vagrant.d\insecure_private_key there is, surprisingly, a private key, though I’ll go out on a limb and assume it’s not a secure one.
Here’s how I fixed the error:
Step 1: edit the Vagrantfile
Add config.ssh.insert_key = false and
config.ssh.private_key_path = %UserProfile%\.vagrant.d\insecure_private_key (note that you need to escape backslashes and expand %UserProfile% manually).
Step 2: Nuke the current VM image.
Make sure you’re in the right directory and run vagrant destroy.
Step 3: Re-provision the image.
Run vagrant up --provision and confirm that you can vagrant ssh, halt and start the machine, and vagrant ssh again.
Now you should be where we were last week, except without some weird key issue preventing an ssh connection from being resumed once it was interrupted, but also without feeling like our box is that secure. Next time, we’ll resume the tutorial (and reinstall vim!)
Till then, happy learning.
-Will
