Introduction

When your Git server listens on a non-default SSH port, the remote URL has to describe that port somehow. The usual confusion comes from Git's short SSH syntax, which looks compact but has no dedicated place for a custom port. The practical fix is to use an ssh:// URL or define an SSH host alias in your client configuration.

Use ssh:// When You Need An Explicit Port

The most direct solution is to include the port in a full SSH URL.

git remote add origin ssh://[email protected]:2222/home/git/project.git

That command tells Git to connect as user git to example.com on port 2222 and use /home/git/project.git as the repository path.

You can confirm that the remote was added correctly with:

git remote -v

This form is unambiguous and works well when you know the exact host, user, port, and path.

Why The Short Syntax Does Not Work

Git also accepts the shorter scp-style syntax:

[email protected]:project.git

That format is convenient, but it does not contain a separate field for the port. The colon already separates the host from the remote path. So a string such as [email protected]:2222/project.git does not mean "port 2222". Git treats 2222/project.git as the path on the server.

That is why custom ports and scp-style syntax do not mix cleanly.

Use An SSH Config Alias For Repeated Access

If you connect to the same host often, an SSH client alias is usually cleaner than repeating the port in every Git remote.

Add this to ~/.ssh/config:

1Host git-alt
2    HostName example.com
3    User git
4    Port 2222

Then you can use the alias in Git:

git remote add origin git-alt:/home/git/project.git

This keeps the repository configuration short and moves connection details into the SSH layer, where they also help with plain ssh, scp, and other tools.

Test SSH Before Blaming Git

Before debugging Git, verify that SSH itself can reach the server on the custom port.

ssh -p 2222 [email protected]

Or, if you are using the alias:

ssh git-alt

If that fails, the problem is not git remote add. It is usually authentication, firewall access, host keys, or the server path.

Updating An Existing Remote

If the remote already exists and only the port is wrong, update the URL instead of deleting and re-adding the remote.

git remote set-url origin ssh://[email protected]:2222/home/git/project.git

That is safer because it preserves the remote name and avoids unnecessary churn in scripts or documentation.

Common Pitfalls

The biggest pitfall is trying to force the port into the short scp-style syntax. Git will treat that as part of the path, not as a connection port.

Another common issue is focusing on Git before checking SSH connectivity directly. A failing SSH connection will make every Git command fail too.

Repository paths are another source of confusion. Even with the right port, different servers expect different repository roots such as /home/git/project.git, /srv/git/project.git, or a hosting-specific namespace.

Finally, if you use the same host often, do not keep repeating the port by hand. Put it in ~/.ssh/config and let your SSH client handle it consistently.

Summary

• Use ssh://user@host:port/path.git when a Git remote needs a non-default SSH port.
• Git's short scp-style syntax does not support a separate port field.
• For repeated use, define an SSH alias in ~/.ssh/config.
• Test plain SSH connectivity before debugging Git-specific commands.
• Use git remote set-url when fixing an existing remote.