Gitlab Plugin - Registered SSH keys not accepted

Xeonian

Dabbler
Joined
May 15, 2019
Messages
10
I recently installed the Gitlab plugin to my Freenas server. The installation went smoothly, and I was able to interact with projects using username and password-based authentication. However, after adding an SSH key for my user, I found that I was not able to communicate with the server. A sample client-side SSH command using the private key whose public pair is shown as registered in the Gitlab web UI is as follows:

Wes@DESKTOP-CMPA99A MINGW64 ~
$ ssh -Tv git@192.168.0.50
OpenSSH_7.1p2, OpenSSL 1.0.2h 3 May 2016
debug1: Reading configuration data /c/Users/Wes/.ssh/config
debug1: /c/Users/Wes/.ssh/config line 1: Applying options for 192.168.0.50
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to 192.168.0.50 [192.168.0.50] port 22.
debug1: Connection established.
debug1: identity file C:/Users/Wes/.ssh/id_ed25519 type 4
debug1: key_load_public: No such file or directory
debug1: identity file C:/Users/Wes/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5 FreeBSD-20170903
debug1: match: OpenSSH_7.5 FreeBSD-20170903 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.0.50:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client chacha20-poly1305@openssh.com <implicit> none
debug1: kex: client->server chacha20-poly1305@openssh.com <implicit> none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:D5h0p2cG+4CrIay6Ubr09juwtfoMAJmCBlUHs23RHIg
debug1: Host '192.168.0.50' is known and matches the ECDSA host key.
debug1: Found key in /c/Users/Wes/.ssh/known_hosts:1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering ED25519 public key: C:/Users/Wes/.ssh/id_ed25519
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: No more authentication methods to try.
Permission denied (publickey,keyboard-interactive).

On the server side, in /var/log/auth.log, each attempt produces the following sequence:

May 15 21:25:36 gitlab sshd[62245]: user git login class [preauth]
May 15 21:25:36 gitlab sshd[62245]: user git login class [preauth]
May 15 21:25:36 gitlab sshd[62245]: Connection closed by authenticating user git 192.168.0.27 port 56635 [preauth]

When investigating the problem, I first discovered this bug report which suggested that the git user may be locked, but this was not the case on my installation. I then saw these two posts [1] [2] which both suggest that the problem may lie with the configuration of the home directory for the user. The plugin post install script appears to set the home directory of the git user to /usr/home/git, as well as creating a .ssh directory for the user - however, on my machine, this directory did not exist, although it did appear to be set as the git user's home directory in the master passwords file. I therefore presumed that problem lied in Gitlab being unable to add entries to the .ssh/authorized_keys file to inform sshd that the added keys are acceptable. I've manually introduced those directories and files, ensure they are owned by the git user and group, and both restarted the Gitlab and SSHD services, as well as rebooting the plugin jail and rerunning the entire post install script, to no avail.

I presume that either the failure to initialize the directory in the first instance has resulted in some misconfiguration in Gitlab, such that it's not correctly updating the ssh configuration when new keys are added, or that I'm misunderstanding the the issue entirely.

Has anyone encountered similar problems, or have any suggestions for what I may want to investigate next?
 

nojohnny101

Wizard
Joined
Dec 3, 2015
Messages
1,478
Just a thought, have you verified permission on the .ssh directories on both machines? Depending on SSH settings, this can cause errors when permissions are too lax, and SSH doesn't always tell you that is the reason.
 

Xeonian

Dabbler
Joined
May 15, 2019
Messages
10
As far as I can tell they're all correct. On the server side, the git user's home directory is set as /usr/home/git, which is what the post install script assigns anyway. The path to /usr/home is owned by root:wheel and has permissions 755, so should be accessible, while everything from the git directory down is owned by git:git. I've set the /usr/home/git/.ssh directory to permissions 700, and the /usr/home/git/.ssh/authorized_keys to 600.

On my client machine (running Windows 10), using Git Bash, my key files show as having permissions 644, and aren't changed in response to a chmod command. I've just followed these instructions to ensure that the permissions on the private key are restricted, but it hasn't had any impact. I've also grabbed the key I had previously used from within the Linux subsystem for Windows for other Gitlab deployments and registered that with my installation. The private part of the key has permissions 600. Testing that configuration gives very similar results:

