TCP Port 22 – SSH (Secure Shell)
Port 22 is the standard port for SSH, the Secure Shell protocol used to log into and administer remote computers across an encrypted channel. SSH is the workhorse of modern systems administration. When a sysadmin connects to a Linux server, when a developer pushes code to a Git repository, when a backup script copies files to a remote host, or when an automated deployment pipeline runs a command on a production machine, the connection almost always runs through SSH on port 22. The protocol is specified in RFC 4251 and the related RFCs published in 2006.
SSH replaced the earlier Telnet protocol on port 23 starting in the late 1990s and is now the universal standard for remote shell access. Where Telnet sent every keystroke (including passwords) across the network in plaintext, SSH negotiates an encrypted session and supports public-key authentication, host verification, port forwarding, and secure file transfer through SFTP and SCP. The combination made SSH not just a more secure replacement for Telnet but a more capable one, and the migration was largely complete on internet-facing systems by the early 2000s.
Outbound TCP/22 from end-user devices is normal in technical contexts (developers, sysadmins, devops engineers) and uncommon outside them. Inbound TCP/22 to a host running an SSH server is normal if that host is intentionally configured for remote access, common on Linux servers, and uncommon on consumer endpoints.
Port 22 is also defined for UDP and SCTP in the IANA registry, but neither sees significant real-world use. SSH typically requires the reliable, ordered, persistent connection that TCP provides.
About TCP Port 22
The Internet Assigned Numbers Authority (IANA) registers port 22 for ssh. The IANA description reads: ‘The Secure Shell (SSH) Protocol’.
Security Considerations
SSH on port 22 is one of the most-attacked services on the public internet, but the attack pattern is not what its IDS rule profile might suggest. Our data shows only 35 IDS rules referencing port 22, dominated by command-and-control and trojan-activity classtypes. This count understates the real exposure substantially. The dominant attack against exposed SSH today is automated credential brute-forcing, which is a high-volume but low-sophistication activity that most IDS rule sets do not flag rule-by-rule. Any internet-facing SSH server with a public IP receives a constant stream of login attempts using common usernames (root, admin, ubuntu, oracle, etc.) and password lists.
Beyond the routine brute-force traffic, our dataset preserves rules for the specific historical SSH exploits that did rise to IDS-detection level. The CRC32 compensation attack (CVE-2001-0144) and the 2002 “gobbles” exploit appear in multiple rules, both targeting OpenSSH versions from that era. These flaws were patched over twenty years ago, but the rules remain useful for detecting attacks against unpatched legacy systems.
Several malware families also appear in the dataset, including Emotet (MITRE S0367, primarily seen here in lateral-movement contexts where a compromised host probes other internal SSH servers), the BPFDoor backdoor (MITRE S1161, a Linux-targeted implant designed for stealth on compromised servers), and the NetWire remote access trojan. Most of these reflect post-compromise lateral movement rather than initial intrusion vectors against SSH itself.
Common practice for hardening SSH includes disabling password authentication entirely in favor of public-key authentication, restricting login to specific user accounts, blocking the root account from direct SSH login, and using fail2ban or similar tools to throttle brute-force attempts. Many organizations also move SSH off port 22 to a non-standard port to reduce automated scanning noise, though this is security through obscurity and does not stop a determined attacker. Restricting SSH access to a known network range or placing the service behind a VPN is more substantive.
Inbound TCP/22 to an internet-facing host is expected if that host is meant to accept SSH, but ongoing monitoring of authentication logs is essential given the volume of attempts. Inbound TCP/22 to an endpoint that is not configured for remote administration is unusual and worth investigating.
IDS Rule References
21 IDS / security rules reference TCP port 22. Presence in IDS rules does not mean traffic on this port is malicious. These are patterns security tools monitor.
Rule categories (top 6): successful-admin (4), trojan-activity (4), shellcode-detect (4), attempted-recon (3), misc-attack (3), network-scan (2).
Sample rule descriptions for TCP port 22:
- INDICATOR-SHELLCODE ssh CRC32 overflow /bin/sh
- INDICATOR-SHELLCODE ssh CRC32 overflow filler
- INDICATOR-SHELLCODE ssh CRC32 overflow NOOP
- INDICATOR-SHELLCODE ssh CRC32 overflow
- INDICATOR-SCAN SSH Version map attempt
Malware Activity
A meaningful share of monitored traffic on this port involves malware indicators.
3 of 21 IDS rules for TCP port 22 involve malware activity.
Families observed (top 2): BPFDoor (1), Netwire_RAT (1).
Data Sources
This information is compiled from: IANA Service Name and Transport Protocol Port Number Registry, Emerging Threats Open Ruleset (BSD 2-Clause / GPLv2 per SID range), Snort Community Rules (GPLv2), and MITRE ATT&CK (Apache 2.0).