SSH port guide: secure remote server access

SSH creates an encrypted channel between a client and a remote server. During connection setup, the client verifies the server host key, both sides negotiate encryption, and the user authenticates with a password, SSH key, certificate, hardware-backed key, or another configured method.

After authentication, SSH can provide an interactive shell, execute a single remote command, forward ports, copy files, or power tools such as Git, rsync, Ansible, and deployment pipelines. That flexibility is why SSH is operationally important and why exposure needs careful policy.

Open SSH when administrators, automation tools, CI/CD jobs, configuration management, Git services, or break-glass workflows need remote access to a server or device. For public cloud servers, SSH is often the first management path used before higher-level tooling is installed.

Do not publish SSH to the entire internet if only a small group needs access. Prefer VPN, bastion hosts, zero-trust access, cloud serial consoles, source-IP allowlists, or private network connectivity when possible. If public SSH is unavoidable, enforce strong authentication and monitoring from the start.

Before opening port 22, confirm that sshd is running, listening on the intended interface, and configured for the authentication model you actually want. Decide whether passwords are allowed, which users may log in, whether root login is disabled, and how administrative actions will be audited.

A port checker can confirm whether TCP 22 is reachable from outside your network, but it cannot prove that a user can log in safely. Use ssh -vvv, server logs, and account-level tests to validate host key trust, key permissions, MFA policies, shell access, and sudo rules.

On Windows Server, install and enable OpenSSH Server, start the sshd service, and allow inbound TCP 22 in Windows Defender Firewall. Cloud-hosted Windows servers also need matching cloud firewall or security group rules.

On Linux, install OpenSSH Server, check sshd_config, and allow TCP 22 through the host firewall such as ufw, firewalld, nftables, or iptables. Cloud instances also require the provider security group to permit the same source networks.

On macOS, enable Remote Login when SSH is needed on trusted networks. For internet exposure, apply the same controls as a server: key-based authentication, firewall scoping, logging, and timely updates.

Start with an external port check against the public hostname or IP address and port 22. If the result is open, the TCP path to SSH is reachable. Then run ssh user@example.com or ssh -vvv user@example.com to verify the host key, authentication method, and session setup.

On the server, confirm the listener with ss -tlnp, netstat, or PowerShell. If a cloud server is involved, compare host firewall rules with the cloud security group because either layer can block SSH even when the other looks correct.

If port 22 is closed, sshd may be stopped, installed on a different port, bound only to a private interface, or blocked by the host firewall. If the check times out, packets may be dropped by a cloud security group, router NAT rule, ISP filter, VPN policy, or source-IP allowlist.

If the port is open but login fails, inspect the username, key permissions, authorized_keys file, password policy, MFA requirement, AllowUsers or DenyUsers rules, root login settings, and server logs. Many SSH failures are authorization problems rather than port problems.

Disable root login, prefer keys or certificates over passwords, rotate keys, remove stale accounts, and restrict who can connect. Use MFA or hardware-backed keys for privileged access, and make sure private keys are protected with passphrases or secure hardware storage.

Reduce attack surface with source allowlists, bastion hosts, VPN, rate limiting, intrusion detection, and timely OpenSSH patches. Moving SSH to a nonstandard port can reduce noisy scans, but it should be treated only as noise reduction, not as a security control.