- 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 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
- RFC 4419 - Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol
- RFC 4716 - The Secure Shell (SSH) Public Key File Format
- RFC 5208 - Public-Key Cryptography Standards (PKCS) #8 - version 1.2
- RFC 5480 - Elliptic Curve Cryptography Subject Public Key Information
- 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 5915 - Elliptic Curve Private Key Structure
- RFC 5958 - EncryptedPrivateKeyInfo
- RFC 6668 - SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol
- RFC 8160 - IUTF8 Terminal Mode in Secure Shell (SSH)
- RFC 8268 - More Modular Exponentiation (MODP) Diffie-Hellman (DH) Key Exchange (KEX) Groups for Secure Shell (SSH)
- RFC 8308 - Extension Negotiation in the Secure Shell (SSH) Protocol
- Note: - the code contains hooks for implementing the RFC and
also provides default client and server implementation for
server-sig-algs
extensions.
- Note: - the code contains hooks for implementing the RFC and
also provides default client and server implementation for
- RFC 8332 - Use of RSA Keys with SHA-256 and SHA-512 in the Secure Shell (SSH) Protocol
- Note: - the server side supports these signatures by default. The client side requires specific initialization - see section 3.3 and also the above mentioned hooks for RFC 8308.
- RFC 8731 - Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448
- Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
- OpenSSH support for U2F/FIDO security keys
- Note: the server side supports these keys by default. The client side requires specific initialization
- OpenSSH public-key certificate authentication system for use by SSH
- OpenSSH 1.9 transport: strict key exchange extension
- (Some) OpenSSH SFTP extensions
Note: some implementations may be limited to client-side - i.e., we provide a capability for the client to detect if the server supports the extension and then use it, but our server does not publish it as being supported.
Section | Extension | Client | Server |
---|---|---|---|
4.3 | [email protected] |
Yes | Yes |
4.4 | [email protected] |
Yes | Yes |
4.4 | [email protected] |
Yes | Yes |
4.5 | [email protected] |
Yes | Yes |
4.6 | [email protected] |
Yes | Yes |
4.7 | [email protected] |
Yes | Yes |
4.8 | [email protected] |
Yes | Yes |
4.10 | copy-data |
Yes | Yes |
supported
- DRAFT 05 - section 4.4supported2
- DRAFT 13 section 5.4versions
- DRAFT 09 Section 4.6vendor-id
- DRAFT 09 - section 4.4acl-supported
- DRAFT 11 - section 5.4newline
- DRAFT 09 Section 4.3md5-hash
,md5-hash-handle
- DRAFT 09 - section 9.1.1check-file-handle
,check-file-name
- DRAFT 09 - section 9.1.2copy-file
,copy-data
- DRAFT 00 - sections 6, 7space-available
- DRAFT 09 - section 9.2filename-charset
,filename-translation-control
- DRAFT 13 - section 6 - only client side
- SSH proxy jumps
- Endless tarpit - see HOWTO(s) section.
- hostbased, publickey, OpenSSH host-based public-key, keyboard-interactive, password
- aes128cbc, aes128ctr, aes192cbc, aes192ctr, aes256cbc, aes256ctr, arcfour128, arcfour256, blowfish-cbc, [email protected], [email protected], [email protected], 3des-cbc
- md5, sha1, sha224, sha256, sha384, sha512
- hmacmd5, hmacmd596, hmacsha1, hmacsha196, hmacsha256, hmacsha512, [email protected] , [email protected], [email protected]
- diffie-hellman-group1-sha1, diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha1, diffie-hellman-group14-sha256
, diffie-hellman-group15-sha512, diffie-hellman-group16-sha512, diffie-hellman-group17-sha512, diffie-hellman-group18-sha512
, ecdh-sha2-nistp256, ecdh-sha2-nistp384, ecdh-sha2-nistp521, curve25519-sha256, [email protected], curve448-sha512
- On Java versions before Java 11, Bouncy Castle is required for curve25519-sha256, [email protected], or curve448-sha512.
- none, zlib, [email protected]
- ssh-dss, ssh-rsa, rsa-sha2-256, rsa-sha2-512, nistp256, nistp384, nistp521
, ssh-ed25519 (requires
eddsa
optional module), [email protected], [email protected] , [email protected], [email protected], [email protected] , [email protected], [email protected], [email protected]
Note: The above list contains all the supported security settings in the code. However, in accordance with the latest recommendations the default client/server setup includes only the security settings that are currently considered safe to use. Users who wish to include the unsafe settings must do so explicitly. The following settings have been deprecated and are no longer included in the default setup:
- RFC 8758 - Deprecating RC4 in Secure Shell (SSH)
- RFC 8429 - Deprecate Triple-DES (3DES) and RC4 in Kerberos
- While it refers to Kerberos, it mentions weaknesses in DES as well.
- OpenSSH release notes - usually a good indicator of de-facto practices
- SHA-1 based key exchanges and signatures
- MD5-based and truncated HMAC algorithms
- RFC 8270 - Increase the Secure Shell Minimum Recommended Diffie-Hellman Modulus Size to 2048 Bits Note: it still possible to use 1024 by initializing the value programmatically or via system property - see Security providers setup. The code still contains moduli for 1024 and will use them if user explicitly lowers the default minimum to it.
Caveat:: According to RFC 8332 - section 3.31
Implementation experience has shown that there are servers that apply authentication penalties to clients attempting public key algorithms that the SSH server does not support.
When authenticating with an RSA key against a server that does not implement the "server-sig-algs" extension, clients MAY default to an "ssh-rsa" signature to avoid authentication penalties. When the new rsa-sha2-* algorithms have been sufficiently widely adopted to warrant disabling "ssh-rsa", clients MAY default to one of the new algorithms.
This means that users that encounter this (and related) problems must modify the supported security settings explicitly in order to avoid the issue.
Special notice: ssh-rsa
was left in as part of the default setup since there are still a lot of systems / users
using it. However, in future version it will be removed from the default. We therefore strongly encourage users to migrate
to other keys (e.g. ECDSA, ED25519) as soon as possible.