SSH From *nix Machines Not Working

I’m having real trouble getting SSH working from two machine on my network.

I have GitLab Community Edition 15.6.2 running in Docker on my Synology. My Windows box is all working fine over SSH. However, both my Linux and MacOS machines cannot clone any repos. They can see the list of projects in the dropdown but as soon as it comes to actually clone, BOOM.

From my PopOS Linux box I’ve run:

ssh -Tv git@neo

Which outputs:

OpenSSH_8.9p1 Ubuntu-3ubuntu0.1, OpenSSL 3.0.2 15 Mar 2022
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files
debug1: /etc/ssh/ssh_config line 21: Applying options for *
debug1: Connecting to neo [] port 22.
debug1: connect to address port 22: Connection refused
ssh: connect to host neo port 22: Connection refused

I’ve gone through the same process to configure GitKraken from each machine including the Windows box but no joy for the others.

I’m presuming this line is the issue, but I’m really not sure.

/etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files

What can I try at this point?



Hi @jamsoft ! :wave: Welcome to the GitLab community forum! :tada:

I understand that you are having trouble getting SSH to work from your Linux and macOS machines while it’s working fine on your Windows machine. :thinking:

Let’s walk through a few potential solutions to resolve this issue.

First, let’s take a look at the line you mentioned:

/etc/ssh/ssh_config line 19: include /etc/ssh/ssh_config.d/*.conf matched no files

This line simply means that there are no additional configuration files present in the /etc/ssh/ssh_config.d/ directory, and it’s not necessarily an issue. Your SSH configuration is most likely read from /etc/ssh/ssh_config, not /etc/ssh/ssh_config.d/*

Now, let’s focus on the main issue:

ssh: connect to host neo port 22: Connection refused

This line indicates that the SSH connection to your GitLab server (neo) on port 22 is being refused. There could be a few reasons for this:

  1. Incorrect SSH key or configuration: Ensure that you’ve added your public SSH key to your GitLab profile and that your private key is properly configured on your Linux and macOS machines. You can refer to this GitLab guide on setting up SSH keys for more information.

  2. Host alias configuration: It seems you’re using neo as the alias for your GitLab server. Make sure it’s correctly configured in your /etc/hosts file or your DNS settings. Alternatively, try using the IP address directly:

    ssh -Tvvv git@[GITLAB-IP-ADDRESS]

  3. SSH config on your Linux and macOS machines: Check the contents of your ~/.ssh/config file on your Linux and macOS machines. Make sure there are no conflicting settings that could be causing the issue. You can refer to this SSH config guide for more details.

If none of these steps resolve the issue, please share more details about your GitLab server configuration and any error messages you encounter so we can help you better. :pray: :four_leaf_clover:

Hi Greg,

Thanks for the reply.

  1. When you create SSH keys in GitKraken it does so after connecting to the GitLab instance using the Personal Access Token. The SSH creation process automatically contacts my GitLab instance and registers the public part of the SSH key for me. This succeeds to register the key every time. I’ve lost count of the number of times I’ve checked that the public key is registered on my account.

2 I have already updated this in my host file and I can browse GitLab in Firefox on this URL http://neo:xxxx.

If I execute ssh -Tv git@ I get the same response as using the alias.

  1. Executing sudo nano ~/.ssh/config this is empty and there isn’t any .ssh in my home dir as far as I can tell.

GitKraken can be configured to use local SSH agent which uses the OS agent or it can use it’s own and configure keys. I’ve tried both, no joy.



I don’t know what GitKraken does.

The number of v’s in @gitlab-greg 's ssh -Tvvv git@[GITLAB-IP-ADDRESS] matters, more (to some degree, I think the limit is three) cause more output, so just saying what ssh -Tv git@ gives makes you appear negligent.

If there is no .ssh folder in your home directory, I’m not surprised SSH doesn’t work, your keys etc. should be there (I guess the administrator of the machine can have set something up that makes ssh look in another location, but that would just be strange).

Your output shows that the connection is refused before (I compared with the output I got from running a similar command here) a key is negotiated, so I very much doubt that the problem is usage of the wrong key.

When you said that you had used GitKraken, and that it had connected to GitLab, it struck me that it probably uses http(s) for that connection, but that lead me to another possibility: Is there a firewall somewhere between you and GitLab (it’s literally you and GitLab, so locally on the machines is a possibility) that allows http(s) (usually tcp port 80/443) but not SSH (usually tcp port 22).