GitLab Install on Ubuntu 20.04 fails with 3rd party Centrify-SSHD

We’re using a 3rd party SSH daemon - Centrify SSHD. When attempting to install gitlab, I get the following output. I already removed Centrify’s SSH and it installed successfully, but any hints on how to get GitLab to install properly with a 3rd part SSHD?

After running # apt-get install gitlab-ee - Following output:
Reading package lists… Done
Building dependency tree
Reading state information… Done
The following NEW packages will be installed:
0 upgraded, 1 newly installed, 0 to remove and 25 not upgraded.
1 not fully installed or removed.
Need to get 976 MB of archives.
After this operation, 2602 MB of additional disk space will be used.
Get:1 focal/main amd64 gitlab-ee amd64 13.10.0-ee.0 [976 MB]
Fetched 976 MB in 2min 24s (6775 kB/s)
Selecting previously unselected package gitlab-ee.
(Reading database … 193841 files and directories currently installed.)
Preparing to unpack …/gitlab-ee_13.10.0-ee.0_amd64.deb …
Unpacking gitlab-ee (13.10.0-ee.0) …
Setting up openssh-server (1:8.2p1-4ubuntu0.2) … is a disabled or a static unit, not starting it.
Job for ssh.service failed because the control process exited with error code.
See “systemctl status ssh.service” and “journalctl -xe” for details.
invoke-rc.d: initscript ssh, action “restart” failed.
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; disabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Tue 2021-03-30 19:59:55 PDT; 8ms ago
Docs: man:sshd(8)
Process: 1193017 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Process: 1193018 ExecStart=/usr/sbin/sshd -D $SSHD_OPTS (code=exited, status=255/EXCEPTION)
Main PID: 1193018 (code=exited, status=255/EXCEPTION)

Mar 30 19:59:55 systemName systemd[1]: Starting OpenBSD Secure Shell server…
Mar 30 19:59:55 systemName sshd[1193018]: error: Bind to port 22 on failed: Address already in use.
Mar 30 19:59:55 systemName sshd[1193018]: error: Bind to port 22 on :: failed: Address already in use.
Mar 30 19:59:55 systemName systemd[1]: ssh.service: Main process exited, code=exited, status=255/EXCEPTION
Mar 30 19:59:55 systemName sshd[1193018]: fatal: Cannot bind any address.
Mar 30 19:59:55 systemName systemd[1]: ssh.service: Failed with result ‘exit-code’.
Mar 30 19:59:55 systemName systemd[1]: Failed to start OpenBSD Secure Shell server.
dpkg: error processing package openssh-server (–configure):
installed openssh-server package post-installation script subprocess returned error exit status 1
dpkg: dependency problems prevent configuration of gitlab-ee:
gitlab-ee depends on openssh-server; however:
Package openssh-server is not configured yet.

dpkg: error processing package gitlab-ee (–configure):
dependency problems - leaving unconfigured
No apport report written because the error message indicates its a followup error from a previous failure.
Errors were encountered while processing:
E: Sub-process /usr/bin/dpkg returned an error code (1)

Hi @slateythree
AFAIK GitLab works only with the OpenSSH daemon.

Depending on your options, you could deploy it using Docker container.

Hi, Gitlab has dependencies, and they are based on what is available by default in the repositories. Therefore, you are unlikely to see it being able to support and utilise 3rd party SSH solutions.

You could attempt to leave openssh-server installed so that the gitlab dependencies are continuously met, and then just disable it:

systemctl disable ssh
systemctl stop ssh

of course, make sure you have a console connection to the server when you do this. Then install the 3rd party SSH and run it. See if gitlab will work when this is installed. There is no guarantee, but it could work providing that the dependency (openssh-server), is left installed on the system as if you remove it, you break the dependencies what Gitlab requires.

Let’s just hope that the 3rd party SSH app doesn’t see OpenSSH as being installed and attempt to remove it before installing itself.

You could also attempt the docker option as above, since openssh isn’t a dependency for docker, chances are it would have more success of working than my little hack above.

Thanks @iwalker and @balonik.

Centrify’s SSH isn’t a hard requirement for us - just a nice to have due to some of the config it automates and supports. I don’t recall having the issue on my RHEL test box, but it’s entirely possible I just didn’t get around to installing Centrify SSHD before doing the GitlLab install on the RHEL box.

I can confirm that after installing GitLab, reinstalling Centrify SSHD, things seem to be working just fine. I also did an upgrade while leaving Centrify SSHD installed, and aside from some complaints about another service being bound to the address and port 22 (Mar 30 19:59:55 systemName sshd[1193018]: error: Bind to port 22 on :: failed: Address already in use) - It worked and upgraded as expected.

You can check with:

systemctl status ssh

and see if it’s enabled/disabled at boot, then do:

systemctl disable ssh

so that it won’t start the OpenSSH version during boot. Whilst this won’t necessarily stop the upgrade process from attempting to start it, you can at least try this during the next upgrade to see if the errors still appear even when it’s disabled. If so, then in theory you can also do:

systemctl mask ssh

which means even if someone attempts to enable/start the service, it will just be sent to /dev/null and thus not generate any errors. Not all services can be masked, but it’s worth a try if you don’t want to see those kinds of error messages appearing. Since openssh-server will be a dependency for gitlab, you cannot remove it, else it will get reinstalled later, but you can mitigate things by doing some or all of the above.