Port 873 rsync – Free, Online, Private

What listens on 873

Port 873 is the rsync daemon, rsync --daemon. The IANA name is rsync, on TCP and also listed for UDP. The daemon people run is TCP. A module in rsyncd.conf is a named tree, and the client asks for it after the connection. That is a different path from rsync user@host:/path, which is SSH on port 22 and then the rsync protocol inside the SSH channel. Opening 873 does nothing for the SSH form. Closing 22 does nothing to a daemon that is actually on 873. The protocol starts with a greeting, not with TLS.

The IANA service name is rsync: rsync. The practical transport is TCP. The checks below use TCP. IANA may also have a UDP row for 873. 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 873

Service notes for port 873: the IANA name is rsync (rsync), and the program people mean is rsync. TCP 873 is the IANA rsync port, used by the rsync daemon. rsync over SSH uses port 22 and never opens 873. An rsync daemon with a module marked read only is still a file server. A module without hosts allow, and without a secret, will be found. Do not point a module at /. Prefer SSH for anything that crosses a network you do not control, because you already have keys and a host key. If you keep 873, bind it to the backup VLAN, require a secret, and keep the secret out of the process list. The daemon does not encrypt. Anyone on the path can read the files. Nothing in that paragraph applies to a different number just because the software family is similar. If your listener is not on 873, you are on the wrong page.

The usual mix-up is a firewall ticket for 873 when the cron job uses SSH. The job fails on 22 and 873 looks closed, which is correct and irrelevant. Another is a daemon that started and then was not restarted after rsyncd.conf changed, so the module list is stale. Another is a chroot module whose path is wrong, which accepts the TCP connection and then errors. nc only proves the greeting. A third is IPv6 left open. A fourth is running the daemon as root because the files were root-owned, which makes a module bug a host bug.

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 873 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. You want rsync, or a socket-activated unit, on TCP 873. From another host the banner is the rsync greeting. A connection to 22 tells you about SSH, not about this daemon.

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.

• rsync over SSH does not use 873. It uses 22.
• IANA lists UDP 873. The daemon is TCP.
• A TCP greeting is not a successful module read. Auth and the path can still fail.
• The transfer is not encrypted. Do not put secrets on an open module.

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

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

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

Remotenc -vz host 873