Bitvise SSH Server Version History  

Changes in Bitvise SSH Server 7.16:    [ 5 December 2016 ]

  • Fixed a race condition that could result in a crash of the main SSH Server process under a specific set of conditions, when clients use server-to-client port forwarding.
  • Due to the nature of the issue fixed in this release, this version contains an upgrade amnesty. Any Bitvise SSH Server activation code that could activate a previous 7.xx version will also activate version 7.16.

Changes in Bitvise SSH Server 7.15:    [ 4 September 2016 ]

  • Updated EULA to make more explicit our licensing and support policies. The policies themselves remain unchanged.
  • Fixed an issue which caused the SSH Server's settings description in textual log files to include all settings fields. It now again properly records only fields that differ from defaults.

Changes in Bitvise SSH Server 7.14:    [ 3 August 2016 ]

  • SSH implementations have a chance of generating RSA signatures slightly smaller than expected with a small probability (e.g. 1:200). Windows CNG has been found to not validate such signatures as presented. With our software versions 7.12, this has resulted in occasional connection or login attempt failures. Our SSH Server, SSH Client, and FlowSsh now re-encode RSA signatures, so that smaller-than-expected ones can verify correctly.
  • Windows CNG, as used by our new cryptographic provider in versions 7.xx, has been found to return an incorrect signature size for odd-sized RSA keys (e.g. for 1023-bit or 2047-bit keys). Most SSH implementations do not generate odd-sized RSA keys, but there are old versions of PuTTY which do (e.g. version 0.62). Our SSH Server, SSH Client, and FlowSsh now take steps to support generating and validating signatures using such keys.
  • Certain implementations (e.g. OpenSSH version 7.2, but not 7.2p2) have been found to encode RSA signatures using the new signature methods rsa-sha2-256 and rsa-sha2-512 in a way that is not compatible with the specification of these methods. For compatibility, our SSH Server, SSH Client, and FlowSsh will now accept these alternate signature encodings.
  • Our SSH Server, SSH Client, and FlowSsh now have improved Windows error reporting, distinguishing NTSTATUS error messages from those associated with HRESULT.
  • In the SSH Server's scriptable configuration COM object, BssCfgManip, use of the OmitDefaults enumeration has been replaced with ShowDefaults, which is more intuitive. The two enumerations are binary compatible (0 omits defaults, 1 shows them). A definition for OmitDefaults remains included.
  • Improved detection of newly applied activation codes to avoid situations that would require the SSH Server service to be restarted for a new activation code to take effect.
  • When reinstalling the SSH Server as Personal Edition, it is now possible to re-enter different personal details for activation.

