https://www.ssh.com/academy/ssh/port
* About us
* Investors
* Partners
* Careers
Request demo
* Solutions
+ By Topic
o What are you better without?
o Just-in-time Zero Trust solutions
o Secure Information Sharing (SIS)
o Quantum Safe Solutions
o Credentials & secrets management 2.0
o Digital transformation
o M2M connections
o Pass IT audits
o Secure file transfer
+ By Industry
o Managed Service Providers (MSP)
o Operational Technology (OT)
* Products
+ Secure access management
o PrivX(tm) lean PAM
o Universal SSH Key Manager(r)
+ Secure file transfer & encryption
o NQX(tm) quantum-ready encryption
o Tectia(tm) SSH Client/Server
o Tectia(tm) z/OS
+ SSH Deltagon Suite
o Secure Email
o Secure Sign
o Secure Rooms
o Secure Forms
Request demo
* Solutions
+ BY TOPIC
o What are you better without in the hybrid cloud?
o Just-in-time Zero Trust solutions
o Secure Information Sharing (SIS)
o Quantum Safe Cryptography (QSC)
o Credentials & secrets management 2.0
o Security Risk Assessment, Quantification & Mitigation
o M2M connections
o Pass IT audits
o Secure file transfer
+ BY INDUSTRY
o Managed Service Providers (MSP)
o Operational Technology (OT)
* Products
+ SSH DELTAGON SUITE
o Secure Email
o Secure Sign
o Secure Forms
o Secure Rooms
+ SECURE ACCESS & SECRETS MANAGEMENT
o PrivX(tm) lean PAM
o Universal SSH Key Manager(r)
+ SECURE FILE TRANSFER & ENCRYPTION
o Tectia(tm) SSH Client/Server
o Tectia(tm) z/OS
o NQX(tm) quantum-safe encryption
* Services
+ SSH Risk Assessment(tm)
+ Professional Services
+ Support
+ Contact us
* Customer cases
+ PrivX Zero Trust PAM
+ Enterprise Key Management UKM
+ Tectia SFTP for servers & mainframes
+ SSH Deltagon Suite
* Resources
+ SSH Academy
+ References
+ Press releases
+ Downloads
+ Manuals
+ Events & Webinars
+ Blog
+ Media
+ Legal
+ Report a vulnerability
* Solutions
+ BY TOPIC
o What are you better without in the hybrid cloud?
o Just-in-time Zero Trust solutions
o Secure Information Sharing (SIS)
o Quantum Safe Cryptography (QSC)
o Credentials & secrets management 2.0
o Security Risk Assessment, Quantification & Mitigation
o M2M connections
o Pass IT audits
o Secure file transfer
+ BY INDUSTRY
o Managed Service Providers (MSP)
o Operational Technology (OT)
* Products
+ SSH DELTAGON SUITE
o Secure Email
o Secure Sign
o Secure Forms
o Secure Rooms
+ SECURE ACCESS & SECRETS MANAGEMENT
o PrivX(tm) lean PAM
o Universal SSH Key Manager(r)
+ SECURE FILE TRANSFER & ENCRYPTION
o Tectia(tm) SSH Client/Server
o Tectia(tm) z/OS
o NQX(tm) quantum-safe encryption
* Services
+ SSH Risk Assessment(tm)
+ Professional Services
+ Support
+ Contact us
* Customer cases
+ PrivX Zero Trust PAM
+ Enterprise Key Management UKM
+ Tectia SFTP for servers & mainframes
+ SSH Deltagon Suite
* Resources
+ SSH Academy
+ References
+ Press releases
+ Downloads
+ Manuals
+ Events & Webinars
+ Blog
+ Media
+ Legal
+ Report a vulnerability
* About us
* Investors
* Partners
* Careers
Request demo
SSH Academy
* Cloud
+ What is Cloud Computing?
+ Cloud Applications
+ Cloud Computing Models
+ Cloud Computing Pros and Cons
+ Cloud Computing Security
+ Cloud Computing Services: Characteristics
+ Cloud Service Providers
+ IaaS
+ PaaS
+ SaaS
+ Virtualization Technology
* Cryptography
+ Cryptography Explained
+ Cryptography and the Quantum Threat
+ Encryption Key Management
+ Private & Public Keys
+ Quantum Computing & Post-Quantum Algorithms
* Identity and Access Management (IAM)
+ What is Identity and Access Management (IAM)?
+ What is IAM Zero Trust Framework?
+ A Guide to Passwordless and Keyless Authentication
+ A Guide to Zero Trust Architecture
+ Active Directory
+ Ephemeral Certificates & Ephemeral Access
+ Gartner CARTA
+ Identity Management
+ Jump Server
+ Just-in-Time Access
+ Just-in-Time Security Tokens
+ Multi-Factor Authentication (MFA)
+ OpenID Connect (OIDC)
+ Password and Key Rotation
+ Password Generator
+ Password Strength Best Practices
+ Password Vaults
+ Privileged Access Management (PAM)
+ Privileged Access Management - Legacy PAM
+ Privileged Access Management (PAM) in the Cloud
+ Privileged Accounts
+ Privileged Account and Session Management (PASM)
+ Privilege Elevation and Delegation Management
+ Privileged Session Management
+ Radius
+ Root Accounts
+ Sudo
+ User Account Types
+ User IDs
+ Zero Standing Privileges (ZSP)
* Internet of Things (IoT)
+ IoT Security
+ Accessing IOT devices for SSH
* Operational Technology
+ What is OT Security?
+ What is the IT/OT Convergence?
* Public Key Infrastructure (PKI)
+ What is Public Key Infrastructure (PKI)?
+ PKI Background
+ PKI Certificates
* Secure Shell (SSH)
+ What is Secure Shell (SSH)?
+ What is the Secure Shell (SSH) Protocol?
+ Automated Connections
+ Network Monitoring
+ OpenSSH
+ sshd: OpenSSH Server Process
+ Port 22
+ RCP
+ rlogin
+ RSH
+ SCP
+ Session Key
+ SSH Command
+ SSH Configuration
+ SSH Software Downloads
+ SSH for Windows
+ SSH Servers
+ SSH Server Configuration
+ SSHFS SSH File System
+ SSO Using SSH Agent
+ Tectia SSH Server
+ Telnet
+ WinSCP
* Security Orchestration
+ Basics of Security Orchestration
+ DLP
+ SIEM
+ SOAR
+ SOC
* SFTP
+ FTP Clients
+ FTP Legacy
+ FTP Servers
+ FTPS
+ SFTP
* SSH Compliance
+ What is the NIST Cybersecurity Framework?
+ Basics of SSH Compliance
+ Basics of SSH Key Compliance
+ Basel III
+ Fips 200
+ GDPR
+ HIPAA
+ ISACA
+ ISACA SSH Guide
+ ISO 27001
+ NIS Directive
+ NIST 7966
+ NIST 7966 Download
+ NIST 800-53
+ PCI-DSS
+ Sans Top 20
+ Sarbanes Oxley
* SSH Clients
+ What are SSH Clients?
+ Tectia SSH Client
+ PuTTY Background
+ PuTTY Download
+ PuTTY for Linux
+ PuTTY for Mac
+ PuTTY for Windows
+ PuTTY for Windows Installation
+ PuTTY Public Keys
+ PuTTYgen for Linux
+ PuTTYgen for Windows
* SSH Keys
+ A Basic Overview of SSH Keys
+ What is an SSH Key?
+ Authorized Key
+ Authorized Keys File
+ Authorized Keys in OpenSSH
+ CAC and PIV Smartcards
+ Copy ID
+ Passphrase
+ Passphrase Generator
+ Public Key Authentication
+ SSH Host Key
+ SSH Key Identities
+ SSH Key Management
+ SSH Key Proliferation
+ SSH Keys for SSO
+ SSH Keygen
+ Universal SSH Key Manager
* SSH Tunneling
+ SSH Tunneling
+ SSH Tunneling Example
* Hacks, Threats & Vulnerabilities
+ Bothanspy Gyrafalcon
+ Breaches in Operational Technology
+ Breaches Involving Passwords & Credentials
+ GoScanSSH
+ Malware
+ Man-in-the-Middle
+ Password Sniffing
SSH Port
Contents
How SSH port became 22 The story of getting SSH port 22 Changing the
SSH port in the server Specifying SSH port number on the command line
Configuring SSH access through firewalls Outbound SSH Back-tunneling
is a risk Inbound SSH access Enabling SSH access via iptables
How SSH port became 22
The default SSH port is 22. It is not a coincidence. This is a story
of how it got that port.
When I (Tatu Ylonen first published this story in April 2017, it went
viral and got about 120,000 readers in three days.
The story of getting SSH port 22
I wrote the initial version of SSH (Secure Shell) in Spring 1995. It
was a time when telnet and FTP were widely used.
Anyway, I designed SSH to replace both telnet (port 23) and ftp (port
21). Port 22 was free. It was conveniently between the ports for
telnet and ftp. I figured having that port number might be one of
those small things that would give some aura of credibility. But how
could I get that port number? I had never allocated one, but I knew
somebody who had allocated a port.
The basic process for port allocation was fairly simple at that time.
Internet was smaller and we were in the very early stages of the
Internet boom. Port numbers were allocated by IANA (Internet Assigned
Numbers Authority). At the time, that meant an esteemed Internet
pioneer called Jon Postel and Joyce K. Reynolds. Among other things,
Jon had been the editor of such minor protocol standards as IP (RFC
791), ICMP (RFC 792), and TCP (RFC 793). Some of you may have heard
of them.
To me Jon felt outright scary, having authored all the main Internet
RFCs!
Anyway, just before announcing ssh-1.0 in July 1995, I sent this
e-mail to IANA:
From ylo Mon Jul 10 11:45:48 +0300 1995 From: Tatu Ylonen
To: Internet Assigned Numbers Authority
Subject: request for port number
Organization: Helsinki University of Technology, Finland
Dear Sir, I have written a program to securely log from one machine into another over an insecure network.
It provides major improvements in security and functionality over existing telnet and rlogin protocols
and implementations. In particular, it prevents IP, DNS and routing spoofing. My plan is to distribute
the software freely on the Internet and to get it into as wide use as possible. I would like to get a registered
privileged port number for the software.
The number should preferably be in the range 1-255 so that it can be used in the WKS field in name servers.
I'll enclose the draft RFC for the protocol below. The software has been in local use for several months,
and is ready for publication except for the port number. If the port number assignment can be arranged in time,
I'd like to publish the software already this week. I am currently using port number 22 in the beta test.
It would be great if this number could be used (it is currently shown as Unassigned in the lists).
The service name for the software is "ssh" (for Secure Shell).
Yours sincerely, Tatu Ylonen ... followed by protocol specification for ssh-1.0
The next day, I had an e-mail from Joyce waiting in my mailbox:
Date: Mon, 10 Jul 1995 15:35:33 -0700 From: jkrey@ISI.EDU To: ylo@cs.hut.fi Subject: Re: request for port number
Cc: iana@ISI.EDU Tatu, We have assigned port number 22 to ssh, with you as the point of contact. Joyce
There we were! SSH port was 22!!!
On July 12, 1995, at 2:32am, I announced a final beta version to my
beta testers at Helsinki University of Technology. At 5:23pm I
announced ssh-1.0.0 packages to my beta testers. At 5:51pm on July
12, 1995, I sent an announcement about SSH (Secure Shell) to the
cypherpunks@toad.com mailing list. I also posted it to a few
newsgroups, mailing lists, and directly to selected people who had
discussed related topics on the Internet.
New call-to-action
Changing the SSH port in the server
By default, the SSH server still runs in port 22. However, there are
occasions when it is run in a different port. Testing use is one
reason. Running multiple configurations on the same host is another.
Rarely, it may also be run without root privileges, in which case it
must be run in a non-privileged port (i.e., port number >= 1024).
The port number can be configured by changing the Port 22 directive
in /etc/ssh/sshd_config. It can also be specified using the -p
option to sshd. The SSH client and sftp programs also support the -p
option.
Specifying SSH port number on the command line
The -p option can be used to specify the port number to
connect to when using the ssh command on Linux. The -P (note:
capital P) option can be used with SFTP and scp. The SSH port number
command line setting overrides any value configured in configuration
files.
Configuring SSH access through firewalls
SSH is one of the few protocols that are frequently permitted through
firewalls. Unrestricted outbound SSH is very common, especially in
smaller and more technical organizations. Inbound SSH is usually
restricted to one or very few servers.
Outbound SSH
Configuring outbound SSH in a firewall is very easy. If there are
restrictions on outgoing traffic at all, just create a rule that
allows TCP port 22 to go out. That is all. If you want to restrict
the destination addresses, you can also limit the rule to only permit
access to your organization's external servers in the cloud, or to a
jump server that guards cloud access.
Back-tunneling is a risk
Unrestricted outbound SSH can, however, be risky. The SSH protocol
supports tunneling. The basic idea is that it is possible to have the
SSH server on an external server listen to connections from anywhere,
forward those back into the organization, and then make a connection
to some Internal server.
This can be very convenient in some environments. Developers and
system administrators frequently use it to open a tunnel that they
can use to gain remote access from their home or from their laptop
when they are travelling.
However, it generally violates policy and takes control away from
firewall administrators and the security team. It can, for example,
violate PCI, HIPAA, or NIST SP 800-53. It can be used by hackers and
foreign intelligence agencies to leave backdoors into organizations
Inbound SSH access
For inbound access, there are a few practical alternatives:
* Configure firewall to forward all connections to port 22 to a
particular IP address on the internal network or DMZ.
* Use different ports on the firewall to access different servers.
* Only allow SSH access after you have logged in using a VPN
(Virtual Private Network), typically using the IPsec protocol.
Enabling SSH access via iptables
Iptables is a host firewall built into the Linux kernel. It is
typically configured to protect the server by preventing access to
any ports that have not been expressly opened.
If iptables is enabled on the server, the following commands can be
used to permit incoming SSH access. They must be run as root.
iptables -A INPUT -p tcp --dport 22 -m conntrack --ctstate NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -p tcp --sport 22 -m conntrack --ctstate ESTABLISHED -j ACCEPT
If you want to save the rules permanently, on some systems that can
be done with the command:
service iptables save
SSH port at firewall can permit tunneling to banks
Together with our customers, our mission is to secure their digital
business on on-premises, cloud, and hybrid ecosystems
cost-efficiently, at scale, and without disruptions to their
operations or business continuity.
* Solutions
+ Zero Trust Access Management
+ Quantum-Safe Solutions
+ Secure Information Sharing (SIS)
+ Operational Technology
+ Hybrid cloud
+ Credentials management 2.0
+ Digital transformation
+ Secure file transfer
+ Pass IT audits
* Products
+ PrivX(tm)
+ UKM(tm)
+ Tectia(tm)
+ Tectia(tm) z/OS
+ Deltagon Suite
+ Secure Email
+ Secure Sign
+ Secure Forms
+ Secure Rooms
+ NQX(tm)
* Services
+ SSH Risk Assessment(tm)
+ Professional Services
+ Support
* Resources
+ Careers
+ References
+ Downloads
+ Manuals
+ Events & Webinars
+ Blog
* Company
+ About us
+ Contact
+ Investors
+ Partners
+ Press
Stay on top of the latest in cybersecurity
Be the first to know about SSH's new solutions and features
Thanks for submitting the form.
(c) Copyright SSH * 2022 * Legal