Bitvise SSH Server 6.xx Version History

An initialization issue in a compression library used by Bitvise software.

Issue 1:

This issue consists of an invalid memory access. At this time, we believe this memory access is always invalid and cannot be used for remote code execution.

This issue has the following impact on Bitvise SSH Server and Client:

High severity: When an affected Bitvise SSH Server version is installed on a 32-bit version of Windows, a remote unauthenticated attacker can cause the SSH Server's main service to stop abruptly.

This high severity impact is not present on 64-bit versions of Windows. The following other impacts are present on all versions of Windows.

Lower severity: An authenticated user connected to Bitvise SSH Server who is permitted to use the SFTP subsystem can cause the SFTP subsystem to stop abruptly. This can have an effect on what actions are logged. For example, an error might be logged instead of the last actions taken by the user.

Lower severity: A server to which a user connects using Bitvise SSH Client can cause the SSH Client to stop abruptly. Due to the limited effects, this would not be an interesting attack in most usage scenarios.

Low severity: If a user or administrator imports a specially crafted file when using either the local Bitvise SSH Server Control Panel; the remote Bitvise SSH Server Control Panel; or Bitvise SSH Client; then the process being used to import the file can stop abruptly. Due to the limited effects, this would not be an interesting attack in most usage scenarios.

In addition, this issue has the following impact on applications using FlowSsh:

If an application using the 32-bit version of FlowSsh connects to a server which sends a specially crafted packet that should cause FlowSsh to disconnect, the application will instead stop abruptly. The severity of this impact depends on the characteristics of the application.

At this time, we believe applications using the 64-bit version of FlowSsh are unaffected.

The following versions of our software are affected by issue 1:

Bitvise SSH Server 6.xx, but not version 6.51 and future versions.

Bitvise SSH Server 7.xx, but not versions 7.41 and higher.

Bitvise SSH Client 6.xx and 7.xx, but not versions 7.41 and higher.

FlowSsh 5.xx and 7.xx, but not version 7.41 and future versions.

We have addressed issue 1 in Bitvise SSH Server, Client, and FlowSsh versions 7.41 and higher. In addition, we have addressed issue 1 for Bitvise SSH Server 6.xx versions due to the high severity impact on 32-bit versions of Windows.

At this time, the limited impact does not seem to warrant applying this change to 6.xx versions of Bitvise SSH Client and FlowSsh. We encourage users of Bitvise SSH Client to upgrade to the latest versions free of charge. Users of FlowSsh 5.xx will need to have upgrade access to a 7.xx version to upgrade.

Issue 2:

Issue 2 consists of incorrect delayed initialization in a compression library used by Bitvise software. We believe this could be used by one SSH session that uses compression to corrupt decompressed data in another simultaneous session that uses compression. However, for this to be likely, there must not have been another session that used compression since application startup. Therefore, the attack would have to occur at the same time as when the first legitimate session that uses compression begins after Bitvise SSH Server or an application using FlowSsh has started.

The following versions of our software are affected by issue 2:

All older versions of Bitvise SSH Server, but not versions 7.41 and higher.

All older versions of FlowSsh, but not version 7.41 and future versions.

Bitvise SSH Client only ever establishes one SSH session per process instance, so the issue cannot be exploited. A FlowSsh application could be affected if it simultaneously starts multiple concurrent SSH sessions after launching.

Mitigation:

We recommend that all users of affected Bitvise SSH Server, Client, and FlowSsh versions upgrade to the newest current versions, which can be downloaded from our website:

In addition, users of Bitvise SSH Server versions 6.xx who do not wish to upgrade can download version 6.51, which also fixes issue 1, but not issue 2.

Changes in Bitvise SSH Server 6.51: &lsqb; 6 May 2018 &rsqb;

This is not a new feature release, but a successor to 6.49 with a continued maintenance update. (We skip over versions containing zeros to avoid ambiguities. For example, 6.05 and 6.50 might both be referred to as "6.5".)

This version continues the upgrade amnesty introduced in version 6.44. It can be upgraded to by all users with activation codes valid for previous 5.xx and 6.xx versions. This is the version we currently recommend for users who do not yet wish to upgrade to 7.xx versions.

Backported from version 7.41: Fixed a denial of service attack vector described in the associated security notification.

Backported from version 7.25: 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 6.48: &lsqb; 15 December 2016 &rsqb;

Backported from version 7.16: 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 6.47: &lsqb; 5 April 2016 &rsqb;

Fixed an issue which could cause the SSH Server to crash under rare conditions.

Fixed a small memory leak which could become visible after long periods of use, e.g. after handling tens of thousands of connections.

Fixed issues which could cause a port forwarding request from the client to be processed incorrectly.

Security Clarification: &lsqb; 14 January 2016 &rsqb;

We are receiving occasional inquiries about whether our software is affected by the "Roaming" vulnerability in OpenSSH client versions 5.4 - 7.1.

Bitvise software does not share common code with OpenSSH. Additionally, no current or past version of Bitvise SSH Server or Client implements the roaming feature affected in OpenSSH.

Due to independent code bases, OpenSSH vulnerabilities tend not to apply to Bitvise software, and Bitvise vulnerabilities tend not to apply to OpenSSH. No changes are necessary to Bitvise SSH Server or Client installations with respect to the OpenSSH roaming issue.

We nevertheless recommend that users of older Bitvise SSH Server and Client versions upgrade to version 6.45 due to a separate and unrelated issue in our previous announcement, as of November 30, 2015.

