0

Context:

A new Gitlab server instance was deployed from an AMI backup. When trying to re-establish connectivity to it from a development server, issuing a git pull command presented me with a password prompt.

user@devserver:/var/www/html/sites/project (develop)$ git pull

[email protected]'s password:

Troubleshooting:

When attempting git pull from dev server and tailing /var/log/auth.log on Gitlab server, I get this error message:

Authentication refused: bad ownership or modes for directory /var/opt/gitlab

I then adjusting server /etc/ssh/sshd_config file and modified StrictModes yes to StrictModes no realizing this must be related to SSH key issue or permissions of .ssh folder files and that StrictMode no would allow my user's keys to pass strict mode. https://ubuntuforums.org/showthread.php?t=831372

Issued /etc/init.d/ssh reload, re-attempted git pull. This time it worked and /var/log/auth.log showed the following: 

sshd[15283]:Accepted publickey for git from 52.X.X.X port 62002 ssh2:RSA

and git pull showing 

user@devserver:/var/www/html/sites/project (develop)$ git pull
Already up-to-date.

Now to verify permission settings on .ssh folder and files (even though they haven't been changed and were working previously)

Correct file permissions for ssh keys and config. 

chmod 700 ~/.ssh
chmod 644 ~/.ssh/authorized_keys
chmod 644 ~/.ssh/known_hosts
chmod 644 ~/.ssh/config
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

I reverted to StrictModes yes and reloaded ssh config settings, git pull and same issue.

Authentication refused: bad ownership or modes for directory /var/opt/gitlab

Common replies: 

Have you tried rekeying SSH keys and adding them to Gitlab SSH user settings?

yes -> Setting up SSH keys for Gitlab

Have you tried rebuilding authorizated_keys file?

yes -> Rebuilding authorized_keys file

Can anyone provide insight as to why git pull not working when StrictMode yes is set after deploying a new Gitlab server from AMI?

I really appreciate anyone whose spent the time read my issue and provide feedback/answers! Hopefully someone out there has encountered this...

Improve this question

1 Answer 1

Reset to default
0

I found the issue after spending all day digging for answers. Seems like the after the relaunch of the server the permissions on the /var/opt/gitlab were had writable on for group permissions. This conflicts with StrictModes yes

StrictModes - Specifies whether sshd should check file modes and ownership of the user's files and home directory before accepting login. This is normally desirable in case users inadvertently leave their directory or files world-writable. The default is "yes". Specifically, StrictModes checks that the following files, directories, and component path names are owned by the current user or superuser and that they are not group or world-writable. Reference found here

After issuing chmod 755 /var/opt/gitlab(removing write permissions), the issue is now resolved.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .