Bitvise SSH Server Version History  

Changes in Bitvise SSH Server 7.31:    [ 3 May 2017 ]

  • This is not a new feature release, but a successor to 7.29 with continued maintenance updates. (We skip over versions containing zeros to avoid ambiguities. For example, 7.03 and 7.30 might both be referred to as "7.3".)
  • Small changes in key places improve CPU efficiency on the order of 30% (impact may depend on the system). This improves transfer speeds where CPU is the bottleneck – or maintaining same performance, allows for a greater number of simultaneous connections. Users who were previously maxing out a single core and seeing transfer speeds of e.g. 150 MB/s, may now see e.g. 200 MB/s.
  • Versions 7.xx introduced encryption of SSH Server settings using a machine-specific encryption key stored in the Windows registry. Past versions stored this encryption key without a trailing null, and did not properly handle a trailing null if it was added by another application (e.g. when manually importing the registry value). The encryption key is now stored with a trailing null when first generated, and any trailing null is stripped when reading the encryption key.

Changes in Bitvise SSH Server 7.29:    [ 31 March 2017 ]

  • A usage pattern for Bitvise SSH Server is to provide an SFTP blind drop. This is a virtual filesystem mount point that removes permissions such as Permit List and Permit Read Existing, and allows only Permit Read/Write/Delete New.

    In recent versions, a blind drop configuration has worked with command line clients. However, the SSH Server was interpreting permissions strictly, causing problems for graphical clients, including Bitvise SSH Client and WinSCP.

    This version slightly relaxes permissions required for SFTP operations such as SSH_FXP_REALPATH and SSH_FXP_STAT, so that graphical clients can be effective in this scenario.

    An effect of this change is that it is now possible to probe for a file's existence using the SSH_FXP_STAT request. However, in current versions, our SSH Server does not support transparently renaming files uploaded into a blind drop. It is therefore possible to probe for a file's existence in any case, by attempting to upload the file.

Changes in Bitvise SSH Server 7.28:    [ 13 March 2017 ]

  • Fixed an issue in BvShell which, under specific conditions, could cause it to become unresponsive in a tight loop with high CPU usage.
  • This version contains an upgrade amnesty. Any Bitvise SSH Server activation code that could activate a previous 7.xx version will also activate this version. This allows upgrade for users who can use the BvShell fix.
  • Reimplemented the workaround for older versions of the Renci.SshNet library. This works around another bug in these library versions that was not avoided by the measures introduced in 7.26.

Changes in Bitvise SSH Server 7.27:    [ 2 March 2017 ]

  • Fixed an issue which would cause an SFTP session to terminate abruptly if the client attempted to set the size of a file using an SSH_FXP_SETSTAT request (specifying a path, rather than a handle to the file).

Changes in Bitvise SSH Server 7.26:    [ 7 February 2017 ]

  • Fixed two issues related to the SSH Server Control Panel, introduced with version 7.21:
    • Exporting a single server host keypair in Bitvise format, using the Manage host keys interface, would result in a corrupted file. (Multiple key export worked fine.)
    • In the Remote SSH Server Control Panel; on the Statistics tab; if Update list was clicked with the option Detailed enumeration enabled; the Remote SSH Server Control Panel would close due to a protocol error caused by incorrect message encoding in the SSH Server. Fixed.
  • Changes to BssCfg settings importText:
    • After implementing changes to the textual settings format in versions 7.xx, the command BssCfg settings importText would no longer report a non-zero exit code if the import failed. This command now again returns a non-zero exit code on failure.
    • The command BssCfg settings importText would previously display warnings if certain types of input could not be interpreted. These warnings are now treated as errors.
    • As a result of these changes, the signature of the methods ImportTextSettingsFrom... in the BssCfgManip COM object has changed. There is no longer a list of warnings returned. Conditions that used to trigger a warning now trigger an error.
  • Implemented a workaround for older versions of the Renci.SshNet client library. These versions conflate local and remote maximum channel packet sizes, which can lead the SSH Server to send a larger packet than the SshNet library accepts. The workaround limits the largest packet size the SSH Server will send to 33,500 for all current and past Renci.SshNet versions. It will not affect future versions if the library increments the SSH product version it sends.

Changes in Bitvise SSH Server 7.25:    [ 22 January 2017 ]

  • Fixed an issue causing corruption of file paths used in the SSHUPLOADFILE environment variable in the On-upload command, and paths used for file transfer activity reporting in the SSH Server Control Panel. This issue was introduced in version 6.41.

Changes in Bitvise SSH Server 7.24:    [ 14 January 2017 ]

  • File transfer subsystem compatibility improvements:
    • Some filesystem drivers; including StableBit DrivePool; do not properly implement asynchronous directory listings. For better compatibility, the SSH Server now again uses synchronous directory listings.
    • Improved robustness of handling FSTAT and FSETSTAT requests on directory handles with non-NTFS filesystems (including FAT and CDFS).
  • When the uninstaller detects that a file is still in use, it can now display the names of applications keeping the file open. (Requires Windows Vista or later.)

