Virtualbox VMs powered by Vagrant require authentication via SSH keys so you don’t have to provide a password each time
vagrant up is doing its magic. Provisioning tools you run as part of the
vagrant up command also rely on the SSH key based authentication to work properly. This is documented in the official Vagrant documentation set.
I don’t want to use unknown SSH keys with my own Vagrant boxes as a matter of principle. Whenever I create a new custom box I resort to a dedicated SSH key I’m using just for this purpose. This avoids the trouble with Vagrant’s “insecure key pair”, all I need to do is add
config.ssh.private_key_path = "/path/to/key" to the Vagrantfile.
The documentation further reads I have to use a NAT device as the first network card in the VM. For some of my VMs I define an additional NIC using a host-only, private network for communication between say for example middle tier and database layer. I don’t want to mess around with port forwarding to enable communication between my VMs, and Vagrant makes it super easy to define another NIC.
This sounds interesting, but what does that have to do with this post?
Please bear with me, I’m building up a story ;) It will all make sense in a minute…
Connecting to the VM’s second interface
With all that in place it’s easy to SSH into my Vagrant box. Assume I have a Vagrant VM with an IP address of 192.168.56.202 to which I want to connect via SSH. Remember when I said I have a dedicated SSH key for my Vagrant boxes? The SSH key is stored in
~/.ssh/vagrant. The SSH command to connect to the environment is simple:
$ ssh -i ~/.ssh/vagrant email@example.com
… and this connects me without having to provide a password.
Saving time for the lazy
Providing the path to the SSH key to use gets a little tedious after a while. There are a couple of solutions to this; there might be more, but I only know about these two:
- Create a configuration in
~/.ssh/configExcept that doesn’t work particularly well with keys for which you defined a passphrase as you now have to enter the passphrase each time
- Add the key to the SSH agent
On Linux and MacOS I prefer the second method, especially since I’m relying on passphrases quite heavily. Recently I encountered a problem with this approach, though. When trying to connect to the VM, I received the following error message:
$ ssh firstname.lastname@example.org Received disconnect from 126.96.36.199 port 22:2: Too many authentication failures Disconnected from 188.8.131.52 port 22
What’s that all about? I am sure I have the necessary key added to the agent:
$ ssh-add -l | grep -c vagrant 1
Well it turns out that if you have too many non-matching keys, you can run into the pre-authentication problem like I did. The first step in troubleshooting SSH connections (at least to me) is to enable the verbose option:
$ ssh -v email@example.com [ ... more detail ... ] debug1: Will attempt key: key1 ... redacted ... agent debug1: Will attempt key: key10 ... redacted ... agent debug1: Will attempt key: key2 ... redacted ... agent debug1: Will attempt key: key3 ... redacted ... agent debug1: Will attempt key: key4 ... redacted ... agent debug1: Will attempt key: key5 ... redacted ... agent debug1: Will attempt key: key6 ... redacted ... agent debug1: Will attempt key: key7 ... redacted ... agent debug1: Will attempt key: key8 ... redacted ... agent debug1: Will attempt key: key9 ... redacted ... agent [ ... ] debug1: Next authentication method: publickey debug1: Offering public key: key1 ... redacted ... agent debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password [...] debug1: Offering public key: key5 ... redacted ... agent debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password Received disconnect from 184.108.40.206 port 22:2: Too many authentication failures Disconnected from 220.127.116.11 port 22
It is my understanding that SSH is querying the agent for SSH keys, and it receives them. After trying key1 through key5 and not finding a match, it decides to stop and returns said error message.
There are quite a few keys currently added to my running agent:
$ ssh-add -l | wc -l 11
The solution is quite straight forward: I need to store keys with the agent, but I have to indicate which of the stored keys to log in to my VM. This is probably best done in
$ cat ~/.ssh/config 192.168.56.202 IdentityFile ~/.ssh/vagrant
In summary, I’m now using a combination of the 2 approaches I outlined above to great effect: now I can log in without having to worry about the keys stored by my agent, and the order in which they are stored.