Roots Discourse

Vagrant ssh Permission denied (publickey)

I know there are at least a dozen Permission denied (publickey). posts up here and I’ve looked at them all.

I cannot seem to get vagrant ssh to work on the dev box all of a sudden. OK not completely all of a sudden. First I was seeing this error in the admin panel:

Warning: An unexpected error occurred. Something may be wrong with WordPress.org or this server...

So I tried to reload the server. Then vagrant up was failing with the error:

A VirtualBox machine with the name 'blablabla.dev' already exists. Please use another name or delete the machine with the existing name, and try again.

The solution to which I’ll spare you.

Now I can’t run vagrant provision or even vagrant ssh.

I have read through this post, performing the following command:

ssh-add -K ~/.ssh/id_rsa.pub

And $ ssh-add -l shows:

2048 73:bd:f2:ca:1f:f3:7f:01:6e:58:03:39:51:a3:df:0d /Users/me/.ssh/id_rsa (RSA).

I even went into the virtual box via the GUI and manually changed permissions on authorized_keys and ~/.ssh to 600 and 700 respectively. I can see that authorized_keys contains an ssh-rsa key for user vagrant.

Aside from destroying and re-provisioning the dev server, can anyone make a recommendation on a good next step. I think this learning experience has been just about as educational as I’d like for the moment.

Did you try nuking ~/.ssh/known_hosts?

1 Like

On the host machine? I just did that. Trying vagrant reload now. This is what I should expect to see, correct?

default: SSH address: 127.0.0.1:2222 default: SSH username: vagrant default: SSH auth method: private key

This is the distressing part:

default: Warning: Authentication failure. Retrying... default: Warning: Authentication failure. Retrying... default: Warning: Authentication failure. Retrying... default: Warning: Authentication failure. Retrying... default: Warning: Authentication failure. Retrying... default: Warning: Authentication failure. Retrying...

Which I have seen before and sometimes goes away. But not today.

What about manually clearing the host entries in /etc/hosts for the problem vm hostname?

Are you able to spin up a new vm using a different hostname?

One thing I noticed is that there were duplicate entries for this box. Deleted both and running vagrant reload --provision.

default: Warning: Authentication failure. Retrying...

I’m not exactly sure what you mean by spin up a new box using a different hostname.

Also Vagrant doesn’t seem to be creating new entries in the hosts file. I know I have ended up doing that manually before with other Ansible scripts (because I’m seeing a note to that effect in the hosts file).

I’m not exactly sure what you mean by spin up a new box using a different hostname.

I mean instead of using hostname-thats-been-giving-you-problems.dev try new-unused-hostname.dev for an entirely new vm and just see if it works, so you can isolate the issue to this specific vm or your local environment.

Make sure all local dependencies are installed correctly.

OK. Thank you for all your help, by the way. If you meant to change host_vars/development/wordpress_sites.yml from:

wordpress_sites: hostname-thats-been-giving-you-problems.dev: site_hosts: - hostname-thats-been-giving-you-problems.dev

to

wordpress_sites: new-unused-hostname.dev: site_hosts: - new-unused-hostname.dev

And run vagrant up --provision, the result is the same.

I can run vagrant up on other Vagrant files on my system without ssh authentication errors:

default: SSH auth method: private key default: default: Vagrant insecure key detected. Vagrant will automatically replace

(Not a trellis instance).

Actually though, the one I just ran seems to have created a new VM in VirtualBox, which was the error I was getting with this Trellis instance earlier.

I don’t just mean changing the site key, I mean try a new dir, clone Trellis/Bedrock and create a completely new project with a new dev hostname and see if you can just get $ vagrant up working so you can isolate the problem. It could be something with your old box or some filesystem remnants in your working dir. But it could also be something system wide; we need to isolate it and then try to figure out how it can be reproduced. If you can start a whole new project in a completely unrelated dir with a new hostname then we know your system is most likely ok and the issue is local (i.e. with that specific vm/project).

Looks like it’s with this specific project, as the new box is flying happily past the ssh authorization:

default: SSH auth method: private key default: default: Vagrant insecure key detected. Vagrant will automatically replace

The only file change I’ve made, aside from to the theme, is in the Composer file, so I’m thinking it must be something with the hostname, hosts file, .ssh directory or vagrant box itself.

I’m definitely leaning towards vagrant destroy at this point, but would love to solve this by figuring out the issue if possible.

I’m not sure if this is relevant, but when I log into the troublesome server through VirtualBox, the /srv/www/troublesome.dev/current directory is empty.

If vagrant destroy is an option and won’t cost you a ton of time or money then that’s likely your best bet. You could backup your themes/ and uploads/ directories and your database file then after you destroy the vm nuke the entire dir and your hosts file to clear out any remnants, then start over and restore your content from your backups.

I’m not sure how best to backup the database. Is there a way other than running mysqldump from within the server?

Ahh right, you can’t get the vm up at all. Hrmm, not sure off the top of my head. I don’t think the vm’s db is directly accessible from your file system but you might be able to find some way around that… or perhaps you have a staging/production db you can use?