Security Notification: &lsqb; 30 November 2015 &rsqb;

We have recently discovered a security issue in a common library used by Bitvise software. Given specific, but common conditions, this issue can be exploited by an unauthenticated remote attacker to cause instability and denial of service in affected software. We cannot exclude that this issue could be exploited to run arbitrary code.

The following versions of our software are affected:

SSH Server 5.xx and 6.xx, up to and including version 6.43. Version 6.44 and newer do not contain this issue.

SSH Client 6.xx, up to and including version 6.43. Versions 6.44 and newer do not contain this issue.

FlowSshC/Cpp/Net versions up to and including 5.36. Versions 5.37 and newer do not contain this issue.

To help mitigate this issue, Bitvise SSH Server versions 6.44 and 6.45, and Bitvise SSH Client versions 6.44 and 6.45; and FlowSsh version 5.37; contain an upgrade amnesty, so that any existing license that is valid for any of the software versions affected by this issue can be used with the respective latest unaffected software version. This means that all users of Bitvise SSH Server and Client 5.xx and 6.xx can upgrade to version 6.45, and can activate it using their existing activation code. This also applies to FlowSsh users upgrading to version 5.37.

Users of Bitvise SSH Server and Client per-installation licenses can
log in to access their existing activation codes.

Users of FlowSsh, and users of large-scale licenses, can upgrade using activation codes received in order delivery.

Changes in Bitvise SSH Server 6.45: &lsqb; 23 November 2015 &rsqb;

UPnP: Automatic router configuration did not work with OpenWrt routers because the router did not recognize "0.0.0.0" as matching all remote addresses. The SSH Server will now use an empty string instead.

File transfer: A new setting, Omit relative paths, is now available, and can be enabled in account settings, group settings, or as a server-wide default. If enabled, this prevents inclusion of relative directory entries "." and ".." in directory listings sent to clients. This setting is disabled by default in new installations (relative entries are sent), but may help users stuck with clients that do not properly handle these entries. To preserve behavior during upgrade, the setting is enabled by default (entries are not sent) when upgrading from versions 5.15 and older.

Terminal: In the November update to Windows 10, automatic line re-wrap during window resizing has been enabled in the Windows console by default. This interacts poorly with SSH, where re-wrap causes loss of synchronization between the client and server. The SSH Server now disables line wrap for terminal console and exec request sessions.

The TelnetForward utility, added in 6.44, now displays a friendlier error if it loses connection to the Telnet server.

A new setting, Add space after exec request prefix, is now part of Custom shell settings, to help preserve identical behavior when upgrading from versions prior to 6.41 that may use a particular type of exec request prefix. This allows a prefix like c:\path\git-shell.exe " (note the dangling double quote) to continue to work without changing settings. Versions 6.41 to 6.44 would break this by inserting a space after the double quote always. However, note that versions since 6.41 have built-in Git support that replaces git-shell.

Changes in Bitvise SSH Server 6.44: &lsqb; 10 November 2015 &rsqb;

Installation: On initial installation, the SSH Server will now generate a default 3072-bit RSA keypair, instead of a 1024-bit DSA keypair. This is in addition to the ECDSA/nistp256 host key that has been generated since version 6.41.

Windows Firewall: The SSH Server's automatically managed IPv4 and IPv6 firewall rules no longer overlap. In previous versions, the rules overlapped, so that removal of a binding for one protocol caused the firewall exception for that same port to be also removed for the other protocol, until the server was restarted.

The SSH Server now includes a TelnetForward utility. This utility can be used to forward a terminal session established via the SSH Server to a legacy Telnet server. Currently, to use this utility, configure the following in a user or group settings entry in Advanced settings:

Installation: Further improved support for unusual reinstallation and upgrade scenarios; in particular, renaming the installation directory during reinstallation or upgrade.

If configured, the session inactivity timeout could take up to double the amount of time as configured. Detection of this timeout is now more accurate.

Master/slave synchronization: The "hmac-sha2-256" data integrity algorithm is now correctly identified by slaves initiating synchronization connections. This now permits the "hmac-sha1" algorithm to be disabled on the master.

Terminal:

Improved support for console command history. Fixed an issue which could cause the terminal subsystem to crash (ending the terminal session) in rare circumstances.

The Rogue Wave HostAccess terminal client would request a terminal session with a geometry of 0 rows and 0 columns, resulting in a single-line console window, not functional for most purposes. The SSH Server will now assume a console geometry of 25 rows by 80 columns in this case.

Support for disabling auto-wrapping has been removed from the wyse60 terminfo file. Some Wyse 60 terminal client implementations (e.g. Van Dyke SecureCRT) do not appear to support it.

Changes in Bitvise SSH Server 6.42: &lsqb; 17 September 2015 &rsqb;

Installation:

Improved uninstallation to reduce the likelihood that Windows might need to be restarted to complete a reinstallation or upgrade. If a restart would be required, the user can now choose to abort reinstallation.

A change in SSH Server version 6.41 caused the following: if version 6.41 is installed on a computer before any of the earlier versions; and then a downgrade is attempted to an earlier version; the earlier version will not work unless a specific registry key is manually removed. This downgrade incompatibility is no longer caused by version 6.42. Version 6.41 will still cause this issue if it is installed before any of the earlier versions.

Control Panel and Settings:

