Known issue being resolved:
Bitvise SSH Server versions 8.xx implement new features including host key synchronization and reporting of elevation status. These features involve sending to the client a message of type SSH_MSG_GLOBAL_REQUEST. Per RFC 4254, a client must be able to handle these messages:
Note that both the client and server MAY send global requests at any time, and the receiver MUST respond appropriately.
A large majority of clients implement this correctly. Correctly behaving clients include Bitvise, OpenSSH, PuTTY, Tectia, Van Dyke, WinSCP, FileZilla, and most others that we have tested.
Since our 8.xx releases, however, we have learned of clients which do not implement this correctly. These clients will disconnect when they receive an SSH_MSG_GLOBAL_REQUEST message from the server. Currently, we know of the following:
Applications using the WeOnlyDo client will disconnect with the message "Invalid packet type (80) received." The client does not implement the SSH_MSG_GLOBAL_REQUEST message as required in RFC 4254. At this time, we don't know if all or only some versions of WeOnlyDo clients are affected.
Cisco devices which send an SSH version string containing Cisco (not all Cisco devices do) will disconnect with a message such as "Channel open failed, reason = 1752134516". The cause of this is not just that the client does not support SSH_MSG_GLOBAL_REQUEST, but it completely ignores the packet type sent by the server and tries to handle the message as if it was SSH_MSG_CHANNEL_OPEN_FAILURE. The client decodes 4 bytes of whichever data appears in the packet at offset 5 and handles it as if it was the "reason code" field in the packet it is expecting.
An automated file transfer client that identifies itself as AutoMate also appears to be affected by this issue. This client seems to disconnect and report the message: "Connection Lost (error code is 10058)."
Extremely old versions of OpenSSH exhibit this issue. These would be versions before OpenSSH 3.1, which was originally released for OpenBSD in 2002, and in 2004 for other platforms. These versions pre-date RFC 4254.
Users who don't need to handle connections from such clients can safely upgrade to SSH Server versions 8.xx, which in our experience are stable and well-performing. For users who must support affected clients, we are preparing a mitigation. Until this is ready, affected users should continue using the latest 7.xx versions available from the SSH Server 7.xx Version History page.
For other issues that might arise using the latest SSH Server versions, see Known issues.
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.