wmarsh@DESKTOP-CMPA99A:~/.ssh$ ssh -Tv git@192.168.0.50
OpenSSH_7.2p2 Ubuntu-4ubuntu2.4, OpenSSL 1.0.2g 1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.168.0.50 [192.168.0.50] port 22.
debug1: Connection established.
debug1: identity file /home/wmarsh/.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /home/wmarsh/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/wmarsh/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/wmarsh/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/wmarsh/.ssh/id_ecdsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/wmarsh/.ssh/id_ecdsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/wmarsh/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/wmarsh/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.5 FreeBSD-20170903
debug1: match: OpenSSH_7.5 FreeBSD-20170903 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 192.168.0.50:22 as 'git'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:D5h0p2cG+4CrIay6Ubr09juwtfoMAJmCBlUHs23RHIg
debug1: Host '192.168.0.50' is known and matches the ECDSA host key.
debug1: Found key in /home/wmarsh/.ssh/known_hosts:4
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/wmarsh/.ssh/id_rsa
debug1: Authentications that can continue: publickey,keyboard-interactive
debug1: Trying private key: /home/wmarsh/.ssh/id_dsa
debug1: Trying private key: /home/wmarsh/.ssh/id_ecdsa
debug1: Trying private key: /home/wmarsh/.ssh/id_ed25519
debug1: Next authentication method: keyboard-interactive
Password for git@gitlab:
 

Xeonian

Dabbler
Joined
May 15, 2019
Messages
10
Ok, I think I've gotten to the bottom of it. I looked into rebuilding the authorized_keys file on the server side. Running the command gave the following result:

root@gitlab:/usr/local/www/gitlab-ce # sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production
W, [2019-05-17T21:01:09.973761 #56925] WARN -- : Please set prometheus_multiproc_dir to persistent directory path. Temporarily writing mmap files to /tmp/prometheus-mmap20190517-56925-1hcxv1w
This task will now rebuild the authorized_keys file.
You will lose any data stored in the authorized_keys file.
Do you want to continue (yes/no)? yes

rake aborted!
Errno::ENOENT: No such file or directory @ rb_sysopen - /usr/local/git/.ssh/authorized_keys
/usr/local/www/gitlab-ce/lib/gitlab/authorized_keys.rb:117:in `initialize'
/usr/local/www/gitlab-ce/lib/gitlab/authorized_keys.rb:117:in `open'
/usr/local/www/gitlab-ce/lib/gitlab/authorized_keys.rb:117:in `open_authorized_keys_file'
/usr/local/www/gitlab-ce/lib/gitlab/authorized_keys.rb:79:in `clear'
/usr/local/www/gitlab-ce/lib/gitlab/shell.rb:228:in `remove_all_keys'
/usr/local/www/gitlab-ce/lib/tasks/gitlab/shell.rake:104:in `setup'
/usr/local/www/gitlab-ce/lib/tasks/gitlab/shell.rake:62:in `block (3 levels) in <top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tasks: TOP => gitlab:shell:setup
(See full trace by running task with --trace)

Investigating, there was no .ssh directory under /usr/local/git. I created the .ssh directory and an empty authorized_keys file, configured the ownership and permissions as appropriate, and reran the rake command with the following result:

root@gitlab:/usr/local/www/gitlab-ce # sudo -u git -H bundle exec rake gitlab:shell:setup RAILS_ENV=production
W, [2019-05-17T21:04:34.475852 #59652] WARN -- : Please set prometheus_multiproc_dir to persistent directory path. Temporarily writing mmap files to /tmp/prometheus-mmap20190517-59652-qs5g1b
This task will now rebuild the authorized_keys file.
You will lose any data stored in the authorized_keys file.
Do you want to continue (yes/no)? yes

This populated authorized_keys with the keys I had registered in Gitlab, and sshing from my local machine then returned:

wmarsh@DESKTOP-CMPA99A:~$ ssh -T git@192.168.0.50
Welcome to GitLab, @xeonian!

I think this was ultimately caused by a mistake in the post_install script - while it attempts to set the home directory for the git user as /usr/home/git and create an .ssh directory for the user, these should actually be under /usr/local/git. I'll raise to have this corrected.
 
Top