When editing a comment associated with an imported client authentication public key, the edited comment would be displayed in the Insert time column instead of the Comment column. Fixed.

In instance type settings, Host key and fingerprints was being displayed incorrectly when instance type was set to Standalone. This could be confusing. Host key and fingerprints will now correctly be available only when instance type is set to Slave or Secondary master.

When the SSH Server fails to initialize its configured bindings (listening sockets), the related notification will no longer be shown by the SSH Server Control Panel when the service is stopped.

Changes in Bitvise SSH Server 6.41: &lsqb; 30 August 2015 &rsqb;

Installation and upgrade:

This is the first version tested on Windows 10 as part of the development process.

On Windows Vista and newer, the installer did not auto-run correctly after the uninstaller prompted for restart during upgrade. Fixed.

Failed and incomplete installations are now detected and displayed, to help the user choose the correct installation directory.

Publisher and version information is now added for display in Add/Remove Programs.

Control Panel and Settings:

In both Easy and Advanced SSH Server settings, terminal shell access can now be configured much more intuitively via a number of default selections: Command Prompt, PowerShell, bash, and Git access only.

The new terminal shell setting Git access only now makes it much easier to configure the SSH Server to provide access to Git repositories. The settings provided by the SSH Server are more secure than can be achieved using git-shell, and are able to restrict the user to a particular repository directory. Both Cygwin and msysGit-style Git implementations are supported.

In Advanced SSH Server settings, account settings have been rearranged into several categories, to make it easier to find and understand settings.

Inline editing of list entry settings is no longer supported. Some users would use only inline editing, and miss essential settings such as Virtual filesystem layout. List entries such as accounts and access rules now need to be opened, via double-click or Edit, in order to edit them.

When the SSH Server Control Panel is started automatically on logon, it was being started by the Windows Task Scheduler with a "below normal" process priority. This caused the SSH Server Control Panel to be sluggish when the machine was under load. The SSH Server Control Panel now auto-starts with "normal" priority.

Separate SSH Server installations on the same machine are now called instances instead of "sites". This is to avoid confusion with a Site License, where the term "site" refers to a building or a group of buildings at a geographical location.

The input box on the Query tab in Advanced SSH Server settings is now larger and vertically resizable.

Improved responsiveness in case a timeout occurs when an administrator disconnects a session.

Strengthened the security of communication between the SSH Server and the local SSH Server Control Panel. The Control Panel now authenticates the SSH Server to ensure it is communicating, not necessarily with the SSH Server, but with a process that has administrative permissions. Implemented steps to prevent hijacking of the named pipe used for this communication.

Improved detection and reporting of installation and configuration issues that might lead to the SSH Server's authentication package not loading, thereby preventing use of password-less authentication, such as for public key login into Windows accounts.

Master-slave synchronization:

It is now possible for a master server instance to disable password cache synchronization.

In previous SSH Server versions, the security of host key verification by a slave instance connecting to a master would always boil down to the strength of an MD5 key fingerprint - even if a full master host key was imported. Since attacks against MD5 would require the true master's key to be generated maliciously, this is not currently known to be exploitable. However, slaves running version 6.41 will now check the master's host key against full information available: for example, the full imported host key. To protect against future uncertainty, we recommend slave servers to be upgraded.

When upgrading from a previous version to 6.31, a master server's instance settings would revert to a standalone instance. Fixed.

Statistics:

Optimized statistics-related file writes under heavy use scenarios.

SSH:

SHA-256 public key fingerprints, compatible with the latest OpenSSH versions, are now supported.

On initial installation, the SSH Server will now generate and employ an ECDSA/nistp256 host key, in addition to the previously standard 1024-bit DSA host key. The ECDSA host key provides the equivalent of 128 bits of symmetric security, and is compatible with recent versions of Bitvise SSH Client as well as OpenSSH. ECDSA over nistp256 is stronger than a 1024-bit DSA host key, which provides the equivalent of 80 bits of symmetric security; and stronger than 2048-bit RSA, which provides the equivalent of 112 bits of symmetric security. We recommend migrating older SSH clients to new versions supporting ECDH and ECDSA.

The key exchange method gssapi-group14-sha1 with Kerberos 5, which uses Diffie Hellman with a 2048-bit fixed prime, is now supported and enabled by default.

The 1024-bit fixed prime Diffie Hellman key exchange methods, diffie-hellman-group1-sha1 and gssapi-group1-sha1 with Kerberos 5, are now disabled by default, due to doubts about continuing security of Diffie Hellman with a 1024-bit fixed prime. Compatibility with most older clients should be retained via the diffie-hellman-group14-sha1 method, which uses a 2048-bit fixed prime. We recommend migrating older SSH clients to new versions supporting ECDH and ECDSA.

Symmetric encryption algorithms that use CBC mode are now disabled by default. Bitvise SSH Server and Client implement defenses against attacks on CBC mode, but other implementations that still use CBC mode are unlikely to implement such defenses. Most implementations should now support encryption in CTR mode.

Authentication:

The SSH Server now again supports changing the username during authentication. This resolves a common issue with PuTTY, where PuTTY would send an undesired GSSAPI (Kerberos) authentication request by default, and thereby lock the client into an authentication username that cannot login, and which the user did not intend.

When a user successfully authenticates using GSSAPI (Kerberos or NTLM), the SSH Server can now optionally verify that the username submitted in the SSH authentication request matches the GSSAPI identity. This is now enabled by default for PuTTY, but disabled for other clients. It is necessary for PuTTY, because it is configured by default to send an undesired GSSAPI (Kerberos) authentication request which may be for a different account than the one with which the user intends to authenticate.

