Hubbry Logo
OpenSSHOpenSSHMain
Open search
OpenSSH
Community hub
OpenSSH
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
OpenSSH
OpenSSH
OpenSSH
View on Wikipedia
from Wikipedia

OpenSSH or OpenBSD Secure Shell
DeveloperThe OpenBSD Project
Initial release1 December 1999; 25 years ago (1999-12-01)
Stable release
10.1[1] Edit this on Wikidata / 6 October 2025
Repository
Written inC
Operating systemCross-platform[2]
StandardRFC 4250, RFC 4251, RFC 4252, RFC 4253, RFC 4254, RFC 4255, RFC 4256, RFC 4335, RFC 4344, RFC 4345, RFC 4419, RFC 4462, RFC 5656, RFC 6594, RFC 6668, RFC 7479[3]
TypeRemote access
LicenseBSD, ISC, public domain
Websitewww.openssh.com Edit this on Wikidata

OpenSSH (also known as OpenBSD Secure Shell[a]) is a suite of secure networking utilities based on the Secure Shell (SSH) protocol, which provides a secure channel over an unsecured network in a client–server architecture.[4][5]

OpenSSH started as a fork of the free SSH program developed by Tatu Ylönen; later versions of Ylönen's SSH were proprietary software offered by SSH Communications Security.[6] OpenSSH was first released in 1999 and is currently developed as part of the OpenBSD operating system.

OpenSSH is not a single computer program, but rather a suite of programs that serve as alternatives to unencrypted protocols like Telnet and FTP. OpenSSH is integrated into several operating systems, namely Microsoft Windows, macOS and most Linux operating systems,[7][8] while the portable version is available as a package in other systems.[9][10][11]

History

[edit]

OpenBSD Secure Shell was developed by OpenBSD developers as an alternative to the original SSH software by Tatu Ylönen, which is now proprietary software.[12] Although source code is available for the original SSH, various restrictions are imposed on its use and distribution. OpenSSH was created as a fork of Björn Grönvall's OSSH that itself was a fork of Tatu Ylönen's original free SSH 1.2.12 release,[13] which was the last one having a license suitable for forking.[14][15] The OpenSSH developers claim that their application is more secure than the original, due to their policy of producing clean and audited code and because it is released under the BSD license, the open-source license to which the word open in the name refers.

OpenSSH first appeared in OpenBSD 2.6. The first portable release was made in October 1999.[16] Developments since then have included the addition of ciphers (e.g., ChaCha20-Poly1305 in 6.5 of January 2014[17]), cutting the dependency on OpenSSL (6.7, October 2014[18]) and an extension to facilitate public-key discovery and rotation for trusted hosts (for transition from DSA to Ed25519 public host keys, version 6.8 of March 2015[19]).

On 19 October 2015, Microsoft announced that OpenSSH will be natively supported on Microsoft Windows and accessible through PowerShell, releasing an early implementation and making the code publicly available.[20] OpenSSH-based client and server programs have been included in Windows 10 since version 1803. The SSH client and key agent are enabled and available by default, and the SSH server is an optional Feature-on-Demand.[21]

In October 2019 protection for private keys at rest in RAM against speculation and memory side-channel attacks were added in OpenSSH 8.1.[22]

Development

[edit]
OpenSSH remotely controlling a server through Unix shell

OpenSSH is developed as part of the OpenBSD operating system. Rather than including changes for other operating systems directly into OpenSSH, a separate portability infrastructure is maintained by the OpenSSH Portability Team, and "portable releases" are made periodically. This infrastructure is substantial, partly because OpenSSH is required to perform authentication, a capability that has many varying implementations. This model is also used for other OpenBSD projects such as OpenNTPD.

The OpenSSH suite includes the following command-line utilities and daemons:

  • scp, a replacement for rcp.
  • sftp, a replacement for ftp to copy files between computers.
  • ssh, a replacement for rlogin, rsh and telnet to allow shell access to a remote machine.
  • ssh-add and ssh-agent, utilities to ease authentication by holding keys ready and avoid the need to enter passphrases every time they are used.
  • ssh-keygen, a tool to inspect and generate the RSA, DSA and elliptic-curve keys that are used for user and host authentication.
  • ssh-keyscan, which scans a list of hosts and collects their public keys.
  • sshd, the SSH server daemon.

The OpenSSH server can authenticate users using the standard methods supported by the SSH protocol: with a password; public-key authentication, using per-user keys; host-based authentication, which is a secure version of rlogin's host trust relationships using public keys; keyboard-interactive, a generic challenge–response mechanism, which is often used for simple password authentication, but which can also make use of stronger authenticators such as tokens; and Kerberos/GSSAPI. The server makes use of authentication methods native to the host operating system; this can include using the BSD Authentication system or pluggable authentication modules (PAM) to enable additional authentication through methods such as one-time passwords. However, this occasionally has side effects: when using PAM with OpenSSH, it must be run as root, as root privileges are typically required to operate PAM. OpenSSH versions after 3.7 (16 September 2003) allow PAM to be disabled at run-time, so regular users can run sshd instances.

On OpenBSD, OpenSSH uses a dedicated sshd user by default to drop privileges and perform privilege separation in accordance with the principle of least privilege, applied throughout the operating system including the Xenocara X server.

Features

[edit]

OpenSSH includes the ability to set up a secured channel through which data sent to local, client-side Unix domain sockets or local, client-side TCP ports may be "forwarded" (sent across the secured channel) for routing on the server side; when this forwarding is set up, the server is instructed to send that forwarded data to some socket or TCP host/port (the host could be the server itself, "localhost"; or, the host may be some other computer, so that it appears to the other computer that the server is the originator of the data). The forwarding of data is bidirectional, meaning that any return communication is itself forwarded back to the client-side in the same manner; this is known as an "SSH tunnel",[23] and it can be used to multiplex additional TCP connections over a single SSH connection since 2004,[24] to conceal connections, to encrypt protocols that are otherwise unsecured, and to circumvent firewalls by sending/receiving all manner of data through one port that is allowed by the firewall. For example, an X Window System tunnel may be created automatically when using OpenSSH to connect to a remote host, and other protocols, such as HTTP and VNC, may be forwarded easily.[25]

