I’m trying to migrate from an internal gitlab instance to gitlab.com I have migrated a project but am struggling to clone the repo from glitlab.com over SSH. Port 22 is blocked for SSH in my network so i’m attempting use SSH over the alternative port as laid out in GitLab.com now supports an alternate git+ssh port | GitLab
However when verifying the setup using ssh -T git@gitlab.com I get the following error
kex_exchange_identification: Connection closed by remote host
Connection closed by 172.65.251.182 port 443
running ssh -Tvvv git@gitlab.com gives:
OpenSSH_8.8p1, OpenSSL 1.1.1l 24 Aug 2021
debug1: Reading configuration data /c/Users/USR/.ssh/config
debug1: /c/Users/USR/.ssh/config line 1: Applying options for gitlab.com
debug1: Reading configuration data /etc/ssh/ssh_config
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/c/Users/USR/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/c/Users/USR/.ssh/known_hosts2'
debug2: resolving "altssh.gitlab.com" port 443
debug3: resolve_host: lookup altssh.gitlab.com:443
debug3: ssh_connect_direct: entering
debug1: Connecting to altssh.gitlab.com [172.65.251.182] port 443.
debug3: set_sock_tos: set socket 4 IP_TOS 0x48
debug1: Connection established.
debug1: identity file /c/Users/USR/.ssh/gitlab type 0
debug1: identity file /c/Users/USR/.ssh/gitlab-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.8
debug1: kex_exchange_identification: banner line 0: HTTP/1.1 400 Bad Request
debug1: kex_exchange_identification: banner line 1:
kex_exchange_identification: Connection closed by remote host
Connection closed by 172.65.251.182 port 443
Trying a clone also results in an error:
ssh_exchange_identification: Connection closed by remote host Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
I have tried regenerating my SSH keys and they are all setup on my gitlab.com account.
Well, ports 80 and 443 are used for HTTP and HTTPS access to gitlab so that is unlikely going to work. If the port is blocked in your network, then you need to get the port unblocked.
The alternative is don’t use SSH for git cloning, and do your cloning over HTTP/HTTPS so port 80 or port 443 instead. Then you don’t need to do anything with SSH.
Yes this is correct, but as the blog post states the cloud version also has it setup to use the alternate port of 443 for SSH with the configuration that is detailed in the blog post.
The post is also linked from the documentation GitLab.com settings | GitLab, so I thought it was still a valid solution to the problem of port 22 been blocked.
Yes, but then you connect differently, as per the docs (hadn’t realised they had SSH running on an alternate address until reading your link):
ssh -T git@altssh.gitlab.com -p 443
note the hostname is different with altssh. I just tested this (if this was added to .ssh/config as per the docs, then git@gitlab.com should work if altssh.gitlab.com is in the HOSTNAME field of the config file):
works when SSH key is added to my account. Therefore if you still have issues, it’s most likely a problem with the SSH key on your user account not matching what is locally on your machine - or perhaps your network wherever you are is doing more filtering.
NGFW (next generation firewalls), will block SSH traffic irrespective of the port. It’s effectively a rule that looks for SSH and doesn’t care if the destination is port 22, or any one of the 65535 ports available. This stops people attempting to bypass a firewall on ports 80 or 443 which are generally unblocked for normal HTTP/HTTPS connections. But I would make sure the SSH key you uploaded does match what you have locally, so if you uploaded id_rsa.pub then make sure it matches what is in there. You always upload the pub files, rather than the private key which would be the id_rsa file. Or whichever type you generated be it ECDSA or ED25519.
After much back and forth with infra guys it seems we do have a firewall that will block the SSH traffic regardless of port (I also managed to connect using my personal laptop).
Looks like HTTPS will have to be used for pull/push until they unblock the port.
On a side note the changes to the ssh config file route any requests to gitlab.com to altssh.gitlab.com, you can see it applying the options in the debug trace so just running ssh git@gitlab.com was using the alternate port and address.