Can't SSH into Vagrant VM (without using vagrant ssh)

Question

In preparation for adapting a fabric deployment script to work with a local Vagrant VM, I'm trying to convince the VM to let me SSH into it without using vagrant ssh. I keep getting errors.

I've tried a lot of different combinations of settings, but here is the latest Vagrant file:

Vagrant.configure(2) do |config|

  config.vm.provider "virtualbox" do |v|
    v.memory = 6144
    v.cpus = 2
    v.name = "mb_vagrant"
  end

  config.vm.box = "ubuntu/trusty64"

  config.vm.network :private_network, ip: "192.168.33.10"

  config.ssh.forward_agent = true

  config.vm.provision :shell, path: "bootstrap.sh"
  config.vm.network :forwarded_port, host: 8001, guest: 8001

end

vagrant ssh-config shows me:

Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /Users/sloan/code/vagrant/.vagrant/machines/default/virtualbox/private_key
  IdentitiesOnly yes
  LogLevel FATAL
  ForwardAgent yes

If I try to SSH in using the key file and IP I set, I get connection refused:

> ssh -i /Users/sloan/code/vagrant/.vagrant/machines/default/virtualbox/private_key -p 2222 [email protected]
ssh: connect to host 192.168.33.10 port 2222: Connection refused

If I try the same thing with [email protected] instead of [email protected] I get a Host key verification failure.

What am I missing here?

Answer 1

Host key verification failure

This is a security feature of ssh that tries to stop man in the middle attacks before they happen.

Your computer, last time it ssh'd into that vagrant box, stored a copy of the servers signature; when you are connecting now, most likely after a rebuild, you are connecting to the same physical address, and the signatures now mismatch.

To clear out stale entries, you can find them in the plain text file ~/.ssh/known_hosts on your client device ( the device you are trying to ssh from ).

Answer 2

Using UserKnownHostsFile option is preferred over deleting ~/.ssh/known_hosts file to prevent host verification failure. I.e:

ssh -o UserKnownHostsFile=/dev/null -i <private-key-path> \
-p 2222 [email protected]

Deleting known_hosts could be a security flaw if you work with unmanaged. external servers (remote, public). Making the exception on your local vm makes sense as it is under your full control.