SSH

What is SSH?

SSH (Secure Shell) is a cryptographic network protocol that lets you log in to another system over an untrusted network with encryption and authentication, run commands, transfer files and tunnel connections. SSH replaces insecure predecessors such as Telnet, rlogin and rsh, which sent passwords and commands across the network in clear text. It is the standard tool for command-line administration of servers, network equipment and embedded systems.

In OT environments, SSH is mainly used to manage Linux-based devices, firewalls, bastion hosts, switches, edge devices and industrial servers. Because an SSH session often grants administrative rights, SSH is also one of the most important access paths an attacker will try to abuse.

🕰️ Where does SSH come from?

Finnish researcher Tatu Ylönen designed SSH in 1995 at Helsinki University of Technology after passwords had been sniffed on the university network. The first version (SSH-1) spread quickly but turned out to have design flaws. The IETF therefore developed a new, incompatible version: SSH-2, published in 2006 as RFC 4250 to 4254. SSH-1 is considered obsolete and should be disabled everywhere.

SSH runs on TCP port 22 by default. Since Windows 10 (1809) and Windows Server 2019, OpenSSH has also shipped with Windows as an optional feature.

🧠 How does SSH work?

SSH-2 consists of three layers that work together on top of TCP:

1. Transport layer - the client connects to the server (usually on port 22). Both sides negotiate algorithms and perform a key exchange (for example X25519, or a hybrid with ML-KEM). The server proves its identity with a host key, which the client compares with the fingerprint stored in known_hosts. From then on the channel is encrypted and protected against tampering.
2. Authentication layer - only inside that encrypted channel does user authentication take place: with a password, a public key, an SSH certificate or a hardware key (FIDO2).
3. Connection layer - the session is split into channels for an interactive shell, single commands, file transfer and port forwarding.

A common misconception is that all SSH traffic is “asymmetrically encrypted”. In reality SSH uses asymmetric cryptography only for the key exchange and for signatures (host key and user key, such as Ed25519, ECDSA or RSA). The actual data is protected with fast symmetric encryption such as AES-GCM or ChaCha20-Poly1305.

Typical uses of SSH:

• Remote CLI access to servers, routers, switches and firewalls
• SCP or SFTP for secure file transfer; since OpenSSH 9.0 the scp command uses the SFTP protocol under the hood by default
• Port forwarding and tunnels to internal OT systems
• Session management via a Bastion Host or Jump Server, for example with the ProxyJump option
• Automation of configuration changes and backups with scripts and management tools

SSH is a core component of secure remote access in a Zero Trust OT Architecture, provided every session runs through a controlled access point.

🔄 What is the difference between SSH, Telnet and RDP?

Telnet still turns up in industrial networks on older switches, serial device servers and controllers. In 2016 the Mirai botnet abused exactly that kind of Telnet access with default passwords on hundreds of thousands of IoT devices. Where a device supports both Telnet and SSH, disable Telnet.

🏭 How is SSH used in industrial networks?

• Administration of industrial Linux devices - edge gateways, industrial PCs, log servers and protocol converters
• Network components - managed industrial switches, routers and firewalls almost always offer an SSH CLI alongside a web interface
• Access to level 3 servers in the Purdue Model, such as the historian or SIEM log servers
• Bastion Host with SSH access as the only stepping stone to internal assets in the DMZ
• Key management - passwordless access with personal keys instead of shared accounts
• Logging and session auditing via Syslog, SIEM or security monitoring, optionally with session recording

Note: some legacy OT devices have an outdated SSH implementation that only supports weak algorithms, or contain hard-coded keys and passwords. Modern clients often refuse to connect to them. Do not re-enable weak algorithms globally; limit the exception to that one device and plan its replacement.

🔐 How do you secure SSH?

• Use key-based authentication (preferably Ed25519, the default type of ssh-keygen since OpenSSH 9.5) with a passphrase, and disable password login with PasswordAuthentication no
• Disable root login with PermitRootLogin no; work with personal accounts and elevate rights through sudo following least privilege
• Restrict who can connect with AllowUsers or AllowGroups, and with Firewall rules that only admit the bastion host or the management segment
• Add a second factor through MFA or a FIDO2 hardware key (key types ed25519-sk and ecdsa-sk, available since OpenSSH 8.2)
• Use a bastion host or jump server for access from other networks, combined with PAM for approval and session recording; port knocking only hides the port and is no substitute
• Limit tooling on the jump server with application whitelisting, so that only approved management programs can run
• Log every session centrally in your SIEM and regularly review which keys are listed in authorized_keys
• Keep OpenSSH up to date through patch management and track vulnerabilities through vulnerability management

