Permission denied (publickey,password) when trying to deploy

[fatonsopa]

I'm trying to deploy a project on an Nginx server.

1. We have added SSH key to ~/.ssh/authorized_keys
2. We are using 'root' user to deploy, and we have full root permission to the deploying server
3. We can connect to Server via "Test server connection"
4. I tried to login to server via ssh (using via ssh-copy-id) and I was able to create/modify directories and create symlinks
5. shared directories are being uploaded
6. 'releases' directory is empty
7. there is no 'latest' directory
8. I see a temporary file being created while cloning is empty, then when composer installed is finished that tmp file is gone

Expected behaviour

Upload releases and setup /latest symlink

Please describe what you're expecting to see happen.
Completed

Actual behavior

On release step, we are getting
production.ERROR: Permission denied (publickey,password).

Environment info

Laravel Environment

• Laravel Version: 5.4.36
• Timezone: Europe/Berlin
• Debug Mode: ✘
• Storage Dir Writable: ✔
• Cache Dir Writable: ✘
• Decomposer Version: ^1.0
• App Size: 205 MB

Server Environment

• PHP Version: 7.1.17-1+020180505045738.17+stretch1.gbpde69c6
• Server Software: Apache/2.4.25 (Debian)
• Server OS: Linux anakonda 4.9.0-6-amd64 Route models #1 SMP Debian 4.9.82-1+deb9u3 (2018-03-02) x86_64
• Database: mysql
• SSL Installed: ✘
• Cache Driver: file
• Session Driver: file
• Openssl Ext: ✔
• PDO Ext: ✔
• Mbstring Ext: ✔
• Tokenizer Ext: ✔
• XML Ext: ✔
• Curl Ext: ✔
• GD Ext: ✔
• JSON Ext: ✔

Installed Packages & their version numbers

• andywer/js-localization : dev-laravel-5
• backup-manager/laravel : ^1.1
• creativeorange/gravatar : ~1.0
• cweagans/composer-patches : ^1.6
• doctrine/dbal : ~2.5
• fideloper/proxy : ^3.1
• graham-campbell/binput : ~3.3
• htmlmin/htmlmin : ~4.5
• guzzlehttp/guzzle : ^6.2
• intervention/image : ^2.3
• laracademy/interactive-make : ^1.1
• laravel-notification-channels/hipchat : ~0.2
• laravel-notification-channels/twilio : ~1.0.2
• laravel-notification-channels/webhook : ~1.0.2
• laravel/framework : ^5.4
• laravel/tinker : 1.0.*
• lubusin/laravel-decomposer : ^1.0
• mccool/laravel-auto-presenter : ^5.0
• melihovv/laravel-log-viewer : ^1.2
• michele-angioni/multi-language : 0.3
• pda/pheanstalk : ~3.1
• pragmarx/google2fa : ^1.0.0
• predis/predis : ~1.0
• tymon/jwt-auth : ~0.5
• rebelinblue/laravel5-zxcvbn : dev-master
• version/version : ^2.2

Extra Information

• proc_open enabled : ✔

• Operating System: Ubuntu

• PHP Version: 7.1.12

• Node Version:

• Database System:

• Database Version: 5.7

Logs (see storage/logs/) or other output that would be helpful

(If logs are large, please upload as attachment).

latest log
[2018-05-18 14:24:15] production.ERROR: Permission denied (publickey,password).

yesterday log:
cli-2018-05-17.log

[REBELinBLUE]

It isn't SSHing into the server which is getting permission denied, it is cloning the repository

[2018-05-17 14:26:18] production.ERROR: Permission denied (publickey,password).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
error: Could not fetch origin

You need to add the SSH key to the deploy keys for your repository, how you do that depends on where the repository is hosted

https://docs.gitlab.com/ee/ssh/
https://help.github.com/articles/connecting-to-github-with-ssh/
https://confluence.atlassian.com/bitbucket/set-up-an-ssh-key-728138079.html#SetupanSSHkey-Step4.AddthepublickeytoyourBitbucketsettings

[fatonsopa]

It looks like the repository is cloning as it should (a tmp .tar.gz is created then deleted after the process fails)

I have added the SSH key from deployer to my gitlab account and the same ssh key to ~/authorized_keys on the destination server. Do I have to add it somewhere else too?

Thanks,

[REBELinBLUE]

Can you run artisan app:debug then try again and share the latest log file

[fatonsopa]

It turn out to be a server permission issue!

Feel free to close the issue.

Thanks (and sorry for the delay)

[REBELinBLUE]

Oh? What was the issue?

[fatonsopa]

There was another company managing the server on behalf of our client. As far as I am informed, they didn't give proper user/group permissions to directories where the clone had to be deployed.