preface

Previously, a gitlab server was built on Alibaba cloud student computers. Because gitlab already exists on the host and the environment has been messed up, it is not easy to install gitlab directly, so we have to run it in the docker container.

It is very convenient for gitlab to deploy docker container. You can use it by switching the port mapping of http and ssh. However, for a long time, ssh can't access the warehouse in gitlab. The basic reason is that the output is the following content, and the warehouse can't be found:

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I didn't use gitlab much before, so I didn't care about it. But I've been using gitlab recently. I remember that I still have a gitlab server. When I test it myself, I feel very unhappy every time I don't have ssh. So I search the Internet. There are many similar problems, but the data doesn't work. From gitlab configuration to ssh configuration to docker configuration, and even some related bug issues mentioned on github are useless.

I was going to give up.

1, Cause

There is no way to burn a goose. When I checked the configuration for the last time and was ready to quit and give up, Yu Guang scanned the logs directory of gitlab... Stunned, and then decisively opened the sshd log file (logs/sshd/current file, see your docker directory mount point, if not, access the file in the docker container):

> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> @         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
> Permissions 0777 for '/etc/gitlab/ssh_host_xxxx_key' are too open.
> It is required that your private key files are NOT accessible by others.
> This private key will be ignored.
> key_load_private: bad permissions
> Could not load host key: /etc/gitlab/ssh_host_xxxx_key

Then he was stunned, and then suddenly realized that it had been ssh for a long time. Every time he loaded the server secret key, he found that the private key file was too unsafe and refused to use it. He ignored it directly, resulting in errors in every ssh access==

2, Settle

1. First check the configuration directory of gitlab (see your docker directory mount point. If not, enter the docker container for operation):

   > -rwxrwxrwx 1 root root 111987 May 17 11:57 gitlab.rb
   > -rw------- 1 root root  18888 May 17 13:48 gitlab-secrets.json
   > -rwxrwxrwx 1 root root    227 Sep 30  2020 ssh_host_ecdsa_key
   > -rwxrwxrwx 1 root root    179 Sep 30  2020 ssh_host_ecdsa_key.pub
   > -rwxrwxrwx 1 root root    411 Sep 30  2020 ssh_host_ed25519_key
   > -rwxrwxrwx 1 root root     99 Sep 30  2020 ssh_host_ed25519_key.pub
   > -rwxrwxrwx 1 root root   1679 Sep 30  2020 ssh_host_rsa_key
   > -rwxrwxrwx 1 root root    399 Sep 30  2020 ssh_host_rsa_key.pub
   > drwxr-xr-x 2 root root   4096 Sep 30  2020 trusted-certs
   
   

2. SSH secret key has three encryption algorithms, which correspond to the private key file ssh_host_ecdsa_key,ssh_host_ed25519_key,ssh_host_rsa_key. RSA algorithm is commonly used in SSH. If you find that there is a problem with the permission of the above private key file, your situation is the same as mine.

3. In case of finding the above situation, modify the authority decisively:

   chmod 700 ssh_host_ecdsa_key # Permission is set so that only the owner can access, and other team members and other users cannot access
   chmod 700 ssh_host_ed25519_key
   chmod 700 ssh_host_rsa_key
   

3, Everyone is happy

After modifying the permissions, you can directly re git access ssh and accept the remote server authentication. You can finish it at one go and have a smooth journey. You don't need to enter passwords in clone, pull and push anymore.
Check the ssh log later:

2021-05-17_06:23:21.86719 Accepted publickey for git from xxipxx port 19304 ssh2: RSA SHA256:xxxhashxx
2021-05-17_06:23:22.89831 Received disconnect from xxipxx port 19304:11: disconnected by user
2021-05-17_06:23:22.89834 Disconnected from xxipxx port 19304

You can see that the ssh access process just now is normal, Over