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