Keys are not passwords that expire: a forgotten key belonging to a supplier who left years ago stays valid. IEC 62443 (for example the requirements for authenticator management and strength of public key authentication in IEC 62443-3-3) and ISO 27001 (management of authentication information and use of cryptography) therefore expect a demonstrable lifecycle: issuance, inventory, revocation and replacement. These standards do not prescribe a fixed rotation period for SSH keys; you set that period in your own policy, often supported by certificate management with short-lived SSH certificates. Good access control around SSH is what turns a strong protocol into strong security.

🛠️ Which settings and vulnerabilities matter in practice?

A practical hardening approach for SSH on OT servers and gateways takes five steps:

1. Inventory every system with port 22 (or 23 for Telnet) open, including network equipment.
2. Harden the server configuration (sshd_config); see the table below.
3. Centralise access through a single bastion host in the DMZ and block direct SSH from the office IT network.
4. Replace shared accounts with personal keys or certificates and record who holds which key.
5. Monitor and patch: send authentication logs to the SIEM and update OpenSSH after security releases.

Recent vulnerabilities show why updating matters. Terrapin (CVE-2023-48795, December 2023) was a man-in-the-middle attack on the handshake, fixed with “strict KEX” in OpenSSH 9.6. regreSSHion (CVE-2024-6387, July 2024) allowed, under certain conditions, unauthenticated code execution as root on glibc-based Linux systems running OpenSSH 8.5p1 up to 9.8p1; version 9.8 fixed it. In March 2024 a backdoor was also discovered in xz-utils (CVE-2024-3094) that targeted the SSH server through a linked library: an example of a supply chain attack. On OT devices SSH is often baked into the firmware, so there you depend on the manufacturer for fixes.

For the choice of algorithms, the German BSI publishes technical guideline TR-02102-4, which is updated every year. In the Netherlands and the EU, secure remote access is becoming a legal duty of care: the Dutch Cybersecurity Act (in force from 15 August 2026) requires appropriate measures for access management and cryptography, and the Cyber Resilience Act requires manufacturers to report actively exploited vulnerabilities from 11 September 2026 and to ship products with a secure default configuration from 11 December 2027.

❓ Frequently asked questions

Is SSH secure enough for remote access to OT systems?

SSH itself is cryptographically strong when you use a current version and modern algorithms. The risk lies mainly in poor key management, password login and direct exposure to the internet. Offer SSH to OT systems only through a bastion host with MFA and logging.

Which port does SSH use?

SSH uses TCP port 22 by default. Moving SSH to another port reduces automated scan noise in the logs, but it is not a security control. Restrict access to port 22 with firewall rules that only admit known management systems instead.

What is the difference between SSH, SCP and SFTP?

SSH is the underlying protocol for encrypted connections. SFTP is a file transfer protocol that runs inside an SSH channel, and SCP is an older copy command that has also used SFTP by default since OpenSSH 9.0. All three share the same SSH authentication and encryption.

Which type of SSH key should you use?

Ed25519 is the common choice: compact, fast and the default in recent OpenSSH versions. RSA with at least 3072 bits remains usable for older devices, but DSA is obsolete and was removed in OpenSSH 10.0. For highly privileged administrators, FIDO2 keys (ed25519-sk) add protection because the private key never leaves the hardware.

Is SSH resistant to quantum computers?

OpenSSH has used a hybrid post-quantum key exchange by default since version 9.0, and the ML-KEM-based variant since version 10.0. This protects intercepted SSH traffic against decryption by a future quantum computer, provided both sides support such an algorithm. The signatures for host and user keys are not yet post-quantum.

Why is SSH in OT usually accessed through a jump server?

A jump server concentrates all SSH access to the OT network in one controlled point. There you can enforce MFA, record sessions and restrict access per supplier or time window. As a result, no OT device has to be directly reachable from the office IT network or the internet.

📌 In summary

SSH (Secure Shell) is the standard encrypted protocol for remote administration of OT and IT systems, from Linux servers to industrial switches and firewalls. The protocol itself is strong, but its security depends on key management, disabled password and root login, access through a bastion host, logging in the SIEM and timely patching, in line with IEC 62443 and ISO 27001 and as part of sound compliance.