WSL is just Linux, so you’d load them the same way you’d normally load SSH keys in Linux:
ssh-add /path/to/your/key
You may need to adjust the permissions on your keys if they’re in the Windows filesystem (ssh-agent won’t want to load them if the permissions are too…permissive). If your SSH private key isn’t in the correct format (i.e. you created it in Windows w/ puttygen) you’ll need to convert it to OpenSSH (I think) which can be done with puttygen.
Still no luck…
I’ve added SSH keys to WSL as described by @alwaysblank but I’m receiving the same ‘unreachable’ error.
I might have found a clue though… If I add this line to trellis/group_vars/staging/main:
web_user: root
Then I can deploy! This is weird because my Mac-based associate doesn’t have to do this.
But now I’ve got a new errors anyway:
RUNNING ansible-playbook deploy.yml -e “site=example.com env=staging” FROM WSL
FAILED! => {"changed": false, "stdout": "Do not run Composer as root/super user! See https://getcomposer.org/root for details\nLoading composer repositories with package information\nInstalling dependencies from lock file\n
RUNNING ansible-playbook deploy.yml -e “site=example.com env=staging” FROM SSH VAGRANT
MODULE FAILURE
See stdout/stderr for the exact error
Traceback (most recent call last):
File "<stdin>", line 113, in <module>
File "<stdin>", line 105, in _ansiballz_main
File "<stdin>", line 48, in invoke_module
File "/tmp/ansible_command_payload_BD1IuR/__main__.py", line 286, in
<module>
File "/tmp/ansible_command_payload_BD1IuR/__main__.py", line 226, in main
OSError: [Errno 2] No such file or directory:
'/srv/www/example.com/current/web/app/themes/example'
An exception occurred during task execution. To see the full traceback, use -vvv. The error was: OSError: [Errno 2] No such file or directory: '/srv/www/example.com/current/web/app/themes/example'
fatal: [xxx.xxx.xxx.xxx-> localhost]: FAILED! => {"changed": false, "module_stdout": "", "rc": 1}
Frustrating!
Take this with a grain of salt because Trellis isn’t really my wheelhouse, but it sounds (?) like the SSH key you’re using locally is associated w/ the root user on your remote server, instead of the web user. Your Mac associate’s key is probably correctly associated w/ web, hence the different behavior. I’d take a look in trellis/group_vars/all/users.yaml to see how the section with name: {{ web_user }} is set up w/r/t SSH keys. You should make sure your SSH public key has been provision with the correct user. If it’s not, you may need to fix it and re-provision.
That sounds about right. I’ll see if I can get my associate to try some reprovisions.
Thanks again for all of your help.
Just to update…
My colleague added my keys in to users.yml and re-provisioned. We had this done before but the trellis configs never got committed to git so they were lost.
Anyway, now we both get the same error message:
Git repo git@github.com:xxxx/yyyy.git cannot be accessed. Please
verify the repository exists and you have SSH forwarding set up correctly.
My colleague never had this issue when deploying before and it’s only occurring now that we’ve added my github public keys back into users.yml:
users:
- name: "{{ web_user }}"
groups:
- "{{ web_group }}"
keys:
- "{{ lookup('file', '~/.ssh/id_rsa.pub') }}"
- https://github.com/stuartcusackie.keys
Back to the drawing board… We might be one step closer though now that we can see the same error.
Just for the sake of ruling things out: can you confirm the branch listed inwordpress_sites.yml exists on the remote repo? I’ve seen people with this issue before and that was their issue.
I double checked and It does indeed exist. Thanks for the thought.
Why use Vagrant? FWIW all of our docs say to use WSL now, and you can just run the deploy from WSL in the Trellis directory instead of trying to do it from Vagrant.
I’ve been alternating between WSL and vagrant while troubleshooting these deploys. I’ve gotten to the stage where they both produce the same error message:
“Git repo cannot be accessed”
I have confirmed the following:
My WSL ~/.ssh/config file looks like so:
Host *servername*
ForwardAgent yes
Hostname *serverip*
User root
All out of ideas.
I’m not sure what to tell you, but this sounds too complicated. I’ve been running deploys in WSL all week, and all I’ve done is this:
ssh-add ~/.ssh/my-key-file (ssh-agent needs to be running already of course).trellis/group_vars/all/users.yml looks like this:admin_user: admin
users:
-
name: '{{ web_user }}'
groups:
- '{{ web_group }}'
keys:
- '{{ lookup(''file'', ''~/.ssh/id_rsa.pub'') }}'
- 'https://github.com/my-username.keys'
-
name: '{{ admin_user }}'
groups:
- sudo
keys:
- '{{ lookup(''file'', ''~/.ssh/id_rsa.pub'') }}'
- 'https://github.com/my-username.keys'
web_user: web
web_group: www-data
web_sudoers:
- '/usr/sbin/service php7.3-fpm *'
ansible-playbook deploy.yml -e env=staging -e site=site.com
No SSH config stuff, no changing to root.
How was your server originally provisioned?
Well I am another step further! But now I have new problem. The deploy works all the way past ‘Compiling assets / Copying production assets’ and then:
"Ansible: could not locate file in lookup: ~/.ssh/id_rsa.pub"
The file definitely exists in both my windows users folder and in my WSL installation folder /home/username/.ssh/id_rsa.pub
The servers were originally configured by a Mac user who didn’t have any experience with this kind of thing so it’s probable that something was missed. He has no trouble deploying though, They are Digital Ocean servers by the way.
My other issue was something stupid. I copied and pasted the ssh-add command from a WSL forum and it had a ‘-k’ flag in it.
I was running:
ssh-add -k ~/.ssh/id_rsa
When I should have been running:
ssh-add ~/.ssh/id_rsa
Doh!
Thanks for all the help!!!
What is the name of the Trellis task that fails with the “could not locate file in lookup” error?
“Copy production assets”
Any clues there?
Have you looked in the Trellis roles directory to see what that task is doing that requires your SSH key?
The only reference I see to “copy production assets” is in ‘deploy_hooks/build-before.yml’
Solved below…
Solved another piece of the puzzle.
My id_rsa.pub had only Windows permissions associated with it as I foolishly copied and pasted my Windows SSH keys to my Ubuntu WSL install to “save” time.
So the last problem was fixed by assigning permissions to the public key file:
chmod 755 ~/.ssh/id_rsa.pub
I already had done this to the private key file:
chmod 600 ~/.ssh/id_rsa
Onto the next problem:
OSError: [Errno 13] Permission denied: '/srv/www/*website.com*/releases/20190327175156/CHANGELOG.md
Looks like I can delete all the broken old releases from failed deploys on the remote server to fix this. I’ve kept the most recent five.
I DID IT!!! I CAN DEPLOY!! 
UPDATE - SPOKE TOO SOON
Well it worked twice and now it’s gone back to:
Git repo git@github.com:*username*/*reponame*.git cannot be accessed.
This makes no sense to me. How did it work twice?
ANOTHER UPDATE
I got it working by setting up a fresh server on Digital Ocean. Hopefully it continues to work…
