For issues that might arise using the latest SSH Server versions, see Known issues.
Security Notification: [ 27 October 2019 ]
Authors of the Minerva attack have identified a small but significant timing information leak in the Crypto++ implementation of ECDSA over prime field curves. This attack may allow discovery of a private key through repeated observation of signature timing. If the leak can be utilized, an attacker could compromise a server host key or a client authentication key using a practical number of connections across a network.
The following is the impact on Bitvise SSH Server, SSH Client and FlowSsh versions before 8.36:
On all recent Windows versions (Vista and higher), there is no effect on users of Bitvise software versions 7.xx and 8.xx who use private keys of algorithms RSA, Ed25519, or ECDSA over the NIST curves nistp256, nistp384 or nistp521. On all recent versions of Windows, and using recent Bitvise software versions, these algorithms use Windows cryptography, which is unaffected by Minerva. In the case of Ed25519, we similarly use a non-Crypto++ implementation, which is unaffected.
On all versions of Windows, using all versions of Bitvise software, the Minerva issue may apply to users who generated, and are using, host keys or client keys of type ECDSA/secp256k1. Bitvise software versions 8.35 and earlier use Crypto++ to implement this algorithm on all platforms. We encourage such users to update to our latest software versions.
On Windows XP and Windows Server 2003, regardless of Bitvise software version; and for Bitvise software versions 5.xx and 6.xx, regardless of Windows version; the Minerva issue may apply to users of ECDSA private keys of any type. We encourage such users to update to our latest software versions, and/or to update to newer versions of Windows.
With Bitvise SSH Server, SSH Client and FlowSsh 8.36, we are releasing the following mitigations:
On all recent Windows versions (Vista and higher), where we previously used Crypto++ to support ECDSA/secp256k1, we are switching to alternatives. If the version of Windows is recent enough (for example, Windows 10, Windows Server 2016 and 2019), our default cryptographic provider (CiWinCng) now uses Windows cryptography to support ECDSA/secp256k1 as well as ECDH/secp256k1. Where Windows does not support secp256k1 (for example, Windows Vista to 8.1 and Windows Server 2008 to 2012 R2), we now support it using OpenSSL.
On Windows XP and Windows Server 2003, we face the issue that maintained cryptographic libraries that continue to support these platforms are hard to switch to and harder to find, while the number of users is small and diminishing. In current versions, we continue to rely on Crypto++ on these platforms, but implement mitigations to make it harder or impossible to observe signature timing across the network.
On all versions of Windows, we continue to use Crypto++ to support non-standard DSA keys. These are DSA keys as used in SSH of size other than 1024 bits. Since versions 7.xx, we have discouraged the use of DSA keys of any size. Also, DSA is not within scope of the Minerva research, so the current attack does not apply directly. Nevertheless, because we use Crypto++ to support non-standard DSA keys on all platforms, we now activate mitigations for these keys to make it harder or impossible to observe signature timing remotely.
Changes in Bitvise SSH Server 8.36: [ 27 October 2019 ]
On Windows 10, Windows Server 2016 and 2019, the algorithms ECDSA/secp256k1 and ECDH/secp256k1 now use Windows cryptography. As a result, these algorithms are now also available when FIPS mode is enabled in Windows.
On Windows Vista to 8.1, and Windows Server 2008 to 2012 R2, the algorithms ECDSA/secp256k1 and ECDH/secp256k1 now use OpenSSL instead of Crypto++. As a side effect, use of these algorithms on Windows Vista now requires at least Service Pack 1 (OpenSSL will fail to initialize on Vista without service packs).
On Windows XP and Windows Server 2003, our software continues to use Crypto++ for all algorithms, but implements mitigations to make it harder or impossible to observe signature timing remotely. Continuing support for these Windows versions is increasingly impractical for multiple reasons including cryptography. Like Microsoft and other software vendors have done, we will need to stop supporting these platforms eventually, but we still support them right now.
Fixed an issue in the SSH Server's terminal subsystem where, using the new Windows 10 console, a cursor position reset would not cancel delayed line wrapping. This was apparent with PowerShell input line wrapping - a second line would incorrectly show characters from the first line.
User feedback identified a client - SmarTerm - which doesn't properly handle global requests, and advertises itself as OpenSSH version 3.5p1 (an OpenSSH version that's 17 years old). To address this, we raise the criterion for OpenSSH client global request compatibility from version 3.1 to include version 3.5.
Changes in Bitvise SSH Server 8.35: [ 20 August 2019 ]
Fixed an issue in Easy settings where any additional port bindings previously configured in Advanced settings would be removed when Easy settings was saved.
For newly created mount point settings entries, the default File sharing setting now prohibits simultaneous write access by other processes. Read and delete access remain allowed by default.
This changes default behavior to prevent a subtle failure where another process – a task or file transfer session – can corrupt a file while it is being uploaded. As a side effect, configurations that require write sharing – for example, to perform a hot-copy of a database – now must modify the File sharing setting in Advanced settings for newly created mount points.
Already configured mount points will continue to function without change.
Fixed an issue where the mount point setting File sharing behavior did not take effect as configured, but in most cases took effect as if it was set to Default.
The 3DES encryption algorithm has known weaknesses, is rarely needed for compatibility, and now triggers warnings in some vulnerability scanners. In newly created settings, the SSH Server now disables the algorithm 3des-ctr by default. (The older, related algorithm, 3des-cbc, has additional weaknesses and has already been disabled by default since version 6.41.)
Fixed an issue in Telnet forwarding as configured by setting Shell access type to Telnet server. Telnet sub-negotiation was being handled incorrectly and could cause the terminal session to hang.
The Manage certificates interface now supports viewing the public key associated with a private key entry which does not yet have an associated certificate.
Changes in Bitvise SSH Server 8.34: [ 17 June 2019 ]
The SSH Server Control Panel now shows more accurate login failure descriptions on the Activity tab. In previous 8.xx versions, detailed information was available in the SSH Server's textual log files, but the Activity tab displayed only a base description for an entire error class. This description was often inaccurate and misleading: "The supplied user name could not be looked up."
Improved logging when password-less logon to a Windows domain account fails in a way that is most likely caused by insufficient Active Directory permissions.
There exist interim, but deployed versions of SSH implementations including SmartFTP which implement the no-flow-control extension based on a previous, non-final draft where the extension value was empty. Bitvise SSH Server, SSH Client and FlowSsh will now no longer disconnect when receiving an unrecognized no-flow-control extension value, but will attempt to continue; and will now treat an empty value as if the remote party sent "p" (for "preferred").
Improved logging of Warning and Trace-level events related to Windows profile loading.
Changes in Bitvise SSH Server 8.33: [ 28 May 2019 ]
Previous 8.xx versions would not trim leading and trailing spaces from client-provided user names on the basis that technically, such accounts could be configured in Windows. In practice, there are effectively no users who want to use usernames like that, but there are clients that unknowingly send usernames with leading or trailing spaces. The SSH Server will now trim leading and trailing spaces from user names, including Unicode spaces.
An added difficulty was that the SSH Server would trim the spaces from user names when logging them, but not when looking them up. This would make it difficult to realize that extra spaces were the reason login did not work.
Improved logging for two types of ADSI errors where the underlying issue is that the SSH Server lacks necessary permissions in the Active Directory. The errors would manifest as:
ADsOpenObject(user, Kerberos) failed: COM error 0x80072030: There is no such object on the server.
IADsUser::Get(msDS-User-Account-Control-Computed) failed: COM error 0x8000500D: The property cannot be found in the cache.
Check Using Bitvise SSH Server in a domain for more information about the Active Directory permissions needed.
SSH: Very old PuTTY versions before 0.58 are now treated as not global-request capable. When these versions are waiting for a channel open confirmation, they will treat any packet other than a channel open confirmation as a failure (including if the packet is a global request).
If synchronization with authorized_keys was enabled, and a user was logged off due to changed settings no longer permitting login, a null pointer read would occur. Fixed. The issue did not have consequences besides logging an error.
SCP: Reduced superfluous logging of I_SFS_GET_FILE_STATUS due to an internal event at the start of an SCP command.
Installation and upgrade:
In previous 8.xx versions, when upgrading from WinSSHD 4.xx and earlier (last such version was released in November 2008), users who should be limited to a specific directory would be incorrectly granted unlimited filesystem access. Fixed.
Automatic updates would fail for instances with non-normalized names (for example, names containing dots). Fixed. Users of affected instances may still need to manually update to this version or later by directly running the new version installer.
Added some verbosity in the installer, in particular to help diagnose situations where an antivirus might prevent the installer from launching a child process. This can prevent an installation or an update from completing.
The SSH Server EULA received a minor update to clarify the meaning of Machine. The meaning remains consistent with our current and past licensing practice.
Changes in Bitvise SSH Server 8.32: [ 18 April 2019 ]
The fix for the server-stopping issue in version 8.31 introduced a new issue where keyboard-interactive authentication would always fail if the setting Penalty login attempt delay was set to 0 seconds. Fixed.
The keyboard-interactive method is used for two-factor authentication using time-based one-time passwords (TOTP). It is also preferred by some clients as a way to perform password authentication.
DNS name rules now permit DNS names with underscores in any position where an alphanumeric character was previously valid. This accommodates users with internal host names that contain underscores (not otherwise valid on the internet).
SSH Server Control Panel: Fixed an issue which prevented a CSV file from being imported if it consisted of a single line without a line terminator.
Changes in Bitvise SSH Server 8.31: [ 15 April 2019 ]
This is not a new feature release, but a successor to 8.29 with continued maintenance updates.
We skip versions containing zeros to avoid misunderstandings. For example, 8.03 and 8.30 might both be called "8.3".
Fixed an issue where, given specific timing and combination of logon attempts, it was possible for the SSH Server to stop in an unplanned but controlled manner due to an unexpected condition.
Fixed a memory safety issue which seems to be hard to trigger, but could have security ramifications.
Added error descriptions for Windows error codes related to checking for new versions and downloading updates.
Fixed an issue where the password authentication failure reason AuthMethodDisabledGlobally was logged incorrectly as AuthMethodDisabledByClientVersion, and the other way around.
When exporting an OTP secret key as a 2D code image in monochrome bitmap format (1 bit per pixel BMP), an all-black image would be generated. Fixed.
Changes in Bitvise SSH Server 8.29: [ 23 March 2019 ]
The next Windows 10 update 19H1 is bringing a new terminal console incompatibility which would prevent the SSH Server's terminal subsystem from starting. This version addresses the issue.
Changes in Bitvise SSH Server 8.28: [ 15 March 2019 ]
Fixed an issue in previous 8.xx versions where, if an SSH Server instance configured as a slave or secondary master was upgraded from a version before 8.xx, it failed to create an update-related registry key. This caused an SSH Server thread to spin indefinitely with high CPU consumption.
The Sessions tab in the SSH Server Control Panel would incorrectly display an account type for connections that have not yet authenticated. Fixed.
The right-click pop-up menu on the Sessions tab to select session view columns was missing an option for IP location. Fixed.
File transfer: On drive letter root directories, such as C:\, Windows enables the attributes System + Hidden ("super-hidden"). The SSH Server will now remove these two attributes on drive letter root directories in stat requests and directory listings.
Changes in Bitvise SSH Server 8.27: [ 4 March 2019 ]
When using terminal modes other than bvterm, the SSH Server would previously generate the following keys as if they were coming from the numeric keypad: arrow keys, Insert, Delete, Home, End, Page Up, Page Down. These keys will now appear to programs running under SSH Server terminal emulation as if they are coming from dedicated (enhanced) keys.
Changes in Bitvise SSH Server 8.26: [ 22 February 2019 ]
Fixed issue introduced in version 8.22 where the Persistent Tray Icon setting would no longer function correctly in situations with multiple concurrently installed instances.
Changes in Bitvise SSH Server 8.25: [ 18 February 2019 ]
When a session was rejected because a configured Client version rule did not permit the client software version, the connection was kept around until a user authentication timeout expired instead of being disconnected immediately. Fixed.
Changes in Bitvise SSH Server 8.24: [ 26 January 2019 ]
Fixed installation and startup issues when there are instances named Bitvise SSH Server - WinSSHD or WinSSHD - Bitvise SSH Server and similar variants.
The LIST command can now also list an individual file path instead of only a directory.
A LIST command like LIST -al *.txt will now be interpreted as intended.
Directory listings returned by the LIST command will now have symbolic links resolved.
The OPTS UTF8 command is now supported.
Improved error reporting regarding certificate management.
To avoid unnecessary complications with re-verifying self-signed FTPS certificates, new self-signed certificates will now have a validity of 15 years.
Installation will now continue instead of failing when generation of a self-signed certificate fails. If the administrator wishes to use FTPS, a certificate can be generated later.
Fixed a number of BvShell corner case behaviors, especially related to text reading and command parsing.
Improved SCP exit code handling and use of the correct code page.
The ls command now supports the parameters -A and --almost-all.
The mkdir command now ignores the -p and --parents parameters instead of rejecting them. The default filesystem provider already creates parent directories by default.
When settings are changed locally, any reversibly encrypted passwords will no longer be re-encoded to avoid the logging of spurious diff segments. For the time being, when settings are changed remotely - using the SSH Server Remote Control Panel via Bitvise SSH Client - spurious diff segments related to passwords will still occur.
Reduced unnecessary logging of the Info-level log event I_LOGON_TOKEN_ELEVATION_CHANGE_FAILED.
Reduced unnecessary Info-level log events resulting from internal FTPS handling.
Changes in Bitvise SSH Server 8.22: [ 21 December 2018 ]
A trivial UI change in 8.21 prevented saving a group or account settings entry in Advanced settings if a mount point was configured with Allow unlimited access and its Real root path was empty. Fixed.
In addition to the fix in 8.21 to support filesystems mounted using the Windows Client for NFS, this version implements a further workaround for SetFileInformationByHandle, so that attributes such as file times can be correctly set.
Our testing indicates that Client for NFS filesystems should now again work well with Bitvise SSH Server.
The new 8.xx -certificates=... parameter for the SSH Server installer did not work. Fixed.
If the SSH Server Control Panel was run by a non-administrative user (requires disabling UAC), it would display a difficult-to-understand error. In this case, the SSH Server Control Panel will now display a more understandable message. If the SSH Server Control Panel was scheduled to run when the user logged in, the scheduled task will now also be removed.
When the SSH Server communicates a textual disconnect reason to a client; and a more accurate numeric disconnect reason is available than SSH_DISCONNECT_BY_APPLICATION; the SSH Server will now send the more accurate reason code.
Changes in Bitvise SSH Server 8.21: [ 17 December 2018 ]
In past versions, when using default settings for logging, the SSH Server would record its entire settings in the textual log file each time they were changed while the SSH Server was running. To improve readability of changes, and to reduce log spam on servers with large settings, the SSH Server will now record difference comparisons between old and new settings.
The Windows feature Client for NFS, used to mount network filesystems, does not support a file attribute operation on which the SSH Server has been relying since version 7.21. With filesystems mounted via Client for NFS, subdirectory traversal would fail with an error involving GetFileInformationByHandleEx and FileAttributeTagInfo. The SSH Server now implements a workaround for this issue.
A further workaround is necessary for SetFileInformationByHandle in order to correctly set attributes such as file times. We plan to release this in version 8.22.
Since versions 8.xx, Bitvise SSH Server and Client support an important new feature, host key synchronization. This allows a supporting client to automatically roll over to new server host keys without requiring manual configuration.
Host key synchronization requires clients – all that connect, including those that do not implement host key sync – to accept global requests. Almost all clients do – this is what RFC 4254 requires. Our users have identified clients which, in violation of the SSH protocol, disconnect when they receive a global request.
We have reports of the following SSH version strings sent by clients with this behavior:
- "WeOnlyDo" – older versions, but new ones send the same version info
- Ancient OpenSSH: clients older than version 3.1 (released 2002 – 2004)
To accommodate these clients, SSH Server 8.21 now implements a whitelist of clients which can handle global requests. For now, global requests will not be sent to clients not on the whitelist. In a future version, this will be configurable.
With versions 8.xx, the SSH Server Control Panel switched to newer, nicer Windows UI elements for dialogs such as exporting settings. It turns out these UI elements are unavailable on Windows Server Core. The SSH Server Control Panel will now detect Windows Server Core and use older versions of UI elements.
This may not resolve all issues on Windows Server Core. Administrators may need to use the BssCfg command line configuration utility or PowerShell scripting.
For FTPS clients, the SSH Server will now close the control connection if password authentication is not available or no longer available.
To improve compatibility with the vCenter SCP client, BvShell now responds to test -r and test -w in addition to previously supported test -d and test -f parameters.
The SSH Server implements further improvements to automatic IP blocking.
In previous 8.xx versions, the SSH Server would not import RSA private and public keys larger than 8192 bits. This limit is once again 16384 bits.
The SSH Server installer will now offer to wait instead of exiting when another Bitvise installation is already in progress.
Slightly improved the user friendliness of the installer and uninstaller for command-line installations.
We are receiving occasional inquiries about whether our software is affected by the libssh vulnerability CVE-2018-10933, where a client can bypass authentication by sending an SSH_MSG_USERAUTH_SUCCESS message to the server.
Bitvise software does not share common code with libssh. Our understanding is that the libssh issue arises due to commingling of authentication state for server-side and client-side purposes. In Bitvise software, authentication state is managed in separate client-side and server-side components. The server-side authentication component is not affected by this issue and will ignore any SSH_MSG_USERAUTH_SUCCESS message sent by the client.
Changes in Bitvise SSH Server 8.19: [ 18 November 2018 ]
In previous 8.xx versions, FTPS connections would fail incorrectly as if password authentication was globally disabled, even when it was not. Fixed.
In previous 8.xx versions, the automatic IP blocking feature could sometimes block an IP address prematurely. Fixed.
The BssCfg help paging can now be exited.
Changes in Bitvise SSH Server 8.18: [ 7 November 2018 ]
With versions 8.xx, the SSH Server implements major improvements to memory concurrency which allow it to more efficiently handle large numbers of simultaneous connections. This is incompatible with Application Verifier - a Windows quality assurance component used for debugging. The SSH Server will now disable some memory optimizations if it detects it's running under the Application Verifier, so it can run on systems where this is (potentially accidentally) enabled.
In previous 8.xx versions, if the system clock was moved back after a check for updates (in UTC, not time zone specific), an automatic check would be repeated with high frequency. This could consume 80 kbps in bandwidth until the clock caught up. Fixed.
In file transfer, the SSH Server supports atomic and non-atomic rename/move. Non-atomic move works as a copy + delete and is used when files are moved across SSH Server's virtual filesystem mount points, or across Windows filesystems. Non-atomic move is implemented in two ways, one way using Windows (for moves within the same SSH Server mount point) and another way in the SSH Server itself (for moves across mount points). The type of move used across SSH Server mount points is now more consistent with non-atomic move performed by Windows. The destination file size is now set when starting the copy, and the destination file is now locked for reading and writing until the copy is complete.
Changes in Bitvise SSH Server 8.17: [ 3 November 2018 ]
Fixed an issue in previous 8.xx versions where an SSH Server thread could hang and prevent the server from accepting further connections.
Fixed an issue in previous 8.xx versions where the terminal subsystem did not properly handle console input for applications which rely on the Windows ReadFile function to receive interactive input.
Improved SFTP rename compatibility with OpenSSH by allowing the extended request email@example.com to perform non-atomic renames.
Changes in Bitvise SSH Server 8.16: [ 29 October 2018 ]
In version 8.15, the SSH Server Control Panel had an issue where the Sessions tab did not show IP addresses for port forwarding channels (tunneled connections). Fixed.
Changes in Bitvise SSH Server 8.15: [ 25 October 2018 ]
The SSH Server can now accept incoming file transfer connections using FTPS. This is the FTP protocol over TLS (SSL). This is in addition to SFTP and SCP, which are the file transfer protocols associated with SSH, which the SSH Server has always supported.
Only authenticated and encrypted FTP connections over TLS (SSL) are supported. To work with Bitvise SSH Server, an FTPS client must support explicit TLS (using the AUTH TLS command), must use FTP passive mode, and must use TLS resume functionality for data connections. The SSH Server receives FTP data connections at the same port as control connections.
Unlike the SSH protocol, where our own Bitvise implementation is used, the SSH Server uses the Windows implementation of TLS (Schannel). Therefore, available TLS versions and configurations depend on the version of Windows on which the SSH Server is used. All versions of Windows that are in support by Microsoft will work. However, we recommend a recent Windows version.
Connections made using FTPS can log into the same Windows and virtual accounts as SFTP and SCP connections, and can interact with the same virtual filesystem. However, FTPS connections are limited to password authentication.
The SSH Server now supports automatic updates. The administrator can configure the SSH Server to automatically apply all updates; only recommended updates; only strongly recommended updates; to apply updates only manually; or to never check for updates.
The SSH Server will not automatically update to a new version if the new version would require an upgrade access extension for the activation code that's currently applied.
The SSH Server's terminal subsystem now fully supports the new Windows 10 console. ANSI escape sequences and other new console behaviors are supported. Processes such as bash under the WSL (Windows Subsystem for Linux) are now supported.
Note: In current Windows versions, WSL does not work for multiple users. It can be used via the SSH Server in a single-account setup, but for use on a production server with multiple accounts, we would at this time still recommend Cygwin or similar.
Two-factor authentication using time-based one-time passwords is now supported. The SSH Server implements RFC 6238, which is supported by a number of authenticator apps including Microsoft Authenticator, Google Authenticator, LastPass, Authy, and FreeOTP. The SSH Server allows configuring, individually for each account, a secret key which can be shared with the user either textually or as a two-dimensional code image. Once configured, the user's authenticator can generate a one-time password specific to the user, which the user's SSH client will prompt for, and which the user can use to log in. The SSH Server can be configured to require this one-time password for a user or a group of users in addition to authentication using a password or public key.
Bitvise SSH Client and SSH Server now implement automatic host key rotation. The SSH Client will synchronize keys from the SSH Server and any other servers that support the OpenSSH mechanism "hostkey update and rotation". The SSH Server will announce to clients all configured host keys, including those not employed, to facilitate host key rotation. The SSH Client will automatically trust new keys announced by a trusted server and remove any keys the server has removed, as long as they were added automatically.
Most lists in SSH Server settings can now be exported and imported in CSV format.
The graphical aspects of the SSH Server now support high resolutions and will display crisp text on high-DPI displays such as retina or 4K. The SSH Server now comes with new, higher resolution icons.
Instance names for new installations are now validated more strictly to avoid use of names that could lead to issues.
SSH Server Control Panel:
An option is now available to copy all fingerprints to clipboard, making it easier to share host key information with clients.
The Activity tab, as well as textual log files, now displays the country (if available) of incoming connections. The SSH Server uses the MaxMind GeoLite2 Country database (under license). The country database comes with the SSH Server installation and is not automatically updated, other than by updating the SSH Server itself.
In many domain environments, the domain logon names used by the SSH Server (in format DOMAIN\username) are generated and hard to read. The SSH Server Control Panel will now display User Principal Names (UPNs) on the Activity tab and in Statistics. Textual log files now also record UPNs in addition to domain logon names.
The Log Folder Viewer now supports an option to Force log rollover without having to stop and restart the SSH Server.
The Manage blocked IPs interface now supports selecting multiple IP addresses to permanently block.
The SSH Server will now keep track of whether any warnings or errors have been logged. If there are errors or warnings, the SSH Server Control Panel will now alert the administrator by displaying a yellow notification.
On the Sessions tab, it is now possible to disable real-time session monitoring to reduce load on busy servers.
Additive settings import now allows the administrator to select which aspects of settings to import. The administrator can review the final settings and choose whether to save them or to cancel the import.
It is now possible to configure IP address rules based on country instead of manually entered address ranges. The SSH Server uses the MaxMind GeoLite2 Country database (under license). The country database comes with the SSH Server installation and is not automatically updated, other than by updating the SSH Server itself.
An administrator can now force a virtual account to change password during their next logon.
The virtual account password policy can now be configured to prevent reuse of the user's existing password.
All IP address rules that previously used a subnet mask and significant bits are now configured as more readable IP address ranges.
In settings for a virtual filesystem mount point, full filesystem access - allowing access to all drives, limited only by Windows filesystem permissions - is now expressed with a more obvious, explicit setting instead of an empty Real root path.
Easy settings, and settings for delegated administrators, now support a Blind drop virtual filesystem layout. This maps to an Advanced settings mount point configuration appropriate for users that should be allowed only to upload, but not view or modify existing files.
The properties and methods available under $cfg - the root BssCfgManip object - have been substantially cleaned up and rationalized. Keypairs are now available under $cfg.keypairs, certificates under $cfg.certificates, activation state under $cfg.actState, information about installed instances under $cfg.instances, and so on.
Commonly called prologue and epilogue methods are now also rationalized. For example, $cfg.LockServerSettings is now $cfg.settings.Lock, while $cfg.SaveServerSettings is now $cfg.settings.Save.
The $cfg.SetSite method is now more appropriately called $cfg.SetInstance.
All list interfaces that previously had two forms, listNameEx and listName, have now been consolidated as listName and listName.entries.
To de-clutter the $cfg namespace, enumeration values are now under $cfg.enums.
The settings layout remains substantially the same, however some settings have moved. For example, IP blocking settings were previously under $cfg.settings.session and are now under $cfg.settings.ipBlock.
The SSH Server now supports the PROXY protocol for use with non-transparent load balancers. The PROXY protocol can be enabled in Advanced settings for individual port and interface bindings. If enabled, the SSH Server will require incoming connections on that binding to be prefixed with a PROXY protocol header which will be trusted to contain the IP address of the actual client.
In Advanced settings, under Logging, it is now possible to configure a list of whitelisted monitor IP addresses. Connections coming from these addresses will not be logged unless they exhibit SSH or FTPS protocol activity. This helps avoid filling up logs with trivial connections that can come from load balancers or health monitors several times per minute.
Greatly improved shutdown performance when the server is handling many concurrent sessions.
Bitvise SSH Server, SSH Client and FlowSsh once again support non-standard DSA keys larger than 1024 bits. We do not recommend using these keys, and new keys of this type cannot be generated. Also, these keys cannot be used when FIPS mode cryptography is enabled in Windows. Re-adding support for these keys is intended to resolve an obstacle that may still be preventing some users of 6.xx versions from upgrading.
When using Windows cryptography, Bitvise SSH Server, SSH Client and FlowSsh now implement a backup strategy for DH and ECDH key exchange. Windows implements key exchange, but it does not expose the agreed value in a form suitable for SSH. Bitvise software must retrieve the value by carefully traversing undocumented Windows structures. In versions 7.xx, this required our software to be upgraded to continue working after the Windows 10 1803 update. Our software will now log a warning and fall back to Crypto++ if it cannot perform key exchange because Windows internal structures have changed. However: if FIPS mode is enabled in Windows, this backup strategy is not used, and the software must be updated.
When importing keys, such as from files, the stage at which an import failed is now described in more detail.
Bitvise SSH Server and Client now support the elevation extension. In previous versions, if a Windows account with administrative rights connected to the SSH Server, the server would always elevate the session if possible. Otherwise, the user would not be able to get an elevated session because there was no way to convey the user's preference. With the elevation extension, the user can request a non-administrative security context by requesting no elevation (elevation is still applied by default). In command line clients including stermc, sexec and sftpc, this is controlled using the switch -elevation=n.
Bitvise SSH Server and Client now support the no-flow-control extension. This disables SSH flow control for clients that only support opening one channel. No flow control is now preferred by sftpc, stermc, sexec and spksc, which only need to open one channel in the SSH session.
Bitvise SSH Server and Client now support the delay-compression extension. Delayed compression reduces attack surface for unauthenticated clients by delaying availability of compression until after a user is authenticated. The delay-compression extension is an improvement over previously supported alternatives: the firstname.lastname@example.org method contains a by-design race condition, while the approach of invoking a second key exchange doubles the overhead of establishing an SSH session.
If the Omit server version setting was enabled, then in previous SSH Server versions, the server would send a trailing space at the end of its version string. Some versions of some clients incorrectly trimmed this space, which caused the session to abort with a key exchange error. This trailing space will now no longer be sent.
The SSH Server now supports global settings to completely disable password authentication; or to disable it for all Windows accounts, or for all virtual accounts.
If the SSH Server is configured in a way such that no Windows accounts could possibly log in, it will no longer perform any Windows account lookups during authentication.
The handling of public key authentication has been reorganized to reduce attack surface. For example, the SSH Server will halt public key processing early if it detects that the public key being used does not even exist in its configuration.
Bitvise SSH Server and Client now support the ext-auth-info extension. This allows the server to respond to user authentication failures with more detailed information in situations where this is safe. For example, if the client attempts to perform a password change but the new password does not meet complexity requirements, the server can communicate this instead of making the user guess.
The SSH Server now supports password authentication over the keyboard-interactive method, in addition to the standard password method. This accommodates some custom clients which may only support password authentication over keyboard-interactive.
The SSH Server now supports PuTTY and OpenSSH agent forwarding. In this situation, an SSH client A, which has access to an authentication agent, can connect to the SSH Server and make the agent available in the SSH session. Within the session, the user can now run client B, located on the server, which will be able to use public keys from the authentication agent on client A. The clients can be Bitvise SSH Client or any other client that supports PuTTY or OpenSSH agent forwarding. However, in the role of client B, Bitvise SSH Client and Cygwin OpenSSH will work; but the OpenSSH client included in Windows 10 will not work because it cannot communicate with an authentication agent outside of the Windows Subsystem for Linux.
The SSH Server will now apply an IP blocking penalty to sessions which make a large number of authentication attempts of a kind that would not otherwise be penalized, unless there are too many.
Terminal and exec requests:
An obstacle for users trying to configure a bash shell for rsync has been that the directory containing the bash and rsync executables may not be present by default in the PATH environment variable. When using the bash shell access type, the SSH Server now offers the option to add the bash directory to PATH.
If the exec request prefix configured for a user begins with cmd /c, and the user's client sends an exec request that also begins with cmd /c, the extra cmd /c prefix is now stripped. This results in more intuitive behavior for commands like cmd /c cd SomeDir && command. Before, the effects of cd would be undone by the time command was run because the cd would be executed by the inner cmd, and command by the outer.
Custom named subsystems are now supported and available by default to accounts with Shell access type set to Command Prompt, PowerShell or bash. A new powershell subsystem is defined by default, which supports PowerShell remoting over SSH if PowerShell 6 is installed on the system.
Execution of an On-upload command is now delayed for some time after the client closes the respective file. This allows a client to complete any follow-up actions, such as a file rename, before the On-upload command is executed. If the client renames the file, the On-upload command is now run with the final filename.
bvRun now supports a -pid command line option which will cause it to return the PID of the started process as an exit code.
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.