Changes in Bitvise SSH Server 7.23:    [ 10 January 2017 ]

  • Recent SSH Server versions use a new way of listing directories that improves consistency of virtual filesystem accesses. This release implements a compatibility fix for non-standard filesystem drivers that may signal an end of directory listing using STATUS_NO_SUCH_FILE instead of STATUS_NO_MORE_FILES.
  • In master/slave environments where there are slaves running on Windows XP or Windows Server 2003, it will now no longer be necessary to disable AES-GCM algorithms on the master in order for master/slave synchronization to work. (During any master/slave upgrade, slaves need to be upgraded first. For this fix to be effective, only the slaves need to be upgraded.)

Changes in Bitvise SSH Server 7.22:    [ 3 January 2017 ]

  • We have identified an issue where, when optimizing for speed under normal Release build settings, Visual Studio unexpectedly generates extraordinarily large stack frames for functions that create many short-lived temporary objects. On some versions of Windows, the footprint of some generated functions could cause the SSH Server to stop due to stack exhaustion under normal operating conditions. We have taken several steps, including splitting up largest offenders, reducing the use of inlining, and changing optimization settings, to ensure the issue is avoided.

Changes in Bitvise SSH Server 7.21:    [ 31 December 2016 ]

  • Cryptography:
    • On Windows Vista, Windows Server 2008, and newer, our SSH Server, SSH Client, and FlowSsh now support server and client public key authentication using Ed25519, and ECDH key exchange using Curve25519. These algorithms are not available when Windows is running in FIPS mode.
    • We have updated support for OpenSSH private keys, so that our software is now able to import and export them in their new format as introduced by OpenSSH in December 2013.
    • Our SSH Server, SSH Client, and FlowSsh now support Diffie Hellman key exchange with 3072-bit and 4096-bit fixed groups, using SHA-512 as the exchange hash; and with the 2048-bit fixed group using SHA-256 as the exchange hash.
    • In SSH Server's Advanced settings, under Algorithms > Key Exchange, the minimum and maximum group size for Diffie Hellman group exchange can now be configured. The SSH Server continues to support only fixed groups. By default, the minimum is 2048 bits, and the maximum is 3072 bits. Therefore, either group 14 (2048-bit) or group 15 (3072-bit) will be used with group exchange algorithms.
  • General:
    • Improved detection and reporting - via log files and the SSH Server Control Panel - for clients that connect with incorrect obfuscation settings.
    • Fixed an issue which would cause the SSH Server to remove and re-add Windows firewall rules unnecessarily when retrying to synchronize main SSH Server listening sockets (bindings).
    • Previously, the SSH Server initialized its listening sockets with a low backlog value of 5. When the accept delay threshold was met, for protection against too many incoming connections, the SSH Server would allow the backlog to fill, causing Windows to refuse additional connections. This was causing problems under heavy load, when there were a large number of simultaneous connections, but the accept delay threshold was not met. Therefore, the SSH Server now uses a large backlog value, and actively clears connections - accepts and closes them immediately - when the accept delay threshold is met.
    • Other listening sockets used by the SSH Server, such as for server-to-client port forwarding, now also use a large backlog value to reduce the likelihood of connections being refused.
    • When upgrading, the uninstaller will now automatically retry moving files that are still in use for a brief period before prompting.
  • Master/slave synchronization:
    • When slaves are configured to not maintain a persistent connection, but reconnect on a periodic basis, slaves will now hold off on reconnecting if unsuccessful. Previous behavior was to enter a state where slaves kept trying to reconnect on a short delay. If a master went down and was unavailable to all slaves for a period of time, this would cause an accidental denial of service effect on the master when it was returned online.
    • Secondary masters are now assigned ranks to help avoid cyclical configurations.
    • Added slave option to Keep local settings for Logging.
  • Delegated settings:
    • The SSH Server now supports delegated settings. In Advanced settings, an administrator with full access to SSH Server settings can configure specific Windows or virtual accounts so that they can view and edit specific, limited aspects of SSH Server functionality and settings. Functionality that can be made accessible to delegated administrators includes:
      • Limited virtual account management.
      • Server host key management.
      • Viewing of session information.
      • Temporary blocking of IP addresses.
    • In order to access delegated SSH Server settings, users who are given access must connect to the SSH Server using Bitvise SSH Client, and use the Bitvise SSH Server Control Panel feature in the SSH Client. It is currently only possible to access delegated SSH Server settings via our SSH Client.
  • Settings:
    • The SSH Server Control Panel will now display a dialog box to warn the administrator if they attempt to import a client authentication public key that cannot be used due to current settings configured under Advanced settings > Algorithms > Signature.
    • If a new account was created in Easy settings, group mount points were not properly copied to the new account settings entry. Fixed.
    • Under Advanced settings > Session, the setting IP blocking - lockout time is now expressed in minutes instead of seconds. On new installations, the default lockout period is now 3 hours instead of 1 hour.
    • Account and group settings entries now have a Comment field. This field can be left empty, or can be set by an administrator to an arbitrary description of a user or group settings entry.
  • Logon:
    • Since versions 5.5x, our SSH Server has supported passwordless creation of logon sessions for Windows accounts that use public key authentication, or for virtual accounts that use a custom security context, where the password for the Windows account has not been entered in the SSH Server's password cache. This feature is made possible using a custom authentication package, which can only be loaded by Windows at system startup. In past versions, upgrading the SSH Server often required a system restart to restore passwordless logon functionality. This feature has been rearchitected so that fewer restarts will be required for future upgrades. Because of the depth of the changes, upgrading to version 7.21 will require a system restart in order for passwordless logon to work.
    • We have revised in-depth the Windows APIs we use to obtain Windows account information, and eliminated as much as possible older APIs that rely on less secure SMB-based protocols in domain environments. In modern environments, the SSH Server should now require only an LDAP (ADSI) connection to the domain controller. This means that all communication with the DC will be secured by default using Kerberos sealing. SMB-based protocols will now only be used for passwordless logon in legacy environments where the domain controller is Windows Server 2000.
    • The speed of LDAP (ADSI) queries performed by the SSH Server has been much improved. The SSH Server now connects to the DC in a way that avoids unnecessary NetBIOS lookups; ADSI connections are cached to improve performance; and the SSH Server avoids retrieving information it does not need. A passwordless logon to a Windows domain account should now be as fast as a logon with a password.
    • A new account and group setting, Session setup > On failure to obtain account info, now controls what should happen if the SSH Server can log the user in successfully, but cannot obtain information from Windows such as the location of the user's profile directory. In this case, environment variables such as %HOME% are likely to be set incorrectly. This may lead to security issues if sensitive settings, such as a Real root path, depend on such environment variables. For existing groups, previous behavior is preserved, which is No restrictions. For new groups, default behavior is now more conservative, and is set to Disable access to child processes.
  • File transfer:
    • Since versions 6.2x, our SSH Server has supported filename pattern whitelists and blacklists for the virtual filesystem used by SFTP, SCP, and BvShell. This feature has been split into separate file and directory blacklists. For example: the SSH Server can now be configured to allow access to a directory with a name that fits a pattern such that access would not be permitted if it was instead a file.
    • The main virtual filesystem provider used by SFTP, SCP, and BvShell has been rearchitected to improve consistency of filesystem operations. All operations that can be performed on file handles are now performed on file handles (instead of paths).
    • Improved handling of requests to change file attributes. Addressed issues where: the Read-only attribute would prevent enabling Sparse, or changing Compression or Encryption; the System attribute would prevent enabling Encryption; and changing Compression and Encryption at the same time could fail.
    • Advanced mount point settings provide a new setting, Delay initialization until accessed. This setting is enabled for new mount points by default, so that users who configure many mount points that are expensive to initialize (e.g. file shares) will not experience delays when a client connects for file transfer. However, the setting can be disabled so that mount points will be initialized immediately. This can be useful e.g. for users who rely on Create real root path to create directories on login.
    • Advanced mount point settings provide a new setting, File sharing behavior. This can be used to specify whether the SSH Server should use the configured file sharing mode always (even if the SFTP client requests a different file sharing mode), or only if the SFTP client does not indicate a file sharing preference (which is the case for many clients).
    • An SFTP client can now remove a symbolic link to a directory with the regular SSH_FXP_REMOVE message (in addition to SSH_FXP_RMDIR). This allows a symbolic link to a directory to be removed using clients that were previously not able to remove it (including graphical SFTP in our SSH Client).
  • Personal Edition:
    • The SSH Server Personal Edition can now be used on domain controllers. In this case, only domain accounts that are part of the domain controller's own domain can be used. Otherwise - when installed on a domain member - the restriction remains in place that only local Windows accounts (and virtual accounts) may be used.
    • It is now possible to change licensed-to information for the Personal Edition by uninstalling and reinstalling.

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.

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%.

Known Issue

  • Windows XP: All versions of our software that we recommend using are built using Visual Studio 2015. The C++ run-time library used by this Visual Studio version has a known issue where 1-2 kB of memory are leaked each time a new thread is created. This issue does not occur on later Windows versions; it does not occur e.g. on Windows Server 2003. Microsoft has stated they do not intend to fix this issue. Bitvise's view is that the impacts on our SSH Client and FlowSsh are manageable; whereas our SSH Server is rarely used on Windows XP. We therefore do not plan to work around this; but we warn that this can be a potential denial of service vector on Windows XP.

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