Ssh – how to ssh into a vagrant box when working with multi-vagrant environments

Don't use a password. Generate a passphrase-less SSH key and push it to your VM.

If you already have an SSH key, you can skip this step… Just hit Enter for the key and both passphrases:

$ ssh-keygen -t rsa -b 2048
Generating public/private rsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_rsa.
Your public key has been saved in /home/username/.ssh/id_rsa.pub.

Copy your keys to the target server:

$ ssh-copy-id id@server
id@server's password:

Now try logging into the machine, with ssh 'id@server', and check-in:

.ssh/authorized_keys

Note: If you don't have .ssh dir and authorized_keys file, you need to create it first

to make sure we haven’t added extra keys that you weren’t expecting.

Finally, check to log in…

$ ssh id@server

id@server:~$

You may also want to look into using ssh-agent if you want to try keeping your keys protected with a passphrase.

The reason why you couldn't log in as vagrant any more is because you backed up /etc which contains shadow. Since the shadow file from linode doesn't contain an entry for the vagrant user, it won't allow you to login with that credentials. You could log in using your linode user because the credentials are in the /etc/shadow file, but the ssh daemon was using the default settings which allow password authentication for everyone. If everything was ok, you could just reload the ssh service to pick up the new configuration (the one from your backup that disables password authentication).

However something must have gone wrong during the restore. From the info provided, I can only make assumptions as to what, and I'd like to avoid that. However, if you open the virtualbox management window with the vagrant box shut down, you will be able to start the virtual machine normally. This will allow you to see any errors that are presented in the console. If no errors are present, it will at least allow you to log in using the console (as opposed to SSH). You can use your normal account to get access and look around to see what's wrong. Something in /var/log will point you towards the right direction (most probably /var/log/syslog).