When a virtual account password is entered and stored irreversibly by the SSH Server, the SSH Server previously hashed the password with a simple, fast SHA-1 based construction. The SSH Server will now use a much more computation-intensive algorithm based on SHA-512 and BusyBeaver. The new construction makes it orders of magnitude more difficult for an attacker to brute force a password in case they know only the password hash; for example, if an attacker gains access to exported SSH Server settings. Note that this improves defenses against some types of attack only, and does not remove the need for users to use secure, randomly-generated passwords; and to avoid reusing passwords for different services and accounts.

File transfer:

The SSH Server will now always send consistent POSIX permissions to SFTP and SCP clients. By default, the permissions sent are 0660 for files, and 0770 for directories. These defaults can be changed in Advanced SSH Server settings, either in an individual account's settings entry; or in group settings as a default for multiple accounts; or on the Server tab, as a server-wide default.

The I_SFS_TRANSFER_FILE log message now includes additional information to distinguish whether a file transfer was ended via an SSH_FXP_CLOSE request sent by the client; or via session cleanup after the client ended the SFTP channel, or disconnected.

Previously, creation of an empty file that did not involve a transfer of data, as well as resizing of an existing file that did not involve a transfer of data, would not be logged using the I_SFS_TRANSFER_FILE message. These actions are now logged and distinguished from other types of transfers.

In versions 6.24 and 6.31, an SCP file transfer with syntax "scp -r server:/path" would behave as if "/path" was empty. To work around this, "/path/*" would need to be used. Fixed.

The SSH Server now checks for clients attempting to set invalid file times with special values 0 or -1. According to the SFTP specification, this is not a valid way to indicate that no time information is available, but some clients send such values regardless. Previously, this would result in file times being set to January 1, 1970, or December 31, 1969. The SSH Server will now set the file time to current time in this cases.

When an empty directory listing was sent due to the setting Show empty directory if no access, the listing would lack the '.' and '..' special directory entries. Fixed.

Terminal:

Changes to the terminal subsystem in version 6.31 caused .NET Any CPU programs to not run under terminal emulation on 64-bit Windows. Such executables should now work again.

The BvRun utility now disables WoW64 filesystem redirection. This allows it to run programs under the actual \Windows\System32 directory, rather than being redirected to \Windows\SysWOW64.

The SSH Server now includes SfsDll: a DLL-based API that allows a command line program to access the SSH Server's virtual filesystem when run as an exec request, or under terminal emulation. A usage sample, SfsDllSample.cpp, is included in the SSH Server installation directory.

Improved the security of interprocess communication for programs running under the SSH Server's terminal subsystem by securing shared objects with the logon SID; or if a logon SID is not available, the user's SID.

Security Clarification: &lsqb; 29 May 2015 &rsqb;

We are receiving occasional inquiries about whether our software is affected by the "Logjam" attack against TLS/SSL.

Our software does not implement TLS/SSL, but SSH, which is a similar, but different protocol. SSH does not specify "export-strength" cryptography, and our software does not implement it. Our software is therefore not vulnerable to "Logjam".

In general, SSH is not vulnerable to middle-man encryption strength downgrade attacks, because it signs negotiation information between the client and the server before key exchange, which TLS/SSL doesn't. An SSH server and client will always negotiate algorithms that are supported by both the server and the client, and which are most preferred by the client.

Our software does, by default, enable key exchange using 1024-bit Diffie Hellman using a fixed prime. This is significantly stronger than "export-strength" cryptography, but has been suspected to be defeatable by nation-state attackers.

This algorithm will be used only if both the client and the server enable it, and the client does not prefer a different mutually supported algorithm. If you wish to completely prevent use of this algorithm, disable the following in Advanced SSH Server settings > Algorithms > Key exchange, or in the SSH Client under SSH > Key exchange:

diffie-hellman-group1-sha1

diffie-hellman-gex-sha1

diffie-hellman-gex-sha256

gss-group1-sha1 with Kerberos 5 (SSH Server only)

gss-gex-sha1 with Kerberos 5 (SSH Server only)

SSPI/Kerberos 5 key exchange (SSH Client only, Login tab)

In recent Bitvise SSH Server and Client versions, this should leave you with ECDH algorithms, which are believed to be secure; and one remaining Diffie Hellman algorithm, diffie-hellman-group14-sha1. This latter algorithm also uses a fixed prime, but one that is 2048-bit, and is currently not believed to be vulnerable even to nation-state attackers.

If you are using an older Bitvise SSH Server or Client version, we recommend migrating to new versions that implement Elliptic Curve-based cryptography (ECDH and ECDSA), and to start deploying ECDSA-based host keys.

Changes in Bitvise SSH Server 6.31: &lsqb; 2 May 2015 &rsqb;

Installation:

The SSH Server installer now supports the -renameExistingDir parameter. This allows an existing SSH Server installation directory to be renamed during upgrade or re-installation, as long as the new installation directory remains on the same drive.

The console output stream implementation provided by the C++ run-time library, and used by the SSH Server installer, did not properly handle Unicode characters that could not be represented in the output code page. Replaced with our own output stream implementation.

Control Panel and Settings:

The SSH Server now maintains a history documenting sources of recent changes to SSH Server settings.

The Reset or Revert Settings dialog now provides the change histories of available settings backups.

