2.3. Compatibility
2.3.1. Internet Standards
2.3.1.1. Secure Shell Protocol (SSH)
The following Request for Comments (RFC) define SSHv2 as an Internet Standard:
RFC 4250, The Secure Shell (SSH) Protocol Assigned Numbers
RFC 4251, The Secure Shell (SSH) Protocol Architecture
RFC 4252, The Secure Shell (SSH) Authentication Protocol
RFC 4253, The Secure Shell (SSH) Transport Layer Protocol
RFC 4254, The Secure Shell (SSH) Connection Protocol
RFC 4255, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints [*]
RFC 4256, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
RFC 4335, The Secure Shell (SSH) Session Channel Break Extension
RFC 4344, The Secure Shell (SSH) Transport Layer Encryption Modes
RFC 4345, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol
It was later modified and expanded by the following RFCs:
RFC 4419, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
RFC 4432, RSA Key Exchange for the Secure Shell (SSH) Transport Layer Protocol
RFC 4462, Generic Security Service Application Program Interface (GSS-API) Authentication and Key Exchange for the Secure Shell (SSH) Protocol
RFC 4716, The Secure Shell (SSH) Public Key File Format
RFC 5647, AES Galois Counter Mode for the Secure Shell Transport Layer Protocol
RFC 5656, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
RFC 6187, X.509v3 Certificates for Secure Shell Authentication [‡]
RFC 6594, Use of the SHA-256 Algorithm with RSA, DSA, and ECDSA in SSHFP Resource Records [§]
RFC 6668, SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol
RFC 8270, Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits
RFC 8308, Extension Negotiation in the Secure Shell (SSH) Protocol [♠]
RFC 8332, Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol
RFC 8709, Ed25519 and Ed448 Public Key Algorithms for the Secure Shell (SSH) Protocol [♥]
RFC 8758, Deprecating RC4 in Secure Shell (SSH)
RFC 9142, Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)
RFC 9212, Commercial National Security Algorithm (CNSA) Suite Cryptography for Secure Shell (SSH) [♦]
RFC 9941, Secure Shell (SSH) Key Exchange Using Hybrid NTRU Prime sntrup761 and X25519 [♣]
2.3.1.2. Secure Shell File Transfer Protocol (SFTP)
The protocol is not an Internet standard, but it is still widely used. OpenSSH and most others implement version 3 of the protocol.
Starting with version 20.05 we do support all defined versions from 3 to 6 in suSSHi as defined in:
draft-ietf-secsh-filexfer-02.txt, SSH File Transfer Protocol Version 3
draft-ietf-secsh-filexfer-04.txt, SSH File Transfer Protocol Version 4
draft-ietf-secsh-filexfer-05.txt, SSH File Transfer Protocol Version 5
draft-ietf-secsh-filexfer-13.txt, SSH File Transfer Protocol Version 6
2.3.1.3. Key Algorithms
suSSHi supports post quantum key exchange algorithms
The following post quantum key exchange algorithms are supported by suSSHi:
mlkem768x25519-sha256,mlkem768nistp256-sha256,mlkem1024nistp384-sha384— defined in the IETF draft draft-ietf-sshm-mlkem-hybrid-kex (currently at revision 10, still an Internet-Draft, not yet a finalized RFC as of April 2026)sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com— defined in a separate draft draft-ietf-sshm-ntruprime-ssh
suSSHi supports Curve25519 key exchange
The canonical algorithm name curve25519-sha256 was standardized by RFC 9142;
the legacy curve25519-sha256@libssh.org identifier (originally a libssh/OpenSSH extension) remains supported for backwards compatibility.
curve25519-sha256, Curve25519-SHA256 for ECDH KEX (standardized in RFC 9142)curve25519-sha256@libssh.org, legacy alias (libssh/OpenSSH extension)
2.3.1.4. Secure Shell Extensions
OpenSSH defines a number of extensions to the SSH protocol, which are widely supported by SSH clients and servers.
- OpenSSH’s Deviations And Extensions
- Fully Supported by suSSHi
Protocol 2 compression algorithm
zlib@openssh.comTransport: Elliptic Curve cryptography
SFTP protocol changes / extensions
Channel write close extension
eow@openssh.comDisallow additional sessions extension
no-more-sessions@openssh.com
- OpenSSH’s SSH Agent
Fully supported by suSSHi.
- OpenSSH’s Hostkey Update And Rotation Feature
Fully supported by suSSHi for gateway host key update to client.
- OpenSSH’s SFTP Extensions
Fully supported by suSSHi.
- OpenSSH’s Unix Domain Socket Forwarding
Fully supported by suSSHi.
2.3.2. Compatible Clients
suSSHi is RFC-compliant to the highest degree and therefore requires no special SSH client. All RFC-compliant SSH clients should work with suSSHi without any problems.
While the suSSHi Gateway is “only” an SSH server from the client’s point of view, we only require that the gateway user, the target user and the actual target are encoded in the SSH username using a separator (different are possible, default is @).
Note
We would like to point out that the software and hardware designations and trade names referenced here are subject to general brand, trademark or patent protection.
The following list of clients is known to work fully compatible with suSSHi:
OpenSSH for Windows (included in Windows 10 and 11)
PuTTY / SuperPuTTY and all PuTTY based clients
… and yes, the list is still incomplete and potentially all SSH clients should work without limitations.
2.3.3. Compatible Servers
The same applies to the servers as to the clients: From the target server’s view, the suSSHi Gateway is just a client, so all RFC-conform servers should work without any problems.
The following list of servers is known to work fully compatible with suSSHi:
OpenSSH for Windows (included in Windows 10 and 11)