I was able to go into the server through the VirtualBox GUI using username and password vagrant:vagrant, then logged into mysql using the credentials root and vault_mysql_root_password contained in host_vars/development/vault.yml:

mysql -uroot -p

Then within MySql: list databases;. Leave mysql by pressing CTRL-C (I think) and then:

mysqldump -uroot -p name_of_database_you_recognized_in_above_command > database_backup.sql

Then I went back to my computer (having to use Option + Command + Escape to get out of the VirtualBox VM window) and got my local IP address. You can just google IP address. I used ifconfig | grep "inet " | grep -v 127.0.0.1 | awk '{print $2}' so I could feel cool. Now back to the VM:

rsync -avP database_backup.sql mikekilmer@my-ip-address:Documents/

And it’s now in ~/Documents.

Unfortunately now I’m getting failed provisioning on Wordpress Install.

failed: [default] (item={'value': {u'multisite': {u'enabled': False}, u'cache': {u'enabled': False}, u'ssl': {u'enabled': False, u'provider': u'self-signed'}, u'local_path': u'../site', u'site_hosts': [u'blablabla.dev'], u'admin_email': u'mike@mzoo.org'}, 'key': u'blablabla.dev'}) => {"changed": true, "cmd": ["composer", "install"], "delta": "0:00:00.101408", "end": "2016-07-13 12:44:20.743464", "failed": true, "item": {"key": "blablabla.dev", "value": {"admin_email": "mike@mzoo.org", "cache": {"enabled": false}, "local_path": "../site", "multisite": {"enabled": false}, "site_hosts": ["blablabla.dev"], "ssl": {"enabled": false, "provider": "self-signed"}}}, "rc": 1, "start": "2016-07-13 12:44:20.642056", "stderr": "You are running composer with xdebug enabled. This has a major impact on runtime performance. See https://getcomposer.org/xdebug\nRunning composer as root/super user is highly discouraged as packages, plugins and scripts cannot always be trusted\nComposer could not find a composer.json file in /srv/www/blablabla.dev/current\nTo initialize a project, please create a composer.json file as described in the https://getcomposer.org/ \"Getting Started\" section", "stdout": "", "stdout_lines": [], "warnings": []}
I was hoping to avoid “nuke the entire dir and your hosts file”, but that may end up being necessary. Which directory are you actually referring to, just Trellis, Trellis and Bedrock or something else? I would think either way I would keep the host_vars/production directory which is hopefully still working.

Hmmm. I just vagrant sshd and manually copied the Bedrock composer.json file to /srv/www/blablabla.dev/current. Re-provisioning now…

TASK [wordpress-install : Install WP]
“Error: This does not seem to be a WordPress install. .\nPass --path=path/to/wordpress or run `wp core download”

Maybe I need to run wp core download manually in the VM?

Doesn’t seem like the ideal solution. I’m not exactly sure what the path/to/wordpress is…

Did you recently update Vagrant or Ansible? Perhaps to an unsupported version? Also possible a VirtualBox update could be the culprit.

Ah I think during this P R O C E S S I may have…

Yup. Had upgraded to 1.8.4. Removed and reinstalling from archive.

NOTE: Confirm you have actually DOWNGRADED by running vagrant version, as noted below.

Ansible version is 2.0.2.0.

Re-provisioning failed. Trying destroy and vagrant up again.

Same error no composer file found:

Composer could not find a composer.json file in /srv/www/blablabla.dev/current\nTo initialize a project, please create a composer.json file as described in the https://getcomposer.org/ \"Getting Started\" section", "stdout": "", "stdout_lines": [], "warnings": []}

NO MORE HOSTS LEFT *************************************************************

Looking into solutions here.

Trying vagrant plugin install vagrant-hostsupdater.

Current approach is I renamed my trellis directory to my_trellis and replaced it with a fresh clone of trellis.

Then moved the group_vars in the new trellis clone to upstream_group_vars (or something).

I copied (cp -r ../my_trellis/group_vars) my original group_vars file to the new clone.

I REMOVED the previous VM via the VirtualBox GUI (which I believe is just about the same as running vagrant destroy) and removed any references to it from the /etc/hosts file and ran vagrant up.

After getting a “ERROR! Decryption failed” error on vagrant provision, I copied two more files from my_trellis: .vault_pass and ansible.cfg.

Ended up back at Composer could not find a composer.json file in /srv/www/blablabla.dev error, BUT this time noticed that even thought I had uninstalled Vagrant 1.8.4 and installed the 1.8.1 version from the downloaded disc image, vagrant version was still returning 1.8.4.

  1. ran the three uninstall commands again
  2. restarted the computer
  3. removed the disc image for Vagrant 1.8.4 from downloads folder
  4. ran the Uninstall script that is included with the 1.8.1 Vagrant download.
  5. Installed from the Vagrant disc

Now vagrant version returns 1.8.1.