When the SSH Server receives a directory change notification for the Config subdirectory, the SSH Server will now check that settings and/or keypairs have truly changed before reloading them.

Users have recently reported that in some environments - virtual machines running under VMWare and Zen have been pointed out specifically - the directory change notification appears to be signaled by Windows about every second, causing previous SSH Server versions to continuously reload settings. Textual log files grow large under this condition unless logging of settings-related events is disabled.

Fixed an issue where settings could not be imported or upgraded from versions prior to 5.00 if login attempt delay was set to a value higher than 29. Import would fail with 'invalid delayed login expiration'.

If upgrading, and the custom event list is not currently being used, it will now be reset to default state. This avoids a large number of irrelevant lines relating to custom event selections normally logged to textual log files as part of the event I_SERVICE_CONFIG_DESCRIPTION.

Fixed an issue which caused the feedback dialog accessed via the Send us feedback link in the SSH Server Control Panel to fail when sending feedback with an access violation. (The feedback dialog in the uninstaller still worked correctly.)

Master-Slave support:

An SSH Server instance can now be configured to run as secondary master. In this mode, the SSH Server will connect to another master to synchronize configured aspects of SSH Server settings; but will also accept connections from other slaves, and allow them to receive synchronized settings as configured on the primary master. This is intended for situations where a load-balanced cluster may serve as master to many slaves.

When configured to run as slave, the SSH Server can now be configured to keep local Windows Firewall settings.

Programmatic access:

Public key settings entries now support the ImportStr instruction to import a public key in one of the common formats from a directly passed string, instead of from a file.

BssCfgManip now implements the method GetServerVersion, allowing the SSH Server version to be retrieved for the instance previously selected using the method SetSite.

BssStat using the -s parameter (display sessions) now properly implements the latest WRC protocol version, and therefore works again.

Server:

For statistics purposes, connections that do not successfully authenticate now count as failed logins only if they completed key exchange. This avoids including regular connections from load balancers in the Failed login count statistic.

When key exchange fails due to no match in algorithms, the local and remote algorithm lists are now logged.

The SSH Server now uses Windows permissions to secure subsystem processes launched as part of an SSH session. Non-administrator users who can run arbitrary code, e.g. via exec request or terminal shell access, are now prevented from using this access to affect operation of SSH Server subsystem processes running in their security context. SSH Server subsystem processes include SftpServer, ScpServer, toterms, and sexec.

Terminal:

The terminal subsystem has been partially re-architected to avoid issues with certain anti-virus software, including Kaspersky, which could cause programs to fail to run under terminal emulation.

Fixed issues which could cause the terminal subsystem to not work correctly for programs run in Windows compatibility mode.

File transfer:

When a client creates a new file or sets file size on an existing file, the SSH Server will now treat this as an upload, generating an I_SFS_TRANSFER_FILE event and executing an on-upload command, even if file content was not written to by the client.

Changes in Bitvise SSH Server 6.24: &lsqb; 17 February 2015 &rsqb;

Fixed an issue which would cause the SSH Server to stop with an assertion failure if it was configured to use a proxy profile for outgoing port forwarded connections with proxy type set to SOCKS4 and "Resolve locally" disabled.

Changes in Bitvise SSH Server 6.23: &lsqb; 3 February 2015 &rsqb;

In versions 6.21 and 6.22, the file transfer subsystem would stall after uploading a file if the client's requested access disposition had to be adjusted due to configured mount point access permissions. Most significantly, SCP uploads would stall if the mount point permitted Read/Write/Delete New, but not Write Existing. In previous 6.xx versions, the transfer would complete, but an event would not be logged.

SCP upload no longer requires List permission to be enabled for the target virtual filesystem mount point. To upload new files via SCP, it is now sufficient to enable only Read/Write/Delete New. (However, in the event of an error, some error messages will be more accurate if List permission is granted.)

In the SSH Server Control Panel, on the Session tab, sorting sessions by account name is now case insensitive and Unicode-aware.

Changes in Bitvise SSH Server 6.22: &lsqb; 31 January 2015 &rsqb;

The SSH Server now supports SSH protocol obfuscation, configured through Advanced settings > Bindings. The SSH Server can be configured to accept connections on some interface and port combinations with obfuscation, and others without. Only a client that also supports obfuscation can connect to an obfuscated binding. When supported and enabled in both the client and the server, obfuscation makes it harder for an observer to determine that the protocol being used is SSH.

Case insensitive name comparisons for virtual group names are now also Unicode-aware.

In version 6.21, the username blacklist feature would behave incorrectly, and cause all clients to be locked out if any username was blacklisted. Fixed.

In version 6.21, the SCP subsystem would hang on termination of an SCP session, and would have to be forcibly closed. Fixed.

Changes in Bitvise SSH Server 6.21: &lsqb; 23 January 2015 &rsqb;

Statistics and quotas. Bitvise SSH Server now supports collection and monitoring of transfer and login statistics on a per-user, per-group, and server-wide basis. In Advanced settings, it is possible to configure users with upload and download quotas. If a user's quota is exceeded, the server can be configured to further restrict that user's bandwidth, or to deny connections until more quota is available.

Installer:

The installer's "-keypairs" parameter now also accepts keypairs in non-passphrase protected Bitvise, OpenSSH, and PuTTY export formats. Previously, only the SSH Server's internal format of the BvSshServer-Keypairs.wpk file was supported.