Changes in Bitvise SSH Server 7.12:    [ 25 June 2016 ]

  • Cryptography:
    • Important: DSA keys larger than 1024 bits are no longer supported. The implementation of these keys in Bitvise software pre-dated the NIST standard for large DSA keys, and was incompatible both with the NIST standard and other implementations that might use it. In general, support for the DSA algorithm is being deprecated by SSH implementations. For interoperability with older SSH installations, we continue to support 1024-bit DSA keys, but we recommend migrating either to 3072-bit RSA, or ECDSA.
    • On Windows Vista, Windows Server 2008, and newer, our software now uses a new cryptographic provider, CiWinCng, which uses built-in Windows cryptography. This provider adheres to FIPS 140-2 requirements as long as FIPS mode is enabled in Windows security policy. In FIPS mode, ECDSA and ECDH are supported with curves nistp256, nistp384 and nistp521, but not with curve secp256k1 because this curve is not implemented in Windows. When FIPS mode is disabled in Windows, the curve secp256k1 remains available (implemented using Crypto++).
    • On Windows XP and Windows Server 2003, our software continues to use our previous cryptographic provider, which uses the Crypto++ 5.3.0 DLL. This DLL was FIPS-certified, but its certificate has been moved to the historical list due to changed random number generator requirements since January 1, 2016.
    • When using the new CiWinCng cryptographic provider - default on all recent Windows versions - the encryption/integrity algorithms aes256-gcm and aes128-gcm are now supported. Our implementation is interoperable with the OpenSSH implementation of these algorithms.
    • New RSA signature algorithms rsa-sha2-256 and rsa-sha2-512 are now supported for host authentication.
    • The EXT_INFO extension negotiation mechanism is now supported, allowing for the use of new RSA signature algorithms rsa-sha2-256 and rsa-sha2-512 for client authentication.
    • On initial installation, the SSH Server will now generate two default host keys: 3072-bit RSA, and ECDSA over the curve nistp384. This replaces ECDSA/nistp256 as the default curve for the ECDSA host key, to match recent NSA recommendations about key strength.
  • SSH:
    • The SSH Server will now disable gssapi-keyex authentication if Kerberos authentication is disabled. In previous versions, it was necessary to also disable NTLM authentication in order to disable gssapi-keyex.
    • The default logon type for Windows groups is now Network, instead of Interactive. This addresses a common support case where non-administrator users cannot log in because the Windows security privilege "Log on locally" is not granted in the Windows security policy. As is true in general for changes to default settings, this does not affect upgraded settings or settings imported from previous versions, but does affect new installations and new groups created in Advanced settings.
  • BvShell:
    • Bitvise SSH Server now supports a new terminal shell access type: BvShell. This is a command-line shell provided by the SSH Server which does not provide full access to the Windows filesystem, but instead limits a user's access to mount points configured for the user in SSH Server settings. The shell supports basic Unix and Windows commands, and allows users to access the SSH Server's virtual filesystem in ways that may not be supported by the user's SFTP or SCP client; for example, global search of file content, or file copy.
    • In previous versions, WinSCP was able to connect to Bitvise SSH Server when used in SFTP mode, but not in SCP mode. Now, the SSH Server will automatically activate BvShell when WinSCP opens a terminal session, allowing WinSCP to function in SCP mode.
  • Terminal:
    • Addressed a compatibility issue with Comodo Internet Security which would cause 64-bit processes to not run in an SSH terminal session on recent Windows versions.
    • The Telnet forwarder utility that has been included in recent SSH Server versions is now fully integrated as a shell access type in Advanced SSH Server settings. This allows an administrator to replace the SSH Server's terminal subsystem so as to instead forward access to an existing Telnet server.
    • The terminal subsystem now properly handles Alt, Shift, Ctrl + F1-F4 escape sequences in xterm.
    • The terminal subsystem now recognizes alternative Shift + F3-F10 escape sequences as sent by PuTTY.
  • File transfer:
    • The SSH Server now properly supports getting and setting Windows file attributes using an SFTP client that supports this.
    • Virtual filesystem mount points now support delayed initialization. Previously, when a user had a large number of mount points mapped to network shares, the connections to the network shares were all initialized at the beginning of the file transfer session. This could cause delays in session initialization. Each mount point provider is now initialized the first time it is accessed.
    • In recent SSH Server versions, the setting "Load profile for SCP and SFTP" has been disabled by default for virtual accounts. It is now disabled by default for Windows accounts also. Windows has issues related to profile loading, and it is best to disable it for file transfer. Normally, a profile only needs to be loaded for terminal shell access, so that programs can be run which require the current user's profile to function.
    • The SFTP protocol contains a legacy "long name" field which is mostly not used by graphical clients or by automated clients, but is used to display directory listings by a number of command line clients. There is now a new setting in Advanced settings, SFTP display time format, which can be used to change the date and time format sent as part of this field.
    • The On-upload command now supports an additional environment variable, SSHUPLOADENDBY, which can have values CLIENT or CLEANUP. The script executed by the On-upload command can use this information to decide whether a transfer was fully completed (value CLIENT), or if it was most likely terminated prematurely (value CLEANUP).
  • Port forwarding:
    • In Advanced settings, it is now possible to configure a listening rule so as to override the listening interface requested by the client with a server-configured listening interface (and optionally, port).
    • It is now possible to configure free-form listening rules that can match any textual interface requested by the client, including DNS names, as well as names that are not a valid DNS name or IPv4/6 address (such as Unix sockets). This is intended to be used together with a listening interface override to specify a valid interface on which to listen (previous bullet).
    • IPv4 and IPv6 listening rules have now been merged into a single list, which also supports the new free-form rules.
  • Logging:
    • Improved consistency of event timestamps on computers where Windows current time functions may return inconsistent values.
  • Control Panel and Settings:
    • Usability improvements in Easy and Advanced settings: saving of dialog sizes when minimized or maximized; improved support for multi-monitor environments; treatment of default values in Easy settings.
    • The default virtual filesystem layout for virtual accounts is now Limit to root directory instead of allowing full filesystem access.
    • A virtual account password can now be cleared (to "not set" state) even if password complexity requirements are configured.
    • The SSH Server will now display a more useful message on the Activity tab if a client connects but cannot establish an SSH session because the client and the server do not have any common algorithms that are supported or enabled.
    • The contents of hidden fields that are not currently in effect are no longer displayed in list columns when editing or viewing settings.
    • SSH Server settings may contain sensitive information, such as proxy authentication passwords or passwords to access network shares. For fields where this is possible, such as virtual account passwords, the information has always been stored irreversibly. For fields where the information must be decrypted, past versions stored it encrypted using a static key that could be decrypted on any computer. Now, the SSH Server will encrypt such sensitive configuration fields using a key that is available only to administrators on the SSH Server computer. To export settings that contain sensitive information for import on another computer, a password can now be provided during export which must be provided to decrypt settings on import.
    • When editing a temporary IP blocking entry, the old entry will now be removed if the IP address is changed.
    • Previously, when a list of client address rules included a DNS name rule, this rule would cause connections to be rejected when they arrived from an IP address for which a reverse DNS lookup did not succeed. In this case, the DNS name rule could not be evaluated, and the response was to always reject the connection in this case. It is now possible to configure, for each DNS rule, what should happen if the rule cannot be evaluated because DNS lookup failed. The default action is now to ignore the rule and proceed with any subsequent rules.
    • The SSH Server Control Panel will no longer try to create or delete its auto-start task when the -noRegistry flag is passed on the command line.
  • Scriptable/textual configuration:
    • The SSH Server's textual configuration has been completely revamped. The structure of the settings and the operations supported remain mostly the same. However, when accessing settings using the BssCfgManip COM object, each settings structure can now be accessed as a separate COM object instead of having to compose text strings and pass them to ProcessInstruction or QueryValue. This allows SSH Server settings to be managed much more naturally using PowerShell or VBScript.
    • As part of the textual configuration changes, the Query tab is no longer available in Advanced settings. Instead, it is now possible to use the SSH Server Control Panel to open a PowerShell window which can be used to query or change settings.
    • The BssCfg commands exportText and importText continue to be supported. These commands now support exporting and importing settings in a textual format which is a subset of PowerShell syntax which can now be used to configure SSH Server settings.
    • A virtual account password can now be cleared (to "not set" state) using the scriptable/textual configuration interface.
    • Host authentication public keys can now be exported programmatically using BssCfgManip in the SSH2 and OpenSSH formats.
    • The SSH Server installation now includes PowerShell scripts VirtAccountExporter.ps1 and VirtAccountImporter.ps1, allowing for export and import of basic virtual account entries to and from CSV (comma-separated values) files. The scripts can be extended to support additional fields in a custom CSV format.
  • Master/slave synchronization:
    • A slave can now be configured to connect to a master that uses SSH protocol obfuscation.
    • Instance type settings (master/slave configuration) have been moved from the Windows registry to the Config subdirectory of the SSH Server installation directory, where the main SSH Server settings and host keypairs reside.
  • General:
    • In previous versions, in domain environments, the SSH Server would retrieve user information from Active Directory using default parameters, which would cause results to be sent from the domain controller to the SSH Server computer without encryption. The SSH Server will now use ADSI using Kerberos sealing by default. It is now also possible to enable a TLS (SSL) connection to Active Directory in Advanced settings, if available in the domain environment.
    • The SSH Server should now support authentication with domain accounts in domains with an Active Directory name different from their DNS name.
    • The SSH Server should now work in cluster environments where the virtual server name of the cluster computer is different from the physical computer name.
    • Versions 6.4x targeted the SSE2 instruction set, which caused them to not run on old computers lacking support for SSE2. Versions 7.xx now target the SSE instruction set, which allows for compatibility with old CPUs, at the cost of a small performance penalty - in our measurements, between 0 and 0.5%.

Older Versions

Bitvise SSH Server 6.xx Version History

Bitvise SSH Server 5.xx Version History

WinSSHD 4.xx Version History

WinSSHD 3.xx Version History