Port 22 is the TCP port for SSH. Interactive login, SFTP and SCP file transfer, remote commands and port forwarding all run over it. Moving it to another number quiets the logs and changes nothing else. Key authentication with passwords disabled is the control that matters.
- SSH, SFTP and SCP are one protocol on one port
- A rule permitting 22 permits tunnels as well as shells
- Changing the port removes scanning noise, not risk
- PasswordAuthentication no ends brute force entirely
- Remote forwarding turns an outbound session into an inbound path
On this page
What uses itWhat runs on port 22
SSH is often described as remote login, and that undersells it. Four distinct things use the same SSH port and the same connection.
Interactive shell sessions. The original purpose and the obvious one. An encrypted terminal on a remote machine.
File transfer. SFTP and SCP are not separate services with separate ports. They run inside an SSH session, which is why enabling the SSH server enables file transfer whether you meant to or not, and why an SFTP server on port 22 is an SSH server.
Remote command execution. Running one command and getting the output back, without an interactive session. Every configuration management and deployment tool that uses SSH works this way.
Port forwarding. SSH tunneling carries arbitrary TCP connections inside the session, in either direction. This is genuinely useful and it is also the feature that surprises people most, so it has its own section below.
The single connection carries all of it, multiplexed into channels. That is worth knowing because a firewall rule permitting port 22 permits every one of these, not only the shell, which is a security decision people make without noticing.
Changing the portThe story of the number, and why it does not matter much
The SSH port was assigned in 1995, at the request of the protocol author, because 22 sat between telnet on 23 and ftp on 21. That neighborhood was the point: SSH existed to replace telnet, which sent passwords and data across the network in plain text.
The number is a convention, not a requirement. An SSH server can listen anywhere, and a client can be told to connect anywhere.
Which brings up the advice that dominates search results for this port: change it to something else. The reasoning is that automated scanners look at 22, so moving it makes you invisible.
Half of that is true.
It does reduce log volume, substantially. An SSH server on port 22 with a public address collects thousands of automated login attempts a day. Moving it to a high port removes almost all of that, and a quiet log is genuinely easier to read.
It does not improve security in any meaningful way. Scanning all 65,535 ports of a host takes seconds, and services that scan the entire internet publish what they find. Anyone who has decided to attack your host specifically will find the SSH port. What you have removed is the untargeted background noise, not the targeted attempt.
On a multi user Linux system it has a small cost. Ports below 1024 can only be bound by root. A high numbered port can be bound by any user, so if sshd ever fails to start, another user on that machine could listen there instead and collect credentials.
The honest position: change the SSH port if you want quieter logs, and understand that you have changed nothing about who can get in. Then implement the security controls that do.
What worksWhat actually secures it
Five things, roughly in order of how much they matter.
Key authentication, with passwords disabled. A password can be guessed and a 4,096 bit key cannot. Setting PasswordAuthentication no in the sshd configuration ends the entire category of brute force and credential stuffing attempts at once. This is the single highest value security change available on the SSH port, and everything else is secondary to it.
Do not publish it at the internet edge. Reach servers through a VPN, or through one hardened jump host that is the only thing with SSH open. An SSH port open to the whole internet is a security decision worth making deliberately rather than by default.
Disable direct root login. PermitRootLogin no. Administrators log in as themselves and escalate, which also means the logs name a person.
Restrict which users may connect. AllowUsers or AllowGroups in sshd_config, and an iptables or firewall rule limiting source addresses where the set of clients is knowable.
Rate limit the attempts. Tools that watch the log and block addresses after repeated failures cut the noise and slow anything automated. Useful, and a distant fifth behind turning passwords off.
| Control | Stops brute force | Stops a targeted attacker | Effort |
|---|---|---|---|
| Key authentication, passwords off | Yes, completely | Raises the bar a long way | Low |
| Not publishing the port | Yes | Yes, if they cannot reach it | Medium |
| Disabling root login | Partly | Makes the logs useful | Very low |
| Restricting source addresses | Yes | Yes, where the list is knowable | Low |
| Rate limiting failures | Slows it | No | Low |
| Changing the port number | Reduces noise only | No | Very low |
Cisco devicesTurning on SSH on a Cisco switch or router
Everything above assumes a server running sshd. Network equipment is the other large population on port 22, and on a Cisco switch or router SSH is not available until somebody configures it.
Cisco's own configuration guide lists what a device needs before it will act as an SSH server: a hostname, a domain name, RSA keys, a way to authenticate users, and virtual terminal lines set up to accept SSH. A device missing any one of the five is not an SSH server.
To configure SSH on Cisco switches and routers running IOS, that comes to the following, in the order Cisco gives it. The names and the password are placeholders.
hostname SW1
ip domain name example.com
crypto key generate rsa general-keys modulus 4096
ip ssh version 2
username netadmin privilege 15 secret ChangeThisSecret
line vty 0 4
login local
transport input sshThe steps to enable SSH on Cisco switches and on Cisco routers are the same. Four of the lines are worth understanding rather than pasting.
The key size. Cisco recommends a 4096 bit modulus where the platform supports it, and 2048 bits or more where it does not. The device generates this key once and presents it to every client that connects, so it is not a setting to economize on.
login local makes the terminal lines check the username and secret stored on the device itself, which is what the username line created. Without an account to check against, there is nothing for an SSH login to succeed with.
transport input ssh is the line that turns Telnet off. Cisco's guidance is to restrict the terminal lines to SSH only, and this is the command that does it. With it in place a Telnet connection to those lines is refused, which is the point of replacing Telnet rather than running both side by side.
line vty 0 4 covers five lines. Cisco's example configures lines 0 to 4. A device with more terminal lines than that keeps whatever the remaining lines were already set to, so apply the same two commands to all of them, or the unconfigured ones are still a way in.
Then check the result. show ip ssh reports the version and the configuration, and show ssh lists the sessions connected right now.
The Cisco SSH configuration above is the minimum that works, not a hardened one. Everything in the previous section still applies to a switch, and one thing applies more: a management interface should be reachable from a management network, not from wherever a user happens to be sitting.
TunnelingPort forwarding, and the direction that matters
An SSH session can tunnel other connections, and there are three forms. Two of them are ordinary and one of them is a hole in a firewall.
| Form | Flag | Direction | What it opens |
|---|---|---|---|
| Local | -L | Outward | A remote service on a local port |
| Dynamic | -D | Outward | The remote network, through a SOCKS proxy |
| Remote | -R | Inward | A local service, reachable from the far end |
Local forwarding. ssh -L 8080:internal-server:80 jumphost makes local port 8080 on your own machine reach a service inside the remote network. Traffic goes out through the SSH connection you opened. This is the everyday use of SSH tunneling: reaching a database or a management interface through a jump host.
Dynamic forwarding. ssh -D 1080 jumphost turns the session into a SOCKS proxy, so any application configured to use it reaches the remote network. The same tunneling idea as local forwarding, without naming each destination.
Remote forwarding. ssh -R 2222:localhost:22 outside-host opens a port on the remote machine that reaches back into yours. This is the one to think about, because it means a user inside your network with outbound SSH access can make an internal service reachable from outside, through a connection your firewall permitted.
That last capability is legitimate and it is also how an inbound path gets created without any inbound firewall rule. Two sshd settings limit it: AllowTcpForwarding no on servers that have no need of tunneling, and GatewayPorts no, which is the default and keeps a remote forward bound to the local loopback address rather than published.
Outbound SSH to the internet is worth treating as a real security decision for the same reason. It is a general purpose tunnel, and permitting it from every machine permits more than shell access.
PitfallsWhere people go wrong
Changing the SSH port and calling it hardened. It is a log noise reduction. The security controls that matter are key authentication and not exposing the service.
Leaving password authentication enabled alongside keys. Keys do nothing while passwords remain accepted, because the attacker will simply use the password path.
Publishing port 22 for one contractor. It ends up permanent, and it is discovered within hours by an automated scan. A VPN account or a jump host is the same amount of work and does not expose a shell to the internet.
Forgetting that SFTP is SSH. Granting somebody file transfer access on port 22 usually grants them a shell as well, unless the account is deliberately restricted to SFTP only.
Allowing outbound SSH from every machine. SSH tunneling carries arbitrary TCP in both directions, and remote forwarding turns an outbound connection into an inbound path.
Sharing one account and one key. The log then records that "the server account" did something, which is not an answer to who.
Never rotating or removing keys. An authorized_keys file accumulates entries, and a key belonging to somebody who left three years ago still works perfectly.
ComparisonThree ways to reach a shell, and how many hosts each one asks you to harden
| Criterion | SSH published on 22 | SSH behind a VPN | SSH through a jump host |
|---|---|---|---|
| Reachable from the internet | Yes, by everybody | No | Only the jump host |
| Automated login attempts | Constant | None | Against one hardened host |
| Extra software for the user | None | A VPN client | None |
| Number of hosts to harden | Every server | Every server | One, then the rest internally |
| Survives a stolen password | Only with keys | Only with MFA and keys | Only with keys |
| Effort to set up | None | Medium | Low |
The fourth row is the argument for a jump host in a small network. Hardening one machine properly is achievable; hardening forty of them consistently is the thing that does not happen.
FAQFrequently asked questions
What is port 22 used for?
SSH, the Secure Shell protocol. That includes interactive login, SFTP and SCP file transfer, remote command execution and SSH tunneling, all over the same connection.
Should I change the SSH port?
Only if you want quieter logs. It removes untargeted scanning noise and does nothing about anybody who scans your host deliberately, which takes seconds.
Does changing the port improve SSH security?
Not in any way that matters. Key authentication with passwords disabled is the change that removes the attack, and moving the SSH port is a distant sixth in usefulness.
Is SFTP the same as SSH?
SFTP runs inside an SSH session on the same port, so an SFTP server is an SSH server. Granting file transfer usually grants shell access too, unless the account is restricted.
What is the difference between SSH and telnet?
Telnet on port 23 sends all data, passwords included, in plain text. SSH encrypts the session and authenticates the server, which is why it replaced telnet entirely.
Should port 22 be open to the internet?
Preferably not. A VPN or a single hardened jump host achieves the same access without exposing a shell service on every server to automated attack.
What is the best way to secure the SSH port?
Key authentication with PasswordAuthentication no, root login disabled, connections restricted by user and by source address, and the SSH server not published at the internet edge.
What is SSH port forwarding?
Carrying other TCP connections inside an SSH session. Local forwarding reaches into the remote network, dynamic forwarding does the same as a proxy, and remote forwarding opens a path back into yours.
Why is remote port forwarding a concern?
Because an outbound SSH connection your firewall permitted can be used to make an internal service reachable from outside, with no inbound rule involved.
How do I stop users tunneling through SSH?
AllowTcpForwarding no in sshd_config on servers with no need for it, and treating outbound SSH to the internet as a rule worth writing rather than a default.
Does port 22 use TCP or UDP?
TCP. SSH needs an ordered, reliable stream, and there is no standard UDP equivalent.
Why do I see thousands of failed logins?
Because the port is published and the internet is scanned continuously. With password authentication disabled they are noise; with it enabled they are attempts that will eventually succeed.
How do I configure SSH on a Cisco switch?
Give the device a hostname and a domain name, generate an RSA key with crypto key generate rsa, set ip ssh version 2, create a local user with a secret, and on the virtual terminal lines set login local and transport input ssh. Cisco recommends a 4096 bit key where the platform supports it.
What does transport input ssh do on the vty lines?
It restricts the virtual terminal lines to SSH, so a Telnet connection to them is refused. It only affects the lines it is applied to, so a device with more lines than the ones configured still accepts whatever the others allow.
How does this fit with other well known ports?
22 is in the range below 1024, so binding it requires privilege. That is one of the small arguments against moving SSH to a high numbered port on a shared machine.
What is the SSH default port?
The SSH default port is TCP 22, assigned by IANA. A server can listen elsewhere by changing the Port line in sshd_config, and the client then connects with the -p option.
Keep readingRelated concepts
Read next · Identity and access What Is MFA? Keys remove password guessing, and a second factor is what protects the key when the laptop holding it is stolen. Open this next16 min- Ports · 12 min What Is a Port Number? Port 22 sits below 1024, which is why binding it needs privilege and why a high numbered port has a small cost of its own.
- Remote access · 11 min SSL VPN Explained, and the Reason It Needs Patching First Reaching servers through a VPN instead of publishing SSH is the second control on the list, and this is what that looks like.
- Protocols · 9 min Telnet, Why SSH Replaced It, and the One Job It Kept What SSH replaced, what it looks like in a capture, and why the glossary answer leaves you with nothing to do.
- Ports · 9 min Port 21, and the Second Connection Nobody Expects What to move to.
- Network operations · 11 min Network Automation, and Why the Interface Matters More Than the Tool Two automation interfaces that run over SSH, and why one of them uses port 830.
- Ports · 9 min Port 110, and Why the Mail Keeps Coming Back The cleartext mail port and what replaced it.
- Ports · 9 min The RDP Port, and Why It Should Not Be the One Facing the Internet The other remote access port, and the one where changing the number matters even less.