Control Panel and Settings:

When importing public keys, the SSH Server will now recognize and import text files with UTF-8 or UTF-16 byte order markers.

Fixed an issue which caused mouse wheel scrolling to stop working after expanding and collapsing some help texts.

When authorized_keys synchronization was enabled, or when an SSH client managed their public keys using the SSH public key subsystem, the SSH Server would incorrectly create duplicate account settings entries. Fixed.

The list that stores Windows account settings entries now implements static sorting, and can no longer be reordered.

The settings wizard launched after first installation will no longer be started if the installation was performed non-interactively, or if settings were already modified in another way after installation.

Slave-Master synchronization:

Slave synchronization sessions are now no longer subject to a session timeout, if it is configured.

SSH:

Delayed negotiation of zlib compression is now supported. If delayed compression is enabled in Advanced SSH server settings, the SSH Server will not advertise "zlib" compression upfront, but will start a second key exchange to negotiate compression after user authentication is successful, if the client indicated a preference for compression over no compression. A concerned administrator can enable this feature to reduce the server's exposure to unauthenticated attack in the event that an issue is found in the Crypto++ implementation of zlib compression, which our SSH implementation uses.

File transfer:

The SSH Server can now be configured to execute an On-upload command after a file is written to by an SSH client. The on-upload command can reference expanded parameters SSHUPLOADFILE and SSHUPLOADBYTES, as well as other environment variables. The command can execute a custom action, such as moving the uploaded file to a different directory, or invoking a third-party program to send a notification email.

Advanced mount point parameters FileWhitelist and FileBlacklist are now supported. Using these parameters, the server can be configured to block file operations (e.g. uploads, downloads, and renames) on files that match or do not match specific file name patterns (e.g. extensions).

In mount point settings for Windows accounts and groups in Advanced SSH Server settings, Windows accounts can now be configured to inherit mount points from multiple groups, instead of only the group from which the user normally inherits settings. This allows users to be granted access to a set of mount points A if they are in group 1; a set of mount points B if they are in group 2; and both sets of mount points if they are in both groups, without having to configure individual account settings entries.

Added CuteFTP to the list of clients that must be sent dummy modification time information when an actual modification time is not available. This works around an issue in CuteFTP which prevented it from displaying a directory listing when no root mount point was configured.

Added support for SFTP version packet extensions "supported2", "acl-supported", and "versions". Added support for "version-select" extended packet.

The SFTP STAT request now works with only List permission on the mount point, without requiring the Read permission as well.

Terminal:

The terminal server now sends window titles to xterm clients.

Port forwarding:

Sessions that attempted to register a large number of simultaneous server-to-client port forwarding rules could be terminated by an error. Fixed.

Fixed issues that would arise if a proxy was configured for outgoing connections; if an outgoing connection was attempted to a DNS name that resolved to multiple IP addresses; and if the first of the addresses could not be reached, so that another had to be attempted.

The SSH Server will no longer stop if no interfaces are configured on which it can accept connections. The server will now continue to try to bind any configured listening interfaces, and wait for any settings changes, while the SSH Server Control Panel displays a warning notifying about this state.

Dramatically improved handling of LOG_I_SERVICE_CONFIG_DESCRIPTION with large settings.

Most case-insensitive string comparisons in the SSH Server are now Unicode-aware. We nevertheless do NOT recommend using non-US-ASCII characters in security identifiers, such as account names. Unicode is ever-changing, and consistency of string comparisons for non-US-ASCII characters is not ensured.

Improved disconnection responsiveness and reliability.

BvRun now supports the "-w" flag. Providing this flag causes BvRun to wait until the child process has exited, and return its exit code plus 9000.

Changes in Bitvise SSH Server 6.07: &lsqb; 4 May 2014 &rsqb;

Fixed issue where the SSH Server Control Panel would sometimes refuse to display its main window, especially on slow systems.

Rare crashing bug in the SSH Server Control Panel believed fixed. The Control Panel will now enumerate only its own windows, instead of unnecessarily enumerating all top-level windows. This should avoid the possibility that a window becomes invalid between enumeration and access.

Changes in Bitvise SSH Server 6.06: &lsqb; 18 April 2014 &rsqb;

A change in version 6.05 triggered an issue where, after logging in, the Bitvise SSH Server Control Panel would open displayed instead of minimized, and would have to be minimized manually. Fixed.

In the terminal subsystem, the console history buffer now functions properly when the "discard old duplicates" mode is enabled on Windows Vista or newer.

Security Clarification: &lsqb; 9 April 2014 &rsqb;

We have recently received many inquiries about whether our software is affected by the heartbeat vulnerability in OpenSSL (nicknamed "Heartbleed"). This vulnerability relates to a protocol we do not implement, and a code base that is independent of ours. None of our software shares common code with OpenSSL or OpenSSH.

Changes in Bitvise SSH Server 6.05: &lsqb; 5 April 2014 &rsqb;

SSH server settings can now be imported additively, so that configurations from multiple SSH servers can be consolidated in a single SSH server installation.

In a master/slave configuration, slave servers can now be configured to connect occasionally, with a configurable average delay between connections, instead of maintaining a permanent connection to the master. This should help reduce load on master servers with a very large number of slaves.

Individual adjustment of channel window size has proven to be effective with JSCH-based clients, including Cisco appliances, which contain a race condition causing them to stall unless window size is frequently adjusted. Our SSH implementation will now adjust channel window size individually when communicating with JSCH-based software.

