SFTP port guide: secure file transfer over SSH

SFTP is not FTP with encryption added on top. It is a separate protocol that runs inside an SSH session. The client connects to the SSH server, authenticates with a password, key, certificate, or other SSH-supported method, and then starts the SFTP subsystem to list directories, upload files, download files, rename paths, and manage permissions.

Because SFTP rides on SSH, it benefits from SSH encryption, host key verification, and mature authentication controls. For most deployments, the SFTP port is therefore TCP 22. Some organizations move SSH and SFTP to another port to reduce background scan noise, but changing the port does not replace authentication and authorization controls.

Classic FTP commonly uses port 21 for commands and separate data ports for transfers. That makes firewalling and NAT more complex, and plain FTP sends credentials and data without encryption. FTPS adds TLS to FTP, but it still keeps the FTP model with command and data channels.

SFTP uses one SSH connection, which is usually easier to allow through firewalls and easier to audit. SCP also uses SSH, but SFTP offers richer file-management operations and is the better default for interactive transfers, partner drops, and automated file workflows.

Open SFTP access when a partner, automation job, backup process, deployment pipeline, or internal team needs to exchange files securely with a server. Common examples include vendor data feeds, nightly exports, log collection, secure document delivery, and controlled upload areas for customers or field devices.

Do not expose SFTP broadly just because it is encrypted. An internet-facing SSH service attracts credential attacks and automated scanning. If only a small group needs access, restrict the source IPs, publish SFTP behind a VPN or private network, or use a managed transfer gateway with stronger policy controls.

Before you open port 22 for SFTP, confirm that the SSH server is installed, running, and configured to allow the SFTP subsystem. Then decide which users or service accounts should connect, which directories they can see, whether password authentication is allowed, and how uploads and downloads will be logged.

Separate network reachability from account authorization. A port checker can show whether TCP 22 is reachable from the internet, but it cannot prove that a specific user can log in or that a chroot directory is correct. Use an SFTP client or ssh command-line tests to verify the application-level behavior.

On Windows Server, install and enable OpenSSH Server, allow inbound TCP 22 in Windows Defender Firewall, and confirm that the sshd service is running. If the server is in a cloud environment, also allow port 22 in the cloud firewall or security group. Use dedicated accounts rather than broad administrator access.

On Linux, install OpenSSH Server, confirm that sshd is listening on port 22, and make sure the SFTP subsystem is enabled in sshd_config. For restricted file transfer accounts, configure chroot directories, ownership rules, and ForceCommand internal-sftp so users cannot get an interactive shell.

On macOS, SFTP is available through the built-in SSH service. It is most often used for local networks, development machines, or lab environments. If you expose it beyond a trusted network, apply the same key-based authentication and firewall rules you would use on a server.

Start with an external port check against the public hostname or IP address and port 22. If the port is open, the TCP path to the SSH service is reachable. Next, use an SFTP client or run sftp user@example.com to verify authentication, host key trust, directory access, and upload permissions.

If you need lower-level detail, test the SSH handshake with ssh -vvv user@example.com or check listeners on the server with ss -tlnp, netstat, or PowerShell. For cloud servers, compare host firewall rules with cloud security groups because both layers must allow the connection.

If the SFTP port shows closed, sshd may not be running, may be listening on a different port, or may be blocked by the host firewall. If the check times out, a cloud security group, router NAT rule, ISP filter, VPN policy, or source-IP allowlist may be dropping packets before they reach the server.

If the port is open but SFTP login fails, inspect the username, key permissions, password policy, MFA requirement, allowed users, chroot ownership, ForceCommand rules, and server logs. A common mistake is giving a chroot directory write permissions for the user; OpenSSH requires specific ownership and permission patterns for chroot to work safely.

Prefer SSH keys or certificate-based authentication over passwords. Disable root login, limit which users can connect, rotate keys, remove unused accounts, and protect private keys with passphrases or hardware-backed storage. For partner access, create one account per partner so activity can be attributed and revoked cleanly.

Restrict file-system access with chroot or tightly scoped directories, avoid shared writable folders unless they are required, and monitor failed logins and unusual transfer volumes. If SFTP is internet-facing, combine rate limiting, source allowlists, intrusion detection, and regular patching of the SSH server.