SSH on alternate ssh port not working


I’m trying to migrate from an internal gitlab instance to I have migrated a project but am struggling to clone the repo from 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 now supports an alternate git+ssh port | GitLab

However when verifying the setup using ssh -T I get the following error

kex_exchange_identification: Connection closed by remote host
Connection closed by port 443

running ssh -Tvvv 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
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 "" port 443
debug3: resolve_host: lookup
debug3: ssh_connect_direct: entering
debug1: Connecting to [] 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 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 account.

Any help would be appreciated.

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 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 -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 should work if is in the HOSTNAME field of the config file):

[ian@elise ~]$ ssh -T -p 443
Welcome to GitLab, @iwalker!

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 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.

Could you please check netstat -tulpn if there is someone already listening on TCP 443 ?

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 to, you can see it applying the options in the debug trace so just running ssh was using the alternate port and address.

Thanks for your assistance.