The less secure MD5-based and 96-bit message integrity algorithms are now disabled by default.

Changes in Bitvise SSH Server 6.04: &lsqb; 11 February 2014 &rsqb;

Elliptic Curve support: ECDSA host keys and client keys, as well as ECDH key exchange, are now supported. Initially supported curves are secp256k1, nistp256, nistp384, and nistp521. When used with clients that also support ECDSA and ECDH, this is an improvement in effective cryptographic security from 80 - 112 bits of symmetric security, to 128 or more, depending on the curve chosen.

Installer:

A command line option is now available to abort installation if a specified warning occurs.

Full help text for installer exit codes is now available.

Control Panel and Settings:

Master/slave settings are now fully configurable from the command line using BssCfg, and programmatically using the BssCfgManip COM object.

Virtual account password expiration can now be configured on a per-account basis. If password change is disabled for the virtual account user, this can be used to configure virtual accounts with an expiry date.

For new Windows groups and new installations, the "Map remote home directory" and "Map remembered shares" settings are now enabled by default, to better meet initial user expectations when logging into a Windows account.

On Windows Vista and later, HTTP links are now opened in a non-elevated browser window.

Fixed an error which caused an assertion failure when a Remote Control Panel session fails due to packet overflow.

Fixed two slow GDI handle leaks that could lead to the Control Panel crashing in specific circumstances after running for a period of several weeks (e.g. in slave installations).

Dates are now displayed in a fixed YYYY-MM-DD format, so that lists containing date columns can be sorted by date regardless of Windows locale.

A newly added Listen rule in account settings entries will now have a default Accept rule entry. Previously, an Accept rule entry had to be configured manually for the Listen rule to allow any connections.

Improved log path links in Log folder viewer.

SSH session:

Improved disconnect handling, so that sessions are less likely to hang.

Username blacklisting is now supported. If a client attempts to authenticate with a username blacklisted by the server administrator (e.g. "root"), the originating IP address will be immediately locked out for the default IP blocking duration.

Implemented several adjustments to reduce the possibility of a channel blocking due to buffering and window adjustment issues.

The server will no longer try to create a window station and desktop when a virtual account is running in Local System context, avoiding a log warning.

Implemented several debugging features related to in-window size and window adjustments, to help investigate compatibility issues with JSCH-based clients that block during SFTP upload.

File transfer:

An SFTP success reply will now be sent without a description, cutting packet size by 39 bytes. This might improve compatibility with clients that send a large number of small write requests, but lack a large enough buffer to receive all status replies.

SFTP can now be limited to version 3 on a per-group and per-account basis, to allow focusing specifically on those users who connect with clients that require this.

Terminal:

For clients that do not support UTF-8, the terminal code page used by the server is now configurable on a per-group and per-account basis.

BvLsa authentication module:

Auditing and logging improvements.

Changes in Bitvise SSH Server 6.03: &lsqb; 05 November 2013 &rsqb;

Utilities: The bvRun utility now supports specifying the command to run on the command line without having to enclose it as part of the -cmd="..." parameter.

Control Panel and Settings:

Settings pages are now easier to scroll using the mouse wheel.

Implemented accessibility improvements in SSH Server Control Panel and Settings.

Fixed an issue which could have caused the Log Folder Viewer user interface to become unresponsive if a third-party application was installed that sent an unexpected GUI message.

Version 6.01 implemented tolerance for importing invalid keys from a previous version of SSH server settings, but only for public keys stored under accounts. This handling is now extended to public keys stored under groups, as well.

Authentication: Implemented a workaround for a memory leak in lsass.exe, which would previously appear when handling SSH logins on recent Windows versions.

SSH session:

Implemented ability to log and debug changes in channel window sizes.

Fixed an issue which caused an SSH session to terminate prematurely if the client sent a characteristic SSH_MSG_DEBUG packet.

Exec requests: Implemented a workaround to improve compatibility with Git. The SSH server can now detect exec requests sent by Git, and convert any single-quoted strings into double-quoted strings that work on Windows.

Terminal: Fixed an issue with Home and End keys not working with PuTTY.

Installation: Fixed an issue which caused the uninstaller to incorrectly believe that a system restart is necessary in order to complete uninstallation.

File transfer: With clients that do not specify otherwise, the SSH server will no longer request exclusive write access when opening files the client requested to open for writing. This improves compatibility with clients that open multiple handles to a file and expect to be able to write to them simultaneously; and also, occasions when a client reconnects and attempts to resume a transfer when the server hasn't yet detected termination of the previous session.

Changes in Bitvise SSH Server 6.02: &lsqb; 30 July 2013 &rsqb;

Fixed a command line parsing issue which prevented quoted parameters from working properly. Commands such as 'bvRun -brj -cmd="..."' now work correctly again.

Fixed an issue which caused IPv6 bit masks to not be generated correctly when significant bits wasn't a multiple of 16.

Changes in Bitvise SSH Server 6.01: &lsqb; 12 July 2013 &rsqb;

Control Panel and Settings:

Bitvise SSH Server now supports master/slave configuration. In clusters and large installations, one SSH server installation can be configured as the master, while secondary installations can be configured as slaves. The slaves will connect to the master, and automatically download and apply settings and configuration changes from the master.

Per-user bandwidth limits are now supported. The administrator can limit the maximum speed with which a user can transfer data to or from the server, either per session, or for all concurrent sessions from a user.

