Failed to start SSH server: listen tcp :22: bind: permission denied

Install/Maintain/Configure
1

Hi,

I’m trying to get a Gitea instance working inside an Ubuntu 18.04 VM, running as guest in VMWare Player. My host machine is Windows 10.

The issue is that I’m unable to SSH from my host machine:

ssh -T -v git@10.100.10.18
OpenSSH_for_Windows_7.7p1, LibreSSL 2.6.5
debug1: Connecting to 10.100.10.18 [10.100.10.18] port 22.
debug1: connect to address 10.100.10.18 port 22: Connection refused
ssh: connect to host 10.100.10.18 port 22: Connection refused

The gitea log file indicates that the SSL server is being denied permission to bind to port 22:

SSH server started on :22. Cipher list ([aes128-ctr aes192-ctr aes256-ctr aes128-gcm@openssh.com arcfour256 arcfour128]), key exchange algorithms ([diffie-hellman-group1-sha1 diffie-hellman-group14-sha1 ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 curve25519-sha256@libssh.org]), MACs ([hmac-sha2-256-etm@openssh.com hmac-sha2-256 hmac-sha1 hmac-sha1-96])
2019/05/29 14:13:32 [...a/modules/ssh/ssh.go:119 listen()] [E] Failed to start SSH server: listen tcp :22: bind: permission denied

I have followed the tutorial as closely as possible, although I did end up deviating slightly from the suggested supervisor configuration file. It looks to me like this file is expecting paths which were never created in previous steps:

directory=/home/git/go/src/github.com/go-gitea/gitea/
command=/home/git/go/src/github.com/go-gitea/gitea/gitea web

Specifically: the gitea binary was moved to a global location previously in the tutorial, and I don’t think the source-code was ever installed using the binary-install instructions. Anyway, I believe this is not relevant to my issue, just mentioning for completeness.

Other things I should mention:

  • Using Gitea 1.7.0
  • All configuration points to ‘git’ user
  • I have added ‘git’ to sudoers, does not fix my issue

Googling around, it seems that it’s normal for a non-root user to be unable to bind to port 22. The instructions for allowing a user to bind to port 22 seem quite complex and it feels like that may be the wrong answer.

So, to put it simply: what is the recommended method to allow Gitea to listen on port 22? (or any other SSL port)?

Is the standard approach to use a different SSL socket to avoid this issue?

2

Ok, I ended up using an alternative SSL port instead of 22.

This lead to some minor issues in GitExtensions which is a bit finicky about non-standard SSL ports; the Connection Test function suggests that it’s not configured correctly, apparently because the test-remote-connection function ignores the port settings. However, if you just ignore this message, the actual git functions work correctly.

Anyway, at least everything is working now.

3

I don’t think it’s a good idea to use a port other than 22 for Gitea, citing your concerns above.

I use non-standard ports for running OpenSSH as a matter of course. I believe it is the most prudent thing to do and so do most sysadmins. you can change your port number in /etc/ssh/sshd_config and restart your sshd daemon. After that it will listen on that port.

The only issue I’ve ever seen is that now you’ve broken the ability to simply ‘ssh-copy-id’, which is no big deal, you only generally place your public key on a server once anyway, so if that’s the method you use then do the ssh-copy-id first and then change your port numbers.

Now that you’ve done that, I think the information in my post here will explain “most” of everything that you were trying to do, with explanations as to how: https://bit.ly/2G2JElW

I hope that helps :slight_smile:
.

1 Like
4

As a remark: On Unix systems IP ports up to and including 1023 are privileged ports and only privileged users like root can bind to them.

5

I don’t quite understand - it’s a bad idea to use a port other than 22, but you use a non-standard port as a matter of course? Can you elaborate?

6

Hi, @asfarley. Gitea’s ssh port is used only for providing a git service: it won’t provide any of the standard services expected on that port (login, scp, etc). You’ll probably want to leave port 22 for regular ssh services. If you have absolutely no interest in that, then the operating system will require you to give root/Administrator permissions to Gitea to let it open port 22. Giving root/Administrator permissions to any but the most essential services is a bad security practice, and you can find extense literature about that in the Internet. :wink:

Having said that, on Ubuntu and CentOS there’s a way of enabling the use of port 22 for specific services (including Gitea) even if they are not running as root using some selinux configuration, but I think you need to repeat that command every time you upgrade Gitea or change the executable in any way.

1 Like
7

Thank you for the clarification.

My goal is to set up a Gitea instance which acts as much like Github as possible, mainly so that integration with other services can follow the Github instructions.

Do you think Github is doing something like your suggestion where they bind to 22 as non-root? Or, would that be the most straightforward way to emulate the Github endpoint using Gitea?

8

If you want a glimpse of the magic :mage: performed by GitHub, you can check this article. It’s not for the faint of heart.

There are so many ways to implement what you want to do. One possibility is to configure iptables to nat from port 22 into port 2222 or whatever port you’d like. There’s also the SeLinux way I’ve mentioned in my previous comment. The absolutely worst method is giving Gitea root permissions (have you given a thought what a user can do with a git hook?).

My advise is that if you don’t know how to do these things by heart, you stay away from them as much as possible.

Anyway, the restriction about port 22 is not Gitea’s. Gitea can listen on any port you want as long as the underlying operating system will allow it.

But please bear in mind that if you use Gitea on port 22, you will not be using ssh for the normal stuff (at least not without tweaks). That means that either 1) you’ll realize you actually need the other ssh stuff at some point and regret your decision or 2) you’ll be using really insecure ways to access your system, like telnet and ftp, etc.

Finally: once you’ve set up your system to a certain URI, changing it later is a pain because all clients will be pointing to the original URI and you’ll have to ask them one by one to update their remotes.