Question

permission denied (publickey) using git from DigitalOcean console, Forge user

Posted May 14, 2020 1.4k views
NginxDigitalOceanUbuntu 18.04Laravel

My setup originates with Laravel Forge connecting to various GitHub repos. I’ve been running a dozen sites without issue for about 6 months. All of a sudden, yesterday I started getting this permission denied (publickey) error in the DigitalOcean Console when I run any git push or git pull command.

I’ve been through these articles:

They all recommend roughly the same solution:

  1. Edit config file sudo nano /etc/ssh/sshd_config
  2. Change PasswordAuthentication yes which I shouldn’t need to do since this is SSH, not password auth
  3. Change PublickeyAuthentication yes or in my case, uncomment it
  4. One article says to change AuthorizedHostKeys .ssh/authorized_keys
  5. Save, exit, and then run sudo service sshd reload

I’ve tried all these steps multiple times but I still can’t get reconnected to my git repositories.

I’ve also reviewed the Forge SSH Keys instructions and confirmed the server key provided is the correct server key in /home/forge/.ssh/authorized_keys

Any additional ideas for 2020? I’m running Ubuntu 18.04.3

These answers are provided by our Community. If you find them useful, show some love by clicking the heart. If you run into issues leave a comment, or add your own answer to help others.

×
2 answers

I was logged in as the root user accidentally, instead of my usual git user forge.

So mucked up my file permissions by trying to git add files, and once I got logged into the correct user, I had to reset my file permissions in the /.git/objects folder of my site(s) because they were owned by root.

This discussion answer was helpful.

Hi @fowlertown,

If I understand correctly, Laravel Forge is used like a central hub which pushes your Git project to different DigitalOcean Droplets, correct?

If that’s correct, then it seems for some reason the droplet isn’t accepting SSH connections via SSH keys. Let’s start troubleshooting. Firstly, can you see if you are able to SSH using your own terminal or if you are getting the same error?

Try to run the following command on the droplet and then connect from the computer/environment using the said key

/usr/sbin/sshd -d -p 2222

You should be able to connect and receive something like the following on your Droplet :

Authentication allowed

In this case, what you can do is temporarily stop the SSH daemon and replace it with one in debug mode. Don’t worry, stopping the SSH daemon won’t kill any existing connections. This means it’s possible to run this without being connected to the droplet’s Console but it’s somewhat risky. If the connection does get broken for any kind of reason, you’ll need to connect using your droplet’s console. Anyway, you can run the following

service ssh stop
/usr/sbin/sshd -d
#...debug output...
service ssh start

If it again runs with the debug mode being on, then for sure it’s the SELinux causing the issues, it’s most probably set to Enforcing. The .ssh dir will probably be mislabeled. Look at /var/log/audit/audit.log. Check with ls -laZ and then Run restorecon -r -v /path/to/users/.ssh.

Regards,
KDSys

  • Thanks for the thoughtful reply, KDSys, but I figured out my issue on my own this morning. I was logged in as the root user accidentally, instead of my usual git user. So mucked up my file permissions by trying to git add files. Once I got logged into the correct user, I had to reset my file permissions in the /.git/objects folder of my site(s) because they were owned by root.

Submit an Answer