Our software implements SSH version 2, SFTP versions 3, 4, and 6, SCP and FTPS according to publicly available standards. In addition, our software supports minor extensions documented here.
Bitvise SSH Server, SSH Client and our library FlowSshC/Cpp/Net use Bitvise's SSH protocol implementation, FlowSsh. Our software implements the following standards:
- 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 4256: Generic Message Exchange Authentication for the Secure Shell Protocol (SSH)
- RFC 4419: Diffie-Hellman Group 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 4819: Secure Shell Public Key Subsystem
- RFC 5656: Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
- RFC 6668: SHA-2 Data Integrity Verification for the Secure Shell (SSH) Transport Layer Protocol
- 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
In addition, our software implements:
- draft-ietf-curdle-ssh-kex-sha2-10: Key Exchange (KEX) Method Updates and Recommendations for Secure Shell (SSH)
- draft-ietf-curdle-ssh-curves-08: Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448
- firstname.lastname@example.org: SSH key exchange using Curve25519
- OpenSSH "PROTOCOL" document: email@example.com and firstname.lastname@example.org; Host key update and rotation
- draft-ssh-ext-auth-info-01: Extended authentication information in Secure Shell (SSH)
- draft-ssh-global-requests-ok-00: Sending and Handling of Global Requests in Secure Shell (SSH)
- draft-miller-secsh-compression-delayed-00: Delayed compression à la email@example.com. Contains an inherent race condition; the mechanism in RFC 8308 is newer, but preferred.
- The PROXY protocol, v1 and v2: A mechanism for a non-transparent gateway to communicate the client's IP address at the start of the TCP connection.
SFTP is the native SSH file access protocol. SFTP version 3 can be thought of as an RPC (remote procedure call) mechanism for a generic Unix-based filesystem. Later SFTP versions, 4–6, include additional features and accommodations for non-Unix filesystems.
When the SSH protocol was being standardized, SFTP was being standardized with it. A schism developed when Unix-based developers rejected further development of SFTP beyond version 3, while others insisted on better support for non-Unix filesystems. As a result, no version of SFTP could be standardized by consensus.
Bitvise SSH Server, SSH Client and FlowSshC/Cpp/Net implement the following drafts, which de-facto specify SFTP:
- draft-ietf-secsh-filexfer-02: SFTP version 3
- draft-ietf-secsh-filexfer-04: SFTP version 4
- draft-ietf-secsh-filexfer-13: SFTP version 6
- draft-ietf-secsh-filexfer-extensions-00: SFTP extensions
- OpenSSH "PROTOCOL" document: SFTP v3 extensions and OpenSSH idiosyncrasies
The check-file-blocks extension:
When using SFTP version 6, Bitvise SSH Server also advertises the check-file-blocks extension. This is because with versions 7.35, we found server implementations that support the check-file extensions, but either did not support block-by-block hashing (VShell) or would disconnect if a larger file was hashed block-by-block (mod_sftp for ProFTPD). This prevented the functioning of file content synchronization in Bitvise SSH Client and FlowSsh.
We suggest that SFTP servers advertise support for check-file-blocks if all of the following are true:
- The server supports block-by-block file hashing.
- Any reasonable block size requested by the client is supported.
- A file can be hashed block-by-block starting from an arbitrary offset.
SCP is an informal protocol originally based on the Unix utility rcp. Bitvise SSH Server implements SCP in a manner intended to be compatible with all significant SCP clients we are aware of.
Some SCP clients, notably WinSCP, require an SCP server to provide a Unix-like shell. Bitvise SSH Server implements BvShell – a dedicated Shell access type setting which provides a hybrid Unix/Windows-style shell. This shell is part of the SSH Server and respects file access limits configured for the user in the SSH Server's virtual filesystem. If enabled for a user, BvShell supports WinSCP in SCP mode, as well as other SCP clients which expect not only SCP, but also a Unix-style shell.
Bitvise SSH Client and FlowSshC/Cpp/Net do not implement SCP - only SFTP over SSH.
Historically, the FTP protocol is not based on a secure design, but it is possible to implement it securely. Bitvise SSH Server implements FTP over TLS/SSL in a manner that emphasizes security at the expense of compatibility with less secure clients. For more information, please see Bitvise SSH Server: Compatibility with FTPS Clients.
Bitvise SSH Client and FlowSshC/Cpp/Net do not implement FTPS - only SFTP over SSH.
Bitvise SSH Server implements time-based one-time passwords as specified in RFC 6238 – TOTP: Time-Based One-Time Password Algorithm.
The SSH Server Control Panel can export a TOTP secret key as a 2D code image by encoding the secret key URI as specified in the Google Key Uri Format. The URI is encoded as an image as specified in ISO/IEC 18004 – QR Code bar code symbology specification.
Bitvise SSH Client and FlowSshC/Cpp/Net implement the following as part of (A) outgoing SSH connections through a SOCKS or HTTP CONNECT proxy, and (B) dynamic TCP connection forwarding:
- socks4.protocol: SOCKS 4
- socks4a.protocol: SOCKS 4A
- RFC 1928: SOCKS Protocol Version 5
- RFC 2817: Upgrading to TLS Within HTTP/1.1 – the HTTP CONNECT verb
The purpose of the bvterm terminal protocol is to provide a quality of Windows terminal experience that cannot always be achieved with other terminal protocols such as xterm.
On Windows, character based applications receive keyboard input and render their output in a Windows Console. bvterm 2.xx is based on the Windows Console API. It may be loosely viewed as a Windows Console API remote procedure call protocol.
The current bvterm version is 2.0. This version is supported by:
- Bitvise SSH Server versions 5.xx and newer.
- Bitvise SSH Client versions 4.25 and newer.
bvterm2-20101019.txt - last updated: 2010-10-19