It is now possible to configure different IP address restrictions for incoming connections on a per-account or per-group basis.

Improved automatic router configuration to also support devices that expose only UPnP version 2.

File transfer speeds will now again be correctly displayed on the Activity tab. A bug caused file transfer speeds to not be displayed correctly in versions 5.50 - 5.60.

Improved memory consumption of SSH server settings when a large number of accounts are configured.

Improved support for Microsoft identity accounts (e.g. of the format ...@hotmail.com).

Improved backward compatibility when importing settings from versions 3.xx and 4.xx. Proxy profiles and SFTP root directories will now be properly imported from WinSSHD 3.xx. Any invalid public keys in account or group settings entries will now be skipped when importing from WinSSHD 3.xx or 4.xx.

BssCfg command line parameters are no longer case-sensitive.

The SSH Server Control Panel will now work correctly in high-contrast mode.

A warning dialog will now be displayed when the SSH server is started with the Windows Firewall management feature configured so as to restrict access to connections from the local subnet only.

Unblocking an IP address will now also clear records of previously failed authentication attempts, so that the next authentication failure will not immediately result in another blocking.

The automatic IP blocking feature now supports a configurable whitelist. Addresses entered into the whitelist will not be affected by automatic IP blocking.

The settings "Tolerate first window fault" and "Maximum subsequent fault bytes" have been obsolete since SSH server version 5.00, and have been removed.

Authentication:

The SSH public key management subsystem is now supported. Access to this feature can be enabled on a per-user or per-group basis in Advanced SSH server settings. Users for whom this feature is enabled can manage their public keys on the SSH server if they connect with a client that also supports this feature.

Improved the way the SID of the local computer is retrieved. Previously, Bitvise SSH Server would retrieve the wrong local computer SID if there was a local account with the same name as the computer. This would cause the SSH server to incorrectly treat local accounts as if they were domain accounts.

SSH session:

Improved CPU usage in the SSH server's core infrastructure. Transfer speeds in local loopback testing should now again be where they were in WinSSHD 4.xx. Users should see a decrease in the server's CPU consumption, given the same transfer speeds.

Re-implemented SSH session data buffering in order to improve responsiveness for slow clients.

Fixed an issue which would cause high CPU usage if the client closed a channel in a non-ready state.

The SSH protocol specification is unclear on whether the maximum packet size in the channel data packet refers to the whole packet, or payload only. Previously, Bitvise SSH Server used the interpretation that the size refers to payload only. This caused a compatibility issue with the Axway client. Our implementation has been changed to interpret the outgoing maximum packet size as referring to the whole packet.

Fixed issue which caused key re-exchange to not be triggered by the server after a one hour timeout. Key re-exchanges started by the client were still accepted, and key re-exchange was triggered by the server after 1 GB of data transferred.

Environment variables:

Advanced environment variable syntax is now supported in the same style as used by the Windows command interpreter, and as described in "help set". In addition to basic syntax (%SOMEVAR%), the following suffixes are supported: %SOMEVAR:~N%, %SOMEVAR:~N,M%, %SOMEVAR:findStr=replaceStr%, %SOMEVAR:*findStr=replaceStr%. This allows administrators to configure a single group-wide rule to map structured home directories. For example, a home directory structure such as M:\Home\a\Aaron, M:\Home\b\Benjamin, can be configured with M:\Home\%USERNAME:0,1%\%USERNAME%.

Child processes launched over an SSH session will now receive an environment variable named SSHSESSIONID, which can be used to identify the SSH session. Separate terminal sessions will still receive the same SSHSESSIONID if they are launched over the same SSH connection.

If SSH server settings permit the client to set environment variables, environment variables set by the client will no longer be used when expanding environment variables in terminal shell or exec request prefix strings configured in SSH server settings. Environment variables provided by the client will still be available to child processes started by the client.

Terminal:

Advanced environment variable syntax is now supported in the same style as used by the Windows command interpreter, and as described in "help set". In addition to basic syntax (%SOMEVAR%), the following suffixes are supported: %SOMEVAR:~N%, %SOMEVAR:~N,M%, %SOMEVAR:findStr=replaceStr%, %SOMEVAR:*findStr=replaceStr%. This allows administrators to configure a single group-wide rule to map structured home directories. For example, a home directory structure such as M:\Home\a\Aaron, M:\Home\b\Benjamin, can be configured with M:\Home\%USERNAME:0,1%\%USERNAME%.

Child processes launched over an SSH session will now receive an environment variable named SSHSESSIONID, which can be used to identify the SSH session. Separate terminal sessions will still receive the same SSHSESSIONID if they are launched over the same SSH connection.

File transfer:

It is now possible to create multiple nested directories at the same time using a single "make directory" command.

Known Issues

Windows 10: As of July 2017, if the SSH Server setting Open Windows Firewall is set to a value other than Do not change Windows Firewall settings, the latest versions of Windows 10 may log this during system shutdown: The Bitvise SSH Server service did not shut down properly after receiving a preshutdown control. After investigating, we find that even though the SSH Server has a dependency on the Windows Firewall service in this configuration, Windows appears to over-aggressively shut down related functionality, so that the SSH Server cannot deinitialize. We have at this time not found a solution, and believe that a fix is needed by Microsoft. Affected users can avoid this issue by configuring the SSH Server with Do not change Windows firewall settings. If this is done, a rule to allow access to the SSH Server must be added in Windows Firewall settings manually.

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.