Port 9418 git daemon – Free, Online, Private

What listens on 9418

Port 9418 is the git protocol. The IANA name is git, git pack transfer service, assigned in 2005, on TCP and UDP. git daemon listens on TCP and serves repositories that have git-daemon-export-ok. The URL form is git://host/path. There is no authentication and no encryption. The pack protocol is the same idea as the one inside SSH and HTTPS, without either wrapper. Ordinary hosting uses SSH on 22 or HTTPS on 443. A closed 9418 on a GitHub-style host is normal. A closed 22 is not, if that is how you push. UDP is registered and is not the daemon.

The IANA service name is git: git pack transfer service. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 9418. The service described here is the TCP one. A process can bind this port without being the service in the registry. The commands show who bound it. They do not prove the protocol on the wire is the one IANA named.

Service notes for port 9418

Service notes for port 9418: the IANA name is git (git pack transfer service), and the program people mean is git daemon. TCP 9418 is the IANA git port, the git pack transfer service. The git daemon uses it. git over SSH uses 22, and git over HTTPS uses 443. git:// is anonymous read, and a mis-set daemon can be an anonymous write. Do not run it on the internet. If you need a mirror inside a build network, export only the repositories you mean, keep the export-ok file as the opt-in, and firewall the port to the builders. SSH with a deploy key is the alternative that already has an identity. HTTPS with a credential helper is the other. Neither needs 9418. A daemon running as a user that can write the repos is a publish path. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 9418, you are on the wrong page.

A clone URL of git:// fails in a network that blocks 9418, while https:// for the same host works. Change the URL. Another trap is a daemon that is running and a repository that lacks git-daemon-export-ok, so the port accepts and the path is refused. Another is a corporate proxy that allows 443 and not 9418, which is the right default. Another is confusing this port with a CI system that fetches over SSH. The job's known_hosts and the key decide that path.

How to check whether it is open

On the machine itself, ask the kernel which socket is bound. ss and lsof do that. A firewall, a security group, and a Docker publish rule sit in front of that socket, so a listener is not the same thing as a port the internet can use. From somewhere else, nc -vz host 9418 tries a TCP handshake when the command is the TCP form. A refusal means something answered with a reset. A timeout means a filter dropped the packet or the host is unreachable. Those are different faults. git-daemon on TCP 9418 is the finding. If nothing is listening, git:// will fail and the other transports can still work. Test the URL scheme you actually ship.

grep and findstr match text. A pattern of :80 also matches :8080 and :8000. The lsof and Get-NetTCPConnection forms take a numeric port and do not have that substring bug. Use them when the number is ambiguous. ss filters in the kernel with sport = :N, which is also exact. On macOS, netstat -p selects a protocol. It does not print the process the way Linux netstat -p does. lsof prints the process.

• 9418 is git:// only. SSH is 22. HTTPS is 443.
• The protocol does not authenticate.
• A repository is invisible to the daemon without git-daemon-export-ok.
• UDP 9418 is not how clones work.

Linuxsudo ss -lptn 'sport = :9418'
sudo lsof -nP -iTCP:9418 -sTCP:LISTEN

macOSsudo lsof -nP -iTCP:9418 -sTCP:LISTEN
netstat -anv -p tcp | grep '\.9418[^0-9]'

Windowsnetstat -ano | findstr :9418
Get-NetTCPConnection -LocalPort 9418

Remotenc -vz host 9418