For issues that might arise using the latest SSH Server versions, see Known issues.
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 firstname.lastname@example.org 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 email@example.com 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.