Connecting To A Vagrant Box Without The 'vagrant ssh' Command

Sunday, May 18, 2014 - 22:22

When Vagrant sets up a virtual machine it will set up a port on your local machine that you can use to connect to the box via SSH. By default this is usually port 2222, which Vagrant maps to port 22 on the virtual machine. All this is essentially transparent so that when you type vagrant ssh you connect to the box without any problems. Vagrant handles all of the port matching and key finding behind the scenes.

Out of curiosity I found myself needing to connect to the box directly via the IP address I set in the Vagrantfile rather than use the vagrant ssh command. I know that Vagrant creates a link to the server with the username of 'vagrant' and a private key that is found in the .vagrant.d directory in your user folder. This is the same private key that has been in use since the beginning of Vagrant so it will be the same on any machine with Vagrant installed. So my first test was with a standard SSH connect command, but also passing in the Vagrant insecure key using the -i flag. This failed with the following output.

1
2
$ ssh vagrant@192.168.100.100 -i /your/user/directory/.vagrant.d/insecure_private_key
Received disconnect from 192.168.100.100: 2: Too many authentication failures for vagrant

After a bit of digging I found that although I was passing in the key there were a few other options that I needed to include in order to get things working. This lead me to discover the vagrant ssh-config command. You can use this command to output a valid SSH configuration that can be placed into your SSH config file to allow connection to the virtual machine. Here is some sample output (the reference to 'default' is the name of the host in your Vagrantfile).

1
2
3
4
5
6
7
8
9
10
11
Host default
  HostName 127.0.0.1
  User vagrant
  Port 2222
  UserKnownHostsFile /dev/null
  StrictHostKeyChecking no
  PasswordAuthentication no
  IdentityFile /your/user/directory/.vagrant.d/insecure_private_key
  IdentitiesOnly yes
  LogLevel FATAL
  ForwardAgent yes

By putting this into your .ssh/config file you can connect to the virtual machine via SSH in the following way.

ssh vagrant@127.0.0.1

However, what we are doing here is essentially using the local machine to route us to the correct machine based on it's port number. I still wanted to connect to the box via the IP address that I had set for it. This meant using the -o flag to pass in the extra SSH config parameters to the command.

So assuming that the virtual machine's IP address is 192.168.100.100 then you would connect to it in the following way.

ssh vagrant@192.168.100.100 -i /your/user/directory/.vagrant.d/insecure_private_key -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o PasswordAuthentication=no -o IdentitiesOnly=yes

You can simplify this slightly by using your SSH config file to automatically add these parameters to your SSH call when you run it. This assumes the box IP address is the same as above, but you can also include wildcards in the Host header to include a number of Vagrant boxes (based on their IP address).

1
2
3
4
5
6
7
Host 192.168.100.100
  StrictHostKeyChecking no
  UserKnownHostsFile /dev/null
  IdentitiesOnly yes
  User vagrant
  IdentityFile /your/user/directory/.vagrant.d/insecure_private_key
  PasswordAuthentication no

This allows you to connect to the box using the following command (without so many of the extra options present).

ssh vagrant@192.168.100.100
Category: 
Tags: 
philipnorton42's picture

Philip Norton

Phil is the founder and administrator of #! code and is an IT professional working in the North West of the UK.
Google+ | Twitter

Comments

So close. It seemed like this was exactly what I needed. I'd been using Vlad for about 2 two weeks at home. I came into the office and now am unable to ssh into my vlad sites. Vagrant status reveals that they are running. "vagrant up" timed out and says that the ssh agent is not running. It seemed that your post was just what the doctor ordered. I had customized the ip address to be 192.168.100.101 so perhaps that was the problem. But no dice.
I've added your settings to my ~/.ssh/config file and the ssh fails saying connection refused.
I assume that it has something to do with NAT vs. Bridge but that is WAY over my head. I've got a call into my IT specialist to help me track it down. Until then it's back to my tried and true VMWare debian node to do drupal development. So sad, I really want to leave VMWare in the dust but no matter how hard I try chef or ansible I just can't get them working as good as my VMWare lamp stack.

Still hoping..

philipnorton42's picture
Submitted by philipnorton42 on Wed, 06/04/2014 - 11:40

It's a shame that you're having problems. There have been some changes to the ansible-vagrant integration recently that has caused some issues with Vlad, especially around SSH access to the box. I think these issues have been nailed down in the latest release of Vlad but if you are having trouble then please pop over to the Vlad issue tracker (https://bitbucket.org/philipnorton42/vlad/issue) and we should be able to help you out.

Thanks for this! I got it working!

@Dan, I'm with you ... I've had lots of trouble getting my head around Chef and Capistrano, but I'm getting there. I think you put the config in the wrong place? The config file needs to be created on the Guest VM (the Vagrant box) in the .ssh directory. It looks like, based on your path, you put in your Host machine's home directory: ~/.ssh/config?

Kind regards,
Dave

Uh-boi, I was wrong as usual. It was working, but I kept getting prompted for my password, but putting a config in my Home directory on my Host machine fixed that!

You also can do it like this:

ssh vagrant@127.0.0.1 -p 2222

Ports for a Vagrant instance are unique per instance; running one box will assign port 2222 to the SSH command, running a second box will detect the conflict and assign a different port (i.e. 2200) - this combined with the ssh-config command (which can be coupled with the box name) can add a lot of clarity to which box is being accessed, making the above method very usable.

That said, for reconnecting automatically you might want to at least manually set the SSH forwarding port...

thanks, really helpful!

Add new comment