Reputation: 8718
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?
Upvotes: 3
Views: 2815
Reputation: 10104
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.
Upvotes: 0
Reputation: 28639
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 ).
Upvotes: 3