Tunneling a TCP-encapsulating payload (such as PPP) over a TCP-based connection (such as SSH's port forwarding) is known as "TCP-over-TCP", and doing so can induce a dramatic loss in transmission performance due to the TCP meltdown problem,[26][27] which is why virtual private network software may instead use for the tunnel connection a protocol simpler than TCP. However, this is often not a problem when using OpenSSH's port forwarding, because many use cases do not entail TCP-over-TCP tunneling; the meltdown is avoided because the OpenSSH client processes the local, client-side TCP connection in order to get to the actual payload that is being sent, and then sends that payload directly through the tunnel's own TCP connection to the server side, where the OpenSSH server similarly "unwraps" the payload in order to "wrap" it up again for routing to its final destination.[28]

In addition, some third-party software includes support for tunnelling over SSH. These include DistCC, CVS, rsync, and Fetchmail. On some operating systems, remote file systems can be mounted over SSH using tools such as sshfs (using FUSE).

An ad hoc SOCKS proxy server may be created using OpenSSH. This allows more flexible proxying than is possible with ordinary port forwarding.

Beginning with version 4.3, OpenSSH implements an OSI layer 2/3 tun-based VPN. This is the most flexible of OpenSSH's tunnelling capabilities, allowing applications to transparently access remote network resources without modifications to make use of SOCKS.[29]

Supported public key types

[edit]

OpenSSH supports the following public key types:[30][31]

  • ssh-dss (disabled at run-time since OpenSSH 7.0, released in 2015)[32]
  • ssh-rsa (disabled at run-time since OpenSSH 8.8, released in 2021)[33]
  • ecdsa-sha2-nistp256 (since OpenSSH 5.7, released in 2011)[34]
  • ecdsa-sha2-nistp384 (since OpenSSH 5.7)
  • ecdsa-sha2-nistp521 (since OpenSSH 5.7)
  • ssh-ed25519 (since OpenSSH 6.5, released in 2014)[35]
  • rsa-sha2-256 (since OpenSSH 7.2, released in 2016)[36]
  • rsa-sha2-512 (since OpenSSH 7.2)
  • ecdsa-sk (since OpenSSH 8.2, released in 2020)[37]
  • ed25519-sk (since OpenSSH 8.2)
  • NTRU Prime-x25519 (since OpenSSH 9.0, released in 2022)[38]

Vulnerabilities

[edit]

Before version 5.2 of OpenSSH, it was possible for an attacker to recover up to 14 bits of plaintext with a success probability of 2−14.[39] The vulnerability was related to the CBC encryption mode. The AES CTR mode and arcfour ciphers are not vulnerable to this attack.

A local privilege escalation vulnerability existed in OpenSSH 6.8 to 6.9 (CVE-2015-6565) due to world-writable (622) TTY devices, which was believed to be a denial of service vulnerability.[40] With the use of the TIOCSTI ioctl, it was possible for authenticated users to inject characters into other users terminals and execute arbitrary commands on Linux.[41]

Malicious or compromised OpenSSH servers could read sensitive information on the client such as private login keys for other systems, using a vulnerability that relies on the undocumented connection-resuming feature of the OpenSSH client, which is called roaming, enabled by default on the client, but not supported on the OpenSSH server. This applies to versions 5.4 (released on 8 March 2010[42]) to 7.1 of the OpenSSH client, and was fixed in OpenSSH 7.1p2, released on 14 January 2016. CVE numbers associated to this vulnerability are CVE-2016-0777 (information leak) and CVE-2016-0778 (buffer overflow).[43][44]

On March 29, 2024, a serious supply chain attack on XZ Utils was reported, indirectly targeting the OpenSSH server (sshd) running on Linux. The OpenSSH code is not directly affected, as the backdoor is caused by the dependencies on liblzma via libsystemd that could be applied by various Linux distributions.[citation needed]

On July 1, 2024, the RegreSSHion security vulnerability was disclosed, which could enable a remote attacker to cause OpenSSH to execute arbitrary code and gain full root access. It was inadvertently introduced in prior OpenSSH version 8.5p1 in October 2020, and was patched following version 9.8/9.8p1.[45][46]

Trademark

[edit]

In February 2001, Tatu Ylönen, chairman and CTO of SSH Communications Security informed the OpenSSH development mailing list that the company intended to assert its ownership of the "SSH" and "Secure Shell" trademarks,[47] and sought to change references to the protocol to "SecSH" or "secsh", in order to maintain control of the "SSH" name. He proposed that OpenSSH change its name in order to avoid a lawsuit, a suggestion that developers resisted. OpenSSH developer Damien Miller replied urging Ylönen to reconsider, arguing that "SSH" had long since been a generic trademark.[48]

At the time, "SSH", "Secure Shell" and "ssh" had appeared in documents proposing the protocol as an open standard. Without marking these within the proposal as registered trademarks, Ylönen ran the risk of relinquishing all exclusive rights to the name as a means of describing the protocol. Improper use of a trademark, or allowing others to use a trademark incorrectly, results in the trademark becoming a generic term, like Aspirin, which opens the mark to use by others.[49] After study of the USPTO trademark database, many online pundits opined that the term "ssh" was not trademarked, merely the logo using the lower case letters "ssh". In addition, the six years between the company's creation and the time when it began to defend its trademark, and that only OpenSSH was receiving threats of legal repercussions, weighed against the trademark's validity.[50]

Both developers of OpenSSH and Ylönen himself were members of the IETF working group developing the new standard; after several meetings this group denied Ylönen's request to rename the protocol, citing concerns that it would set a bad precedent for other trademark claims against the IETF. The participants argued that both "Secure Shell" and "SSH" were generic terms and could not be trademarks.[6]

See also

[edit]

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

OpenSSH

View on Grokipedia
from Grokipedia
OpenSSH is an open-source implementation of the (SSH) protocol suite, providing secure remote login, command execution, and capabilities over unsecured networks by encrypting all communication to prevent , connection hijacking, and other attacks. Developed in 1999 by the Project as a licensing-clean alternative to earlier free SSH code, it originated from a of Björn Grönvall's OSSH project and was rapidly advanced by key contributors including , Markus Friedl, Niels Provos, and others to support the 2.6 release in December 1999. The suite comprises essential components such as the ssh client for initiating secure connections, the sshd daemon for hosting SSH servers, scp for secure file copying, and sftp for interactive file transfers, all built atop the SSH-2 protocol standardized by the IETF. OpenSSH emphasizes security through features like strong authentication methods (including ), secure tunneling for , and configurable options for , while its portable version extends compatibility to numerous non- platforms including , Windows, macOS, and various systems. Maintained by a small team of developers under a BSD-style license, it has become the de facto standard for secure remote access, with the latest release, version 10.2, issued on October 10, 2025, incorporating bug fixes for ControlPersist usability and key handling alongside ongoing portability enhancements.

Introduction

Overview

OpenSSH is an open-source suite of networking utilities based on the (SSH) protocol, specifically implementing version 2.0 to facilitate secure remote login, file transfer, and command execution across unsecured networks. Developed under a BSD-style license, it encrypts all communication to ensure confidentiality and integrity, serving as the for secure remote access in modern computing environments. The core purpose of OpenSSH is to replace vulnerable legacy protocols like , rlogin, and rcp, which transmit data in and are susceptible to , tampering, and man-in-the-middle attacks. By providing robust and mechanisms, OpenSSH enables administrators and users to manage systems remotely without compromising , a critical need in distributed and cloud-based infrastructures. OpenSSH enjoys widespread adoption, installed by default on most operating systems, including major Linux distributions such as and , macOS, and BSD variants like . For Windows, it is available through official portable releases and integrated as an optional feature since Windows 10 version 1809. This ubiquity stems from its emergence in 1999, when OpenBSD developers forked the last free version of the original SSH software to address the licensing restrictions imposed by its proprietary successors in the late 1990s.

Components

OpenSSH is composed of a suite of tools and binaries designed to implement the SSH protocol for secure remote operations, with client-side, server-side, and auxiliary components that work together to enable encrypted communications and .

Client-side tools

The primary client-side tools facilitate remote access and over secure channels. The ssh client is a program for logging into a remote machine and executing commands on it, providing secure encrypted communications between untrusted hosts over an insecure network. The scp command copies files between hosts on a network in a secure manner, using the SFTP protocol over an SSH connection to ensure the same level of and as an SSH login session. Similarly, the sftp client is a secure interactive program that operates over an encrypted SSH transport, supporting features like public key for transferring files between local and remote systems.

Server-side tools

On the server side, the sshd daemon provides the core service for handling incoming SSH connections, listening for clients and forking new processes to manage each session, including , , and data transfer.

Auxiliary tools

Auxiliary tools support key generation, management, and processes integral to the suite's operation. The utility generates, manages, and converts authentication keys for SSH protocol version 2, creating public-private key pairs such as Ed25519 by default and allowing passphrase protection for private keys. The authentication agent holds private keys used for public key , allowing users to avoid repeatedly entering passphrases during multiple SSH sessions by securely storing and forwarding authentication requests. Complementing this, ssh-add adds private key identities to the authentication agent, loading default keys from the user's ~/.ssh directory or specified files and prompting for passphrases as needed. Additionally, ssh-keyscan gathers public host keys from remote servers to help build and verify known host files, using non-blocking I/O to efficiently collect keys from multiple hosts without requiring login access.

Configuration files

Configuration is centralized through dedicated files that govern the behavior of the tools. The ssh_config file customizes client-side settings for connections, , and forwarding, with user-specific options in ~/.ssh/config and system-wide defaults in /etc/ssh/ssh_config. On the server, sshd_config defines daemon parameters for , , and session handling, typically located at /etc/ssh/sshd_config and readable by all users while writable only by root. The modular design of these components allows them to interact seamlessly via the SSH protocol, enabling advanced functionalities such as and tunneling, where the ssh client can create secure channels for other applications or services. These tools collectively support authentication methods like public key authentication, with auxiliary components handling key-related tasks to maintain across operations.

History and Development

Origins

OpenSSH was founded in 1999 by and members of the project team, including Aaron Campbell, Bob Beck, Markus Friedl, Niels Provos, and Dug Song, as an open-source reimplementation of the (SSH) protocol. The project originated as a of OSSH, a bug-fixed version of Tatu Ylönen's original free SSH 1.2.12 release from 1998, which had been revived earlier that year by Björn Grönvall. Prior to OpenSSH, Ylönen had developed SSH in 1995 at to address password-sniffing vulnerabilities on his university network, releasing the initial protocol and software as free but later commercializing it through SSH Communications Security, which imposed restrictive licensing. The primary motivations for creating OpenSSH were to establish a freely auditable free from restrictions, enabling rigorous reviews aligned with OpenBSD's emphasis on proactive and code correctness. This effort was spurred by Ylönen's shift to commercial licensing, which limited community access and auditing of the increasingly popular SSH software, prompting the OpenBSD team to clean up and enhance the last free version for long-term maintainability. The initial source code was committed to the OpenBSD repository on September 26, 1999, marking the project's official start. The first portable release, OpenSSH 1.0, emerged in October 1999, providing an early multi-platform version based on the SSH 1.2.12 codebase but with immediate additions for SSH-2 protocol support to improve security. This was followed by integration into 2.6 as version 1.2.2 on December 1, 1999. Early development faced challenges including concerns over RSA encryption, which influenced the rapid adoption of SSH-2 alternatives like Diffie-Hellman , and U.S. cryptographic export restrictions that complicated international distribution of strong encryption tools during the late .

Evolution and Key Releases

OpenSSH's evolution has been marked by a steady progression toward enhanced and protocol standardization, beginning with its initial focus on replacing insecure remote access tools. By 2000, the project achieved full compliance with the SSH-2 protocol, a significant introduced in version 2.1.0p1 released on May 9, 2000, which provided robust encryption and authentication mechanisms superior to the vulnerable SSH-1. This transition culminated in version 3.0 on November 6, 2001, where SSH-2 became the default protocol, reflecting the developers' commitment to phasing out legacy insecurities. A pivotal advancement occurred in 2002 with OpenSSH 3.3, released on June 21, which enabled privilege separation by default—a design that isolates untrusted processes to limit potential exploit damage—building on preliminary implementations from earlier versions like 3.2 in May 2002. Further reinforcing this posture, OpenSSH disabled SSH-1 support by default in version 5.4p1 on March 8, 2010, and fully removed it in version 7.6 on October 3, 2017, accelerating the ecosystem's shift away from the protocol's known weaknesses. The development model centers on the operating system, where core OpenSSH is crafted with an emphasis on simplicity, auditability, and security, typically aligning with OpenBSD's biannual release cycle to incorporate rigorous code reviews and testing. Since its inception in 1999, a distinct "portable" version has been maintained separately by a to adapt the codebase for other and non-OpenBSD platforms, ensuring broad accessibility while preserving the original's security principles. This dual-track approach involves periodic synchronization between the OpenBSD trunk and portable branch, with the latter marked by 'p' suffixes in version numbers (e.g., 10.2p1) to denote portability-specific adjustments. The process relies on comprehensive code audits conducted by the OpenBSD team, a that incentivizes vulnerability discovery through monetary rewards, and funding from donations to support ongoing maintenance without commercial dependencies. In recent years, OpenSSH has continued to prioritize cryptographic modernization and vulnerability remediation. Version 9.0, released on April 8, 2022, switched the scp tool to use SFTP by default for improved security. Additionally, ssh-keygen began generating Ed25519 keys by default in version 9.5 on October 4, 2023, due to their efficiency and resistance to certain attacks. Addressing emerging threats, OpenSSH 9.9p2, issued on February 18, 2025, incorporated fixes for critical CVEs including CVE-2025-26465 (a man-in-the-middle vulnerability) and CVE-2025-26466 (a pre-authentication denial-of-service issue), affecting versions from 6.8p1 onward. Most recently, OpenSSH 10.2, released on October 10, 2025, resolved key bugs in the ControlPersist feature for multiplexed connections and PKCS#11 key handling; DSA key support was fully removed in version 10.0 on April 9, 2025, following earlier disablement by default in version 7.0 in 2015. These updates underscore the project's adaptive response to evolving security landscapes through targeted enhancements rather than wholesale overhauls.

Technical Features

Protocols and Algorithms

OpenSSH implements the Secure Shell version 2 (SSH-2) protocol as its primary transport mechanism, standardized in RFC 4251 through RFC 4254, which define the , , , and connection protocols, respectively. SSH-2 became the default protocol in OpenSSH starting with version 2.9 in 2001, providing enhanced security over the original SSH-1 through improved key exchange, integrity protection, and resistance to known vulnerabilities. Support for the insecure SSH-1 protocol, which lacked proper protection against insertion attacks and used weaker cryptography, was deprecated following the publication of SSH-2 standards in 2006, with a build-time option to remove it added in version 6.5 (2014); sshd disabled it by default in version 7.8 (2018), and it was fully expunged in later versions. OpenSSH also supports protocol extensions such as the (SFTP), integrated as a subsystem within the SSH-2 connection protocol per RFC 4254. For key exchange, OpenSSH employs Diffie-Hellman (DH) methods, including group exchange as specified in RFC 4419, to establish shared session keys securely between client and server. It supports Diffie-Hellman (ECDH) variants, such as ecdh-sha2-nistp256, ecdh-sha2-nistp384, and ecdh-sha2-nistp521, introduced in version 5.7 (2011) per RFC 5656 for efficient key agreement using NIST curves. Additionally, Curve25519-based exchanges like [email protected], added in version 6.5 (2014); standardized in RFC 8731 (2020), provide high-speed, secure key derivation with resistance to certain side-channel attacks. Recent versions, such as OpenSSH 10.0 (2025), prioritize hybrid post-quantum key exchanges like mlkem768x25519-sha256 by default—introduced earlier in 9.0 (2022) with sntrup761x25519-sha512—while disabling legacy finite-field DH groups for improved security. Version 10.2 (October 2025) added related portability fixes. Symmetric encryption in OpenSSH relies on modes to protect session data confidentiality and integrity. Preferred ciphers include AES variants in Galois/Counter Mode (GCM), such as [email protected] and [email protected], added in version 6.2 (2013) per RFC 5647, and Counter (CTR) mode like aes128-ctr and aes256-ctr per RFC 4344. The mode, introduced in version 6.5 (2014) via draft-ietf-secsh-chacha20-poly1305, serves as the default since version 6.9 (2015) due to its performance on resource-constrained devices and resistance to timing attacks. Older ciphers like 3DES (3des-cbc) were removed from default configurations in OpenSSH 8.0 (2020) to mitigate vulnerabilities in triple-DES, such as meet-in-the-middle attacks. Message authentication in OpenSSH uses hash-based message authentication codes (HMACs) and other primitives to ensure during transmission. It supports HMAC-SHA2 algorithms, including hmac-sha2-256 and hmac-sha2-512, added in version 5.9 (2011) per RFC 6668, which provide stronger than earlier SHA-1 variants. For AEAD ciphers like and AES-GCM, Poly1305 serves as the integrated authenticator, as defined in their respective specifications, eliminating the need for separate MACs while maintaining 128-bit security. Legacy MACs, such as those based on or truncated , were disabled by default in version 7.0 (2015) to prevent exploitation of weak hash functions. Encrypt-then-MAC (EtM) constructions, like [email protected], are preferred in modern configurations to enhance security against certain padding oracle attacks. Compression in OpenSSH is optional and implemented using the zlib library for deflate-based reduction of bandwidth usage, supporting methods like "zlib" and the delayed "[email protected]" variant introduced in version 4.2 (2005) to mitigate risks from pre-authentication compression attacks like . By default, compression is disabled in both client and server since early versions to prioritize and avoid potential vulnerabilities in compressed data handling, though it can be enabled explicitly for high-latency links. Pre-authentication compression support was fully removed in sshd version 7.4 (2016).

Authentication and Key Management

OpenSSH supports multiple authentication methods to verify user and host identities securely over the network. The preferred method is public-key authentication, where a client proves its identity using a cryptographic key pair without transmitting sensitive data like passwords. In this process, the client's private key remains local, while the corresponding public key is stored on the server for verification. Other methods include password authentication, which prompts the user for a plaintext password sent encrypted over the channel; keyboard-interactive authentication, which allows the server to issue challenges such as one-time passwords; and host-based authentication, which relies on trusted host files like /etc/hosts.equiv combined with public key verification of the client host. For enhanced security, OpenSSH integrates with Pluggable Authentication Modules (PAM) to enable multi-factor authentication (MFA) through keyboard-interactive methods, allowing systems to combine public keys or passwords with additional factors like hardware tokens or biometrics provided by PAM modules. This integration is configured via the KbdInteractiveAuthentication directive in sshd_config, specifying pam as the device, and supports standards like U2F/FIDO for two-factor challenges passed through PAM environment variables. Key management in OpenSSH begins with key pair generation using the ssh-keygen utility, which creates private and keys in standard formats, typically storing the private key in ~/.ssh/id_<type> (e.g., id_ed25519) protected by a and the key in a corresponding .pub file. The key is then distributed to the target server and appended to the user's ~/.ssh/authorized_keys file, which lists authorized keys in a specific format for server-side verification during attempts. Host key verification ensures the server's identity by checking its key against the client's ~/.ssh/known_hosts file or /etc/ssh/ssh_known_hosts, preventing man-in-the-middle attacks by alerting users to unknown or changed keys. The ssh-agent daemon facilitates seamless key handling by securely storing unlocked private keys in memory, eliminating repeated passphrase entry across multiple sessions or hosts. Keys are added to the agent using ssh-add, and the agent authenticates on behalf of the user via environment variables like SSH_AUTH_SOCK. Agent forwarding, enabled with the -A option in ssh, extends this capability over SSH connections, allowing keys to be used on remote systems without direct exposure, but it includes restrictions such as prohibiting remote loading of or FIDO libraries by default to mitigate risks like key misuse if the remote host is compromised. Privilege separation, introduced in OpenSSH 3.2.2 (2002) and enabled by default since then, enhances by forking the sshd daemon into multiple processes with distinct privilege levels: a privileged monitor process oversees , while unprivileged child processes handle potentially vulnerable operations like input processing. This isolation limits the impact of authentication failures or exploits, as bugs in untrusted code cannot escalate to full system compromise, a design formalized in early implementations to contain privilege escalation risks. For enterprise-scale deployments, OpenSSH supports SSH certificates signed by a trusted (CA), enabling centralized key management without distributing individual public keys to every server. Certificates embed a public key, user identity, principals, and constraints like validity periods or command restrictions, generated via ssh-keygen -s with the CA's private key; servers verify them by trusting the CA's public key in sshd_config via TrustedUserCAKeys. This approach scales efficiently for large organizations by revoking certificates centrally rather than managing per-user keys.

Supported Key Types

OpenSSH supports a variety of for both host authentication and public key-based user authentication, enabling secure and verification within the SSH protocol. The primary types include RSA, ECDSA, and Ed25519, along with specialized security key (sk) variants for hardware-backed authentication. These are configured via options like PubkeyAcceptedAlgorithms in sshd_config, which lists acceptable algorithms by default as ssh-ed25519, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, [email protected], [email protected], rsa-sha2-512, and rsa-sha2-256 (plus certificate variants). RSA keys remain one of the most widely supported options in OpenSSH, utilizing the RSA algorithm with SHA-256 or SHA-512 signatures for compatibility with legacy systems. They are suitable for both host and user keys, providing robust in mixed environments. OpenSSH recommends generating RSA keys with at least 2048 bits for adequate security, though the default size for new keys is 3072 bits to align with current cryptographic standards. ECDSA keys employ the over NIST P-256, , and P-521 curves, supporting fixed key sizes of 256, 384, and 521 bits respectively. This allows for smaller key sizes than RSA while delivering equivalent or higher security levels, making ECDSA efficient for resource-constrained systems. The 256-bit variant (ecdsa-sha2-nistp256) is commonly used due to its balance of performance and security. Ed25519 keys, based on the Edwards-curve Digital Signature Algorithm, feature a fixed 256-bit key size and have served as the default for ssh-keygen since OpenSSH 6.5, released in January 2014. They offer strong resistance to side-channel attacks and are optimized for high-speed operations, combining compact keys with performance superior to traditional methods. Ed25519 is recommended for new deployments due to its modern design and broad compatibility. The DSA key type (ssh-dss), limited to 1024-bit keys, was deprecated in OpenSSH due to its vulnerability to certain attacks and insufficient security margins compared to contemporaries. It was disabled by default at runtime starting with OpenSSH 7.0 in 2015 and fully removed in OpenSSH 10.0, released in April 2025, to eliminate legacy risks. Security key variants, prefixed with "sk-", integrate hardware security modules like FIDO/U2F devices and were introduced in OpenSSH 8.2, released in February 2020. Supported types include sk-ecdsa-sha2-nistp256 (256 bits) and sk-ssh-ed25519 (256 bits), which bind keys to physical tokens for enhanced phishing resistance without relying on software-stored private keys. These are ideal for high-security environments requiring multi-factor authentication semantics.
Key TypeKey Sizes (bits)Approximate Symmetric Security EquivalentRelative PerformanceKey Advantages and Migration Notes
RSA2048+ (default 3072)112+ bits (for 2048-bit)ModerateExcellent compatibility; migrate to 3072+ bits from smaller legacy keys for future-proofing.
ECDSA256, 384, 521128, 192, 256 bitsGoodEfficient size-security trade-off; prefer 256-bit for general use over larger RSA.
Ed25519256 (fixed)~128 bitsFastestOptimal for speed and security; recommended default—transition from DSA or RSA for better efficiency.
sk-ECDSA/Ed25519256 (base)~128 bits + hardware bindingGoodPhishing-resistant; adopt for sensitive access alongside software keys.
Overall, Ed25519 provides the best combination of security, performance, and simplicity for most users, with its 256-bit keys achieving security comparable to much larger RSA equivalents while enabling faster authentication. Migration from deprecated DSA or undersized RSA is strongly advised to maintain robust protection against evolving threats.

Security

Known Vulnerabilities

OpenSSH has inherited several vulnerabilities from the original SSH-1 protocol, including weaknesses in its integrity checks such as the CRC-32 compensation attack, which allowed remote attackers to execute arbitrary code by exploiting an in the attack detection mechanism (CVE-2001-0144). This issue affected early OpenSSH versions supporting SSH-1, but was addressed in OpenSSH 2.3.0 released in early 2000 by disabling vulnerable components. Additionally, a weak generator in the sshd server (CVE-2008-5161) enabled attackers to recover up to 32 bits of plaintext from CBC-mode ciphertexts through error handling flaws, impacting versions using deprecated CBC ciphers. Privilege escalation vulnerabilities have also posed significant risks, notably a in the challenge-response handling of sshd (CVE-2002-0640), which permitted remote unauthenticated attackers to execute arbitrary code as by sending a large number of responses during in versions 2.3.1 through 3.3. This flaw was mitigated through the introduction of privilege separation in OpenSSH 3.2 in 2003, which sandboxed unprivileged processes to limit potential damage from such overflows. Information disclosure issues include a client-side vulnerability in the roaming feature (CVE-2016-0777), where malicious servers could trick OpenSSH clients in versions 5.4 through 7.1p1 into writing private keys to untrusted files or logging sensitive data like hostnames and usernames, potentially exposing credentials. This affected the default client configuration with roaming enabled, allowing remote servers to obtain sensitive information from process memory. More recent vulnerabilities highlight ongoing challenges in authentication and denial-of-service protections. In CVE-2025-26465, attackers could perform man-in-the-middle attacks via on systems with VerifyHostKeyDNS enabled in OpenSSH versions before 9.9p2, bypassing host key verification under specific network conditions. Similarly, CVE-2025-26466 introduced a pre-authentication denial-of-service in versions 9.5p1 through 9.9p1, where crafted packets could cause sshd to enter an , exhausting resources. CVE-2025-61984 affected versions before 10.1 by allowing control characters in untrusted usernames to inject commands via ProxyCommand expansion, potentially leading to remote code execution. Since its inception in 1999, OpenSSH has accumulated over 100 (CVEs), with the majority addressed in subsequent releases through timely patches. As of November 2025, no zero-day vulnerabilities in OpenSSH have been widely exploited in the wild.

Mitigation Strategies

To mitigate security risks in OpenSSH deployments, administrators should prioritize regular patching to the latest stable version, such as OpenSSH 10.2 released on October 10, 2025, which addresses recent vulnerabilities including those affecting ProxyCommand handling and DNS verification. Automated tools like unattended-upgrades on Debian-based systems can facilitate this by enabling automatic installation of security updates for OpenSSH packages, reducing exposure to known exploits through timely application of patches. Configuration hardening is essential for limiting attack surfaces; disabling password authentication in favor of key-based authentication only, via setting PasswordAuthentication no in /etc/ssh/sshd_config, prevents brute-force attempts on weak credentials. Restricting user access through Match blocks in sshd_config allows fine-grained controls, such as permitting only specific users or groups for SSH access, thereby enforcing least-privilege principles. Additionally, limiting ciphers to modern algorithms like AES-GCM by specifying Ciphers [email protected],[email protected],[email protected] in the configuration avoids deprecated modes such as CBC, which are vulnerable to certain padding oracle attacks. Effective monitoring involves analyzing SSH logs for signs of brute-force attacks, with integration of tools like Fail2Ban to automatically ban IP addresses after repeated failed login attempts by scanning /var/log/auth.log and applying rules. Verifying host public key s during initial connections, as prompted by the ssh client, ensures man-in-the-middle resistance by confirming the expected SHA256 or ED25519 against trusted sources. For advanced protections, configuring environments for SFTP-only users via ChrootDirectory and ForceCommand internal-sftp in sshd_config confines sessions to isolated directories, preventing broader system access even if credentials are compromised. Mandatory access controls like SELinux can further confine the sshd process by enabling booleans such as sshd_can_read_user_content_files and setting appropriate contexts on directories, while profiles restrict file access and network operations for the daemon. Regular rotation of SSH host and user keys, ideally every 90-180 days or after potential exposure, maintains and limits the impact of key compromise through generation of new key pairs and propagation via secure channels. In response to recent threats, disabling ProxyCommand expansions for CVE-2025-61984 by updating to OpenSSH 10.1 or later—or avoiding untrusted inputs in ProxyCommand configurations—prevents command injection via control characters in usernames. Similarly, enabling strict DNS resolution or disabling the VerifyHostKeyDNS yes option mitigates CVE-2025-26465, with patching to version 9.9p2 or newer providing comprehensive resolution against man-in-the-middle attacks during host key verification.

Deployment and Usage

Installation Methods

OpenSSH can be installed on various operating systems using platform-specific package managers, built-in tools, or by compiling from source. The choice of method depends on the target system, with most distributions providing pre-built packages for ease of deployment. On Debian-based Linux distributions such as Ubuntu, OpenSSH is installed via the Advanced Package Tool (APT) by running sudo apt update followed by sudo apt install openssh-server, which retrieves the package from the official Debian repositories. For Red Hat Enterprise Linux (RHEL) and derivatives like CentOS, the DNF or YUM package manager is used; for example, on RHEL 8 and later, execute sudo dnf install openssh-server to install from the enabled repositories. On Fedora, the process is similar with sudo dnf install openssh-server, ensuring the latest version from Fedora's repositories is obtained. For BSD variants like , OpenSSH is available as the openssh-portable package through the pkg tool; installation is performed with sudo pkg install openssh-portable, which pulls from the FreeBSD ports collection. On macOS, OpenSSH is included by default since early versions, and the server can be enabled by turning on Remote Login in the settings ( > General > in macOS 13 and later; System Preferences > in earlier versions), without requiring additional installation. Windows supports OpenSSH natively since Windows 10 version 1809 (October 2018 Update), where it can be added as an optional feature using with the command Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0, or through the Settings app under Apps > Optional features > Add a feature > OpenSSH Server. Alternatively, on (WSL), OpenSSH follows the Linux distribution's installation method, such as APT for on WSL. To install from source, download the latest portable release tarball from the official OpenSSH website at https://www.openssh.com/portable.html, extract it, and compile using the standard autotools sequence: ./configure, make, and sudo make install, assuming dependencies like OpenSSL and zlib are pre-installed. Post-installation verification involves checking the version with ssh -V to confirm the installed OpenSSH release, and for systems using systemd (common on Linux), querying the service status with systemctl status sshd to ensure the daemon is active and enabled.

Configuration Basics

OpenSSH configuration is managed through two primary files: sshd_config for the server daemon and ssh_config for the client. These files use a simple keyword-value format, where directives can be set globally or overridden in host-specific sections. Changes to sshd_config require restarting the SSH daemon to take effect, while client configurations apply immediately upon invocation of the ssh command. The server configuration file, typically located at /etc/ssh/sshd_config, controls the behavior of the sshd daemon. The Port directive specifies the listening port, with a default of 22; multiple Port lines can be specified to listen on more than one port. For example, setting Port 2233 configures the SSH service to listen on port 2233 instead of or in addition to the default. It is common to comment out or remove the default Port 22 line when using a custom port to reduce exposure to automated attacks. On Debian-based systems such as Ubuntu and Debian, to configure sshd to listen on a custom port (for example, 2233), perform the following steps:
  1. Edit the configuration file:

    sudo nano /etc/ssh/sshd_config

    sudo nano /etc/ssh/sshd_config

    Change or add the line:

    Port 2233

    Port 2233

    (Comment out or remove the default Port 22 if you do not want to keep listening on port 22.)
  2. Test the configuration for syntax errors:

    sudo sshd -t

    sudo sshd -t

    If no errors are reported, the syntax is valid.
  3. Restart the SSH service (note: on Ubuntu and Debian, the service is typically named ssh, not sshd):

    sudo systemctl restart ssh

    sudo systemctl restart ssh

  4. If UFW is enabled, allow the new port through the firewall:

    sudo ufw allow 2233/tcp sudo ufw reload

    sudo ufw allow 2233/tcp sudo ufw reload

  5. Verify that sshd is listening on the new port:

    sudo ss -tuln | grep 2233

    sudo ss -tuln | grep 2233

    or

    sudo netstat -tuln | grep 2233

    sudo netstat -tuln | grep 2233

Common reasons why connections to the custom port may fail include:
  • The SSH service was not restarted after making changes.
  • The firewall (UFW, iptables, firewalld, or a cloud provider's security group) is blocking the new port.
  • A syntax error exists in the sshd_config file (use sshd -t to check and journalctl -u ssh -xe to view logs).
  • Another process is already using port 2233.
  • The client command did not specify the custom port (use ssh -p 2233 user@host).
  • Existing connections on port 22 remain open after the restart, but new connections to port 22 will fail if Port 22 is no longer configured.
On Windows systems, including Windows 11, the default SSH port is 22, and the server configuration file is located at C:\ProgramData\ssh\sshd_config. To change the port on Windows 11, edit this file to uncomment or modify the Port line (e.g., Port 2222), restart the sshd service using PowerShell as Administrator with the command Restart-Service sshd, and update the Windows Firewall inbound rule to allow traffic on the new port. The ListenAddress directive defines the local IP addresses on which sshd binds, defaulting to all available addresses (0.0.0.0 and ::); an entry like ListenAddress 192.168.1.100 restricts it to a specific interface. PermitRootLogin governs root user access, defaulting to prohibit-password, which disables password-based logins for root while allowing public key authentication; setting it to no fully prohibits root logins. PubkeyAuthentication enables or disables public key-based authentication, defaulting to yes, as in PubkeyAuthentication yes. Common server directives include MaxAuthTries, which limits authentication attempts per connection to a default of 6 (e.g., MaxAuthTries 3 reduces it to prevent brute-force risks), and ClientAliveInterval, which sets the interval in seconds for sending keep-alive messages to the client if no data is received, defaulting to 0 (disabled); for instance, ClientAliveInterval 300 sends messages every 5 minutes. The client configuration file, usually at /etc/ssh/ssh_config or ~/.ssh/config, allows per-host customization. Host-specific blocks are defined with the Host keyword followed by a pattern, such as:

Host example.com IdentityFile ~/.ssh/id_rsa

Host example.com IdentityFile ~/.ssh/id_rsa

This applies settings only to connections to example.com. The IdentityFile directive specifies private key files for authentication, defaulting to ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ed25519, and others; multiple files can be listed for sequential trials. StrictHostKeyChecking controls verification of the server's host key, defaulting to ask, which prompts the user for new hosts; options include yes (strict verification, no auto-add) or no (auto-add without prompts), as in StrictHostKeyChecking no for automated scripts. By default, on the first invocation of sshd, host keys (such as RSA, ECDSA, and Ed25519) are automatically generated in /etc/ssh/ if they do not exist, using ssh-keygen internally. To apply changes to the server, restart the service using systemctl restart sshd on systemd-based systems like most modern Linux distributions. On Ubuntu and Debian, use systemctl restart ssh instead. On Windows, use Restart-Service sshd in PowerShell as Administrator. Client configurations can be tested with the ssh command's -o option to override settings temporarily, such as ssh -o StrictHostKeyChecking=no user@host to bypass host key checks for a single connection.

Community and Extensions

Licensing and Ports

OpenSSH's core codebase is released under a permissive BSD-style , allowing free use, modification, and distribution for any purpose, including commercial applications, provided that the original copyright notices and disclaimers are retained. Most components of the software fall under the 2-clause BSD , while certain elements derived from code are governed by the 3-clause BSD . The portable distribution of OpenSSH, designed for integration into non-OpenBSD operating systems such as , macOS, Windows, and various environments, maintains the same core licensing framework but incorporates additional permissive licenses for portability enhancements and replacement components. For instance, compatibility code in the openbsd-compat subdirectory includes elements under both 2-clause and 3-clause donated from other BSD projects, and optional dependencies like the zlib compression library operate under the , which permits unrestricted use with minimal attribution requirements. This model ensures broad compatibility without introducing obligations, as OpenSSH explicitly avoids any GPL-licensed code. The portable OpenSSH is developed and maintained as an independent project parallel to the base system version, with releases marked by a "p" suffix (e.g., 9.9p2) to distinguish them. While it tracks the official releases for feature synchronization, the portable variant receives separate bug fixes, platform-specific adaptations, and testing to support diverse environments, preventing disruptions to the core implementation. This separation facilitates widespread adoption across operating systems while preserving the security-focused development of the original. Development of OpenSSH, including both the core and portable versions, relies on volunteer contributions from a dedicated team of developers associated with the project, with no formal barriers to participation beyond code quality and security standards. Funding for these efforts is secured through donations to the OpenBSD Foundation, a non-profit organization that supports OpenSSH alongside other OpenBSD subprojects, enabling hackathons, infrastructure, and developer stipends without imposing commercial restrictions on the software's use or redistribution.

Integrations and Alternatives

OpenSSH seamlessly integrates with version control systems such as , enabling secure authentication via SSH keys for cloning, pushing, and pulling repositories over encrypted channels. In cloud environments, it facilitates secure access through tunneling mechanisms; for instance, AWS IoT Core leverages OpenSSH-compatible SSH tunneling to establish between local clients and remote devices without exposing ports publicly. Similarly, Azure Bastion acts as a proxy for SSH connections to virtual machines, allowing users to connect via the Azure portal or native SSH clients while maintaining secure, audited sessions. OpenSSH's dynamic , exemplified by the ssh -D option, creates proxies that serve as lightweight alternatives to full VPN setups for routing traffic through remote hosts. Within automation ecosystems, OpenSSH serves as the default transport for tools like , which relies on SSH connections to managed nodes for executing playbooks and configuring systems without requiring agent installation on targets. Chef, another configuration management platform, similarly employs OpenSSH for remote execution during infrastructure provisioning and compliance checks. For enhanced mobile and intermittent connectivity, Mosh integrates with OpenSSH by using it for initial and UDP-based , providing responsive terminal sessions that predictively update displays even under network disruptions. As an open-source implementation, OpenSSH contrasts with proprietary alternatives like Tectia SSH, which offers enterprise-grade features including 24/7 support, centralized management, and specialized editions for zero-trust and quantum-safe environments, though at the cost of licensing fees. Dropbear provides a lightweight alternative optimized for resource-constrained embedded systems, with a smaller binary size and reduced dependencies compared to OpenSSH's fuller feature set, making it ideal for routers and IoT devices. Libssh, an API-focused C library, enables developers to embed SSH client and server capabilities directly into applications, offering greater programmatic control than OpenSSH's command-line tools but requiring custom integration. OpenSSH's strengths lie in its widespread auditability due to open-source code, fostering community-driven enhancements, while its weaknesses include the absence of dedicated commercial support and built-in graphical interfaces—users often pair it with tools like for Windows-based GUI access. Looking ahead, OpenSSH is preparing for post-quantum threats through hybrid algorithms; since version 9.0 (April 2022), it defaults to post-quantum key agreement with sntrup761x25519-sha512, and version 10.0 (April 2025) adopts mlkem768x25519-sha256 as the primary method to resist quantum attacks on classical .

References

  1. https://www.openssh.com/
  2. https://www.openssh.com/history.html
  3. https://www.openssh.com/manual.html
  4. https://www.openssh.com/releasenotes.html
  5. https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/7/html/system_administrators_guide/ch-openssh
  6. https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh-overview
  7. https://man.openbsd.org/ssh.1
  8. https://man.openbsd.org/scp.1
  9. https://man.openbsd.org/sftp.1
  10. https://man.openbsd.org/sshd.8
  11. https://man.openbsd.org/ssh-keygen.1
  12. https://man.openbsd.org/ssh-agent.1
  13. https://man.openbsd.org/ssh-add.1
  14. https://man.openbsd.org/ssh-keyscan.1
  15. https://man.openbsd.org/ssh_config.5
  16. https://man.openbsd.org/sshd_config.5
  17. https://www.ssh.com/about/history/
  18. https://undeadly.org/cgi?action=article;sid=20070926182742
  19. https://www.openssh.com/press.html
  20. https://www.openbsd.org/26.html
  21. https://www.openssh.com/goals.html
  22. https://www.openssh.com/openbsd.html
  23. https://www.openssh.com/portable.html
  24. https://www.openssh.com/specs.html
  25. https://datatracker.ietf.org/doc/html/rfc8731
  26. https://www.openssh.com/pq.html
  27. https://datatracker.ietf.org/doc/html/rfc5647
  28. https://www.openbsd.org/openssh/releasenotes.html
  29. https://www.openssh.com/security.html
  30. https://man.openbsd.org/ssh-keygen.1#certificates
  31. https://www.openssh.com/txt/release-6.5
  32. https://goteleport.com/blog/comparing-ssh-keys/
  33. https://nvd.nist.gov/vuln/detail/CVE-2001-0144
  34. https://nvd.nist.gov/vuln/detail/CVE-2008-5161
  35. https://nvd.nist.gov/vuln/detail/CVE-2002-0640
  36. https://nvd.nist.gov/vuln/detail/CVE-2016-0777
  37. https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt
  38. https://nvd.nist.gov/vuln/detail/CVE-2025-61984
  39. https://forum.cloudron.io/topic/12028/automatic-linux-update-openssh-cve-2024-6387
  40. https://serverfault.com/questions/691294/should-i-enable-automatic-security-updates-on-a-ubuntu-server
  41. https://www.cyberciti.biz/faq/how-to-disable-ssh-password-login-on-linux/
  42. https://www.cyberciti.biz/tips/linux-unix-bsd-openssh-server-best-practices.html
  43. https://www.sshaudit.com/hardening_guides.html
  44. https://dev.to/sebos/complete-guide-to-fail2ban-protect-your-ssh-server-from-brute-force-attacks-3m3l
  45. https://codenotary.com/blog/how-to-block-brute-force-attacks-on-ssh
  46. https://infosec.mozilla.org/guidelines/openssh
  47. https://www.thegeekstuff.com/2012/03/chroot-sftp-setup/
  48. https://access.redhat.com/solutions/3600431
  49. https://www.wiz.io/vulnerability-database/cve/cve-2025-61984
  50. https://www.upwind.io/feed/openssh-vulnerabilities-cve-2025-26465-and-cve-2025-26466-enable-man-in-the-middle-and-dos-attacks
  51. https://www.vicarius.io/vsociety/posts/cve-2025-26465-mitigate-vulnerable-openssh
  52. https://docs.fedoraproject.org/en-US/fedora/f40/system-administrators-guide/infrastructure-services/OpenSSH/
  53. https://www.freshports.org/security/openssh-portable
  54. https://support.apple.com/guide/mac-help/allow-a-remote-computer-to-access-your-mac-mchlp1066/mac
  55. https://learn.microsoft.com/en-us/windows-server/administration/openssh/openssh_install_firstuse
  56. http://man.openbsd.org/sshd_config
  57. http://man.openbsd.org/ssh_config
  58. http://man.openbsd.org/ssh.1
  59. https://docs.oracle.com/en/servers/management/ilom/5.1.x/enterprise-license-guide/openssh.html
  60. https://github.com/openssh/openssh-portable
  61. https://www.openssh.com/donations.html
  62. https://www.openbsdfoundation.org/donations.html
  63. https://learn.microsoft.com/en-us/azure/devops/repos/git/use-ssh-keys-to-authenticate
  64. https://docs.aws.amazon.com/iot/latest/developerguide/secure-tunneling.html
  65. https://www.ssh.com/products/tectia-ssh/
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.