For issues that might arise using the latest SSH Server versions, see Known issues.
Changes in Bitvise SSH Server 8.47: [ 3 April 2021 ]
The SSH Server's upgrade access amnesty continues, so that all users of previous 8.xx version can update to the latest version with accumulated fixes. The minimum upgrade access to use this version is October 23, 2018.
We are at this point highly confident in the security, stability and compatibility of our latest 8.xx versions. We are aware of users still relying on versions 7.xx and 6.xx, and sometimes even older. The SSH Server is security-sensitive, network-facing software, and updating is the only way to receive the latest security and reliability fixes. We suggest all users update.
Control Panel and settings:
Newly created virtual groups no longer have a default mount point that maps the virtual root directory to C:\SftpRoot. Users of Advanced settings who were unaware of this default mount point found the behavior confusing if they did not create a mount point for the virtual root in individual account settings.
When a new virtual account is created using Advanced settings, it will now by default have no mount points at all. Virtual accounts created using Easy settings will continue to have a default Limit to root directory setting that restricts the user to C:\SftpRoot.
Fixed a situation where settings scrolling could behave incorrectly after expanding and collapsing certain help texts.
Added optional trace log events for unsuccessful UPnP NAT forwarding add/remove actions.
When using the bvterm terminal on earlier versions of Windows, if the user pressed Ctrl+S, this could cause the terminal server to stop accepting input. Fixed.
Changes in Bitvise SSH Server 8.45: [ 30 December 2020 ]
If the automatic update process encountered an error while downloading a new version installer from the primary download location, resulting in a partial executable being stored; and if download was then successful from the secondary download location; the resulting executable would be corrupted. Fixed.
Improved the automatic update locking mechanisms.
Control Panel and settings:
When the SSH Server Control Panel was started hidden in the system notification area, it would cause a phantom Alt-Tab menu entry to appear. Fixed.
Generating a new employed certificate for FTPS did not immediately update certificate information on the Server tab. Fixed.
When monitoring session activity on busy servers, the Activity tab could experience repeated overflows of events from the SSH Server. Buffering flexibility has been improved to reduce this problem.
Fixed a GDI leak that could lead to resource exhaustion in the SSH Server Control Panel (not the main SSH Server process). This could happen, for example, if UI elements were opened and closed a very large number of times that is not usually experienced by users.
Previous SSH Server versions came configured by default to limit the number of sessions with processes to 60. This can be easily changed, but requires finding the setting in Advanced settings, under Session. The default limit accommodated an OS desktop heap limitation in Windows XP and Windows Server 2003, which are now rarely used. For new settings, the default limit is now 500 sessions, and applies to all sessions (not only sessions with processes).
The SSH Server process could stop unexpectedly if settings in Advanced settings, under Logging, were first configured so that the settings description event would not be logged, and then changed so that it's logged. Fixed.
Improved compatibility of BvShell with virtual filesystem settings configured as blind drops. BvShell will no longer fail to start if the initial directory cannot be opened for listing.
Changes in Bitvise SSH Server 8.44: [ 4 October 2020 ]
If an update is available and settings are configured to automatically apply it, then when the SSH Server Control Panel is started, it will no longer initiate the update immediately, but will instead wait for some time (currently 5 minutes). This offers the administrator a window in which to change automatic update settings, in case the administrator wants to modify them.
When using the authentication method keyboard-interactive, an implementation that identifies itself as "SSH-2.0-libssh-0.6.5" sends the message SSH_MSG_USERAUTH_REQUEST without encoding fields for the language tag and submethods. These fields are required, but since they are not critical, the SSH Server will now treat them as empty if they are missing.
Improved stability of the new Windows 10 terminal console when resizing. The new Windows 10 console has a bug where it will crash if the cursor lands outside of the screen buffer after a resize. The SSH Server now detects this situation and works around it.
In previous versions, each FTPS connection would cause a small file to be created, and never deleted, in the directory C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18. Fixed.
Changed the behavior of the Maximum wait time setting for the On-upload command. Previously, it was a mistake to set this to a value other than 0 seconds (the default). However, when this value was set to 0 seconds, and Execute as service was disabled (also the default), the last On-upload command in a session could be terminated prematurely if it did not complete quickly when a session disconnected.
The SSH Server now no longer waits for an On-upload command to complete, except optionally after a session has disconnected. The Maximum wait time now applies only in this situation, and it causes the SSH Server to wait for this amount of time before forcefully terminating the command. If set to zero, the SSH Server will not wait with session cleanup, and will also not forcefully terminate the command.
Changes in Bitvise SSH Server 8.43: [ 6 June 2020 ]
This version extends the SSH Server's upgrade access amnesty so that all users of previous 8.xx version can update to the latest version with accumulated fixes. The minimum upgrade access to use this version is October 23, 2018.
Previous SSH Server 8.xx versions had a race condition which could cause the SSH Server to crash on startup. The crash did not cause a vulnerability or loss of data, but it did require the service to be restarted. In our testing, a crash occurred in 1 out of 200 - 300 startups. The chance of crash could be higher on certain computers or in certain situations, such as when a new version was started immediately after an update. Fixed.
When the SSH Server is first installed, it will now configure Windows service failure actions (Recovery options) to automatically restart the service if it crashes, up to two times in a day. The SSH Server is never intended to crash, and we want it to be noticeable if it does, so that the issue is reported. However, we also do not want users to suffer unnecessary outages if a crash does occur.
In most cases, this change will not affect users upgrading from previous versions. During an upgrade, configured service failure actions – or lack of them – will be preserved, except in situations that require the previously existing service to be unregistered.
On completion of an update, a spurious warning would be logged in the Windows Event Log about failing to restart the SSH Server Control Panel. Fixed.
On Windows XP, when an update was started automatically or through the SSH Server Control Panel, the installation console window would stay open indefinitely until the log process was forcibly closed, such as by using the Windows Task Manager or Process Explorer. Fixed.
On Windows 10, the installer would create a shortcut to the SSH Server Control Panel in the Start Menu. However, Windows would detect this as a duplicate of the shortcut in Administrative Tools, and would hide the shortcut from the user. Fixed.
Changes in Bitvise SSH Server 8.42: [ 9 May 2020 ]
The SSH Server no longer supports installation on Windows 10 versions 1507 and 1511. These versions contain a flawed cryptographic implementation which prevents a number of SSH algorithms from working correctly. The lowest Windows 10 version supported is 1607.
During an initial, interactive installation; when installing into a non-default directory (e.g. outside of C:\Program Files\); the SSH Server installer will attempt to detect if any parent of the installation directory grants insecure permissions for non-administrative users. The installer will display a warning about installing into such insecure directories.
When updating an installation in such a directory, the update will succeed, but the SSH Server Control Panel will display a warning.
Control Panel and settings:
The FTPS passive port is now configurable in Easy settings and has a default fixed value 20020. The previous default value, 0, would cause the passive port for data connections to be randomly selected each time the SSH Server was started. This required using Advanced settings to configure FTPS access from the internet when a router or firewall needed to be manually configured.
The Log Folder Viewer now starts faster when the log directory contains many log files.
The SSH Server Control Panel could crash when interacting with the Host keys and fingerprints interface in instance type settings for slaves and secondary masters. Fixed.
During CSV import, boolean values are now recognized regardless of character case. Boolean values had to be lowercase previously.
The difference comparison algorithm used for logging settings changes had a rare corner case which would cause the SSH Server to stop in a controlled but definitely unintended way. Fixed.
In rare circumstances, an SSH session could terminate in such a way that the SSH Server would crash. Fixed.
OpenSSH 6.2 and 6.3 can be configured to enable AES GCM, but crash if it is used. Bitvise software versions 8.42 and higher will now disable AES GCM if the remote version string indicates an affected OpenSSH version.
The SSH Server will now log the host key algorithm negotiated by a client in the message I_SESSION_KEY_EXCHANGE_ALGORITHMS.
In specific circumstances, a logon attempt could get stuck waiting for serialization due to the Penalty login attempt delay setting. The session would not be released until the next login attempt initiated by another session. Fixed.
The log message I_LOGON_AUTH_DISCARDED has been changed from info-level to more appropriate trace-level.
Improved protections on SSH Server subsystems for file transfer, terminal shell and exec requests. The improvements protect against SSH clients with non-administrative access which are nevertheless granted the ability to run arbitrary code, such as through unrestricted Command Prompt or PowerShell access. The improvements are not effective on Windows 7 and Windows Server 2008 R2 due to limitations in those Windows versions.
Fixed an issue where BvShell would log superfluous, non-informative info-level messages for each entry in a directory listing.
BvShell now supports the command sh to enter a simulated sh-like shell. This is to improve compatibility with the SCP implementation in the IBM Workload Scheduler on AIX, which supports SCP but not SFTP, and expects to invoke an sh shell. These are some poor design decisions on behalf of IBM, so that further accommodations may still be needed.
Changes in Bitvise SSH Server 8.41: [ 14 February 2020 ]
This is not a new feature release, but a successor to 8.39 with continued maintenance updates.
We skip versions containing zeros to avoid misunderstandings. For example, 8.04 and 8.40 might both be called "8.4".
The CSV list import feature which is accessible from list views in graphical settings is now able to import plaintext passwords. This is useful, for example, when importing a list of Windows file shares or virtual accounts.
To reliably import a plaintext password, prefix it with "p:". Plaintext passwords that are not prefixed with "p:" will also import, as long as the content of the password does not start with "p:" or "h:". Then it may cause an error or import incorrectly.
The "h:" prefix is for a hexadecimal representation of an internal format which exists so that round-trip export and import preserves settings. The "h:" format is not meant to be generated by users, but will be generated when exporting settings in CSV format, and can be re-imported as-is.
In version 8.35, we made a change where newly created mount points for file transfer are now configured by default to allow other processes to share files for Read and Delete access, and no longer for Write access. Previous versions would use a default that also permits sharing for Write access.
Due to the changed default setting value, users who upgraded from a previous version to 8.35 or higher would find that Easy settings no longer shows their accounts with a single mount point configured as Limit to root directory, but now shows them as Configure multiple mount points. The single mount point would still be properly configured and work as before. We have relaxed this logic so that such accounts will once again show as Limit to root directory, as the user expects.
We received a report indicating that WS_FTP can intermittently fail to correctly handle a global request, disconnecting with a protocol error. Until further news, our SSH Server now treats all versions of the WS_FTP client as incapable of receiving global requests.
A number of clients, including PuTTY and OpenSSH, are now likely to try GSSAPI authentication always when connecting, by default. In previous versions, this could cause the following message to be frequently logged in the SSH Server's textual log files, as well as displayed on the Activity tab:
None of the GSSAPI mechanisms advertised by the client are supported or enabled.
This would cause some users to think that if a connection has a problem, this must be the cause of the problem. This message is never the cause of a problem, unless your problem is specifically with GSSAPI.
This is therefore now a Trace-level log message and is no longer displayed in the Activity tab.
For improved compatibility with clients such as the vCenter Server Appliance which expect an SCP server to support chmod, BvShell now supports a chmod command which always succeeds and does nothing.
Changes in Bitvise SSH Server 8.39: [ 16 January 2020 ]
In version 8.38, the built-in help text inadvertently used an incorrect font. Fixed.
Changes in Bitvise SSH Server 8.38: [ 12 January 2020 ]
The SSH Server installer now supports more convenient command line parameters to configure automatic updates (including to disable them) without having to accompany the installer with an additional instance settings file.
Any error that may have occurred during the last check for updates will now be cleared and no longer shown after disabling checking for updates.
Since versions 8.xx, the SSH Server now uses multiple heaps to reduce contention for memory allocation and freeing. Among other things, this dramatically reduces time to shutdown when handling many simultaneous connections.
In previous 8.xx versions, on computers with many CPU cores, the SSH Server could use too many heaps. In certain usage scenarios, this could cause very excessive memory consumption. The SSH Server will now use a radically smaller number of heaps on computers with many cores.
When public key or private key import fails, a more accurate error message will now be displayed in certain cases.
In 7.xx and earlier versions, automatic IP blocking could be disabled by setting any of the three main IP blocking settings to 0. When upgrading to 8.xx, if the setting IP blocking - threshold was set to 0, but the other two settings were non-zero, then IP blocking would be incorrectly enabled after the upgrade. Fixed.
Thanks to user feedback, we identified a circumstance where looking up a Windows account in a different domain, where the relationship is an external trust, may cause Windows to return a malformed account name such as domain\user@domain. The SSH Server is now able to handle this, so that such accounts can still log in.
Changes in the SSH Server's terminal subsystem in versions 8.xx have made the bvterm protocol unreasonably slow with certain console applications. Bitvise SSH Server and SSH Client versions 8.38 implement optimizations in both the server and client to address these issues.
Re-categorized another type of event related to FTPS disconnect as an Info which was previously incorrectly a Warning.
Changes in Bitvise SSH Server 8.37: [ 25 November 2019 ]
Reliability issue: In SSH Server version 8.21, we introduced difference comparisons to reduce an overwhelming amount of logging that would previously occur when large SSH Server settings were changed. We recently discovered the difference comparison algorithm had corner cases which could cause it to run out of stack and cause the SSH Server to crash. Fixed by using a new difference comparison algorithm which is non-recursive and has better and more consistent performance.
We received multiple reports indicating that the SSH.com Tectia client, when connecting from a mainframe, intermittently reports an error consistent with the client incorrectly handling global requests during a channel open. Until further news, the SSH Server now treats all versions of the SSH.com Tectia client as incapable of receiving global requests.
When a proxy profile is configured for client-to-server port forwarding, if the setting Resolve locally was enabled, the SSH Server would often resolve DNS names remotely (via the proxy) anyway. Fixed.
In a terminal console, Shift+Tab will now cycle items in reverse direction (opposite of Tab), as expected.
In BvShell, the command mkdir -p now succeeds if the directory already exists. This brings its behavior in line with mkdir in bash, improving compatibility with SCP clients that send commands like "mkdir -p .", expecting them to succeed.
Self-signed certificates for FTPS, as well as certificate signing requests, were previously incorrectly generated using RSA + SHA-1 signing instead of RSA + SHA-256. Fixed (on Windows Vista and newer; limited to SHA-1 on Windows XP and 2003).
Self-signed certificates for FTPS were previously generated without certificate signing enabled in encoded key usage. This prevented self-signed certificates from working with e.g. curl --cacert. Fixed.
Re-categorized a type of FTPS disconnect event as an Info which was previously incorrectly a Warning.
Security Notification: [ 27 October 2019 ]
Authors of the Minerva attack have identified a small but significant timing information leak in the Crypto++ implementation of ECDSA over prime field curves. This attack may allow discovery of a private key through repeated observation of signature timing. If the leak can be utilized, an attacker could compromise a server host key or a client authentication key using a practical number of connections across a network.
The following is the impact on Bitvise SSH Server, SSH Client and FlowSsh versions before 8.36:
On all recent Windows versions (Vista and higher), there is no effect on users of Bitvise software versions 7.xx and 8.xx who use private keys of algorithms RSA, Ed25519, or ECDSA over the NIST curves nistp256, nistp384 or nistp521. On all recent versions of Windows, and using recent Bitvise software versions, these algorithms use Windows cryptography, which is unaffected by Minerva. In the case of Ed25519, we similarly use a non-Crypto++ implementation, which is unaffected.
On all versions of Windows, using all versions of Bitvise software, the Minerva issue may apply to users who generated, and are using, host keys or client keys of type ECDSA/secp256k1. Bitvise software versions 8.35 and earlier use Crypto++ to implement this algorithm on all platforms. We encourage such users to update to our latest software versions.
On Windows XP and Windows Server 2003, regardless of Bitvise software version; and for Bitvise software versions 5.xx and 6.xx, regardless of Windows version; the Minerva issue may apply to users of ECDSA private keys of any type. We encourage such users to update to our latest software versions, and/or to update to newer versions of Windows.
With Bitvise SSH Server, SSH Client and FlowSsh 8.36, we are releasing the following mitigations:
On all recent Windows versions (Vista and higher), where we previously used Crypto++ to support ECDSA/secp256k1, we are switching to alternatives. If the version of Windows is recent enough (for example, Windows 10, Windows Server 2016 and 2019), our default cryptographic provider (CiWinCng) now uses Windows cryptography to support ECDSA/secp256k1 as well as ECDH/secp256k1. Where Windows does not support secp256k1 (for example, Windows Vista to 8.1 and Windows Server 2008 to 2012 R2), we now support it using OpenSSL.
On Windows XP and Windows Server 2003, we face the issue that maintained cryptographic libraries that continue to support these platforms are hard to switch to and harder to find, while the number of users is small and diminishing. In current versions, we continue to rely on Crypto++ on these platforms, but implement mitigations to make it harder or impossible to observe signature timing across the network.
On all versions of Windows, we continue to use Crypto++ to support non-standard DSA keys. These are DSA keys as used in SSH of size other than 1024 bits. Since versions 7.xx, we have discouraged the use of DSA keys of any size. Also, DSA is not within scope of the Minerva research, so the current attack does not apply directly. Nevertheless, because we use Crypto++ to support non-standard DSA keys on all platforms, we now activate mitigations for these keys to make it harder or impossible to observe signature timing remotely.
Changes in Bitvise SSH Server 8.36: [ 27 October 2019 ]
On Windows 10, Windows Server 2016 and 2019, the algorithms ECDSA/secp256k1 and ECDH/secp256k1 now use Windows cryptography. As a result, these algorithms are now also available when FIPS mode is enabled in Windows.
On Windows Vista to 8.1, and Windows Server 2008 to 2012 R2, the algorithms ECDSA/secp256k1 and ECDH/secp256k1 now use OpenSSL instead of Crypto++. As a side effect, use of these algorithms on Windows Vista now requires at least Service Pack 1 (OpenSSL will fail to initialize on Vista without service packs).
On Windows XP and Windows Server 2003, our software continues to use Crypto++ for all algorithms, but implements mitigations to make it harder or impossible to observe signature timing remotely. Continuing support for these Windows versions is increasingly impractical for multiple reasons including cryptography. Like Microsoft and other software vendors have done, we will need to stop supporting these platforms eventually, but we still support them right now.
Fixed an issue in the SSH Server's terminal subsystem where, using the new Windows 10 console, a cursor position reset would not cancel delayed line wrapping. This was apparent with PowerShell input line wrapping - a second line would incorrectly show characters from the first line.
User feedback identified a client - SmarTerm - which doesn't properly handle global requests, and advertises itself as OpenSSH version 3.5p1 (an OpenSSH version that's 17 years old). To address this, we raise the criterion for OpenSSH client global request compatibility from version 3.1 to include version 3.5.
Changes in Bitvise SSH Server 8.35: [ 20 August 2019 ]
Fixed an issue in Easy settings where any additional port bindings previously configured in Advanced settings would be removed when Easy settings was saved.
For newly created mount point settings entries, the default File sharing setting now prohibits simultaneous write access by other processes. Read and delete access remain allowed by default.
This changes default behavior to prevent a subtle failure where another process – a task or file transfer session – can corrupt a file while it is being uploaded. As a side effect, configurations that require write sharing – for example, to perform a hot-copy of a database – now must modify the File sharing setting in Advanced settings for newly created mount points.
Already configured mount points will continue to function without change.
Fixed an issue where the mount point setting File sharing behavior did not take effect as configured, but in most cases took effect as if it was set to Default.
The 3DES encryption algorithm has known weaknesses, is rarely needed for compatibility, and now triggers warnings in some vulnerability scanners. In newly created settings, the SSH Server now disables the algorithm 3des-ctr by default. (The older, related algorithm, 3des-cbc, has additional weaknesses and has already been disabled by default since version 6.41.)
Fixed an issue in Telnet forwarding as configured by setting Shell access type to Telnet server. Telnet sub-negotiation was being handled incorrectly and could cause the terminal session to hang.
The Manage certificates interface now supports viewing the public key associated with a private key entry which does not yet have an associated certificate.
Changes in Bitvise SSH Server 8.34: [ 17 June 2019 ]
The SSH Server Control Panel now shows more accurate login failure descriptions on the Activity tab. In previous 8.xx versions, detailed information was available in the SSH Server's textual log files, but the Activity tab displayed only a base description for an entire error class. This description was often inaccurate and misleading: "The supplied user name could not be looked up."
Improved logging when password-less logon to a Windows domain account fails in a way that is most likely caused by insufficient Active Directory permissions.
There exist interim, but deployed versions of SSH implementations including SmartFTP which implement the no-flow-control extension based on a previous, non-final draft where the extension value was empty. Bitvise SSH Server, SSH Client and FlowSsh will now no longer disconnect when receiving an unrecognized no-flow-control extension value, but will attempt to continue; and will now treat an empty value as if the remote party sent "p" (for "preferred").
Improved logging of Warning and Trace-level events related to Windows profile loading.
Changes in Bitvise SSH Server 8.33: [ 28 May 2019 ]
Previous 8.xx versions would not trim leading and trailing spaces from client-provided user names on the basis that technically, such accounts could be configured in Windows. In practice, there are effectively no users who want to use usernames like that, but there are clients that unknowingly send usernames with leading or trailing spaces. The SSH Server will now trim leading and trailing spaces from user names, including Unicode spaces.
An added difficulty was that the SSH Server would trim the spaces from user names when logging them, but not when looking them up. This would make it difficult to realize that extra spaces were the reason login did not work.
Improved logging for two types of ADSI errors where the underlying issue is that the SSH Server lacks necessary permissions in the Active Directory. The errors would manifest as:
ADsOpenObject(user, Kerberos) failed: COM error 0x80072030: There is no such object on the server.
IADsUser::Get(msDS-User-Account-Control-Computed) failed: COM error 0x8000500D: The property cannot be found in the cache.
Check Using Bitvise SSH Server in a domain for more information about the Active Directory permissions needed.
SSH: Very old PuTTY versions before 0.58 are now treated as not global-request capable. When these versions are waiting for a channel open confirmation, they will treat any packet other than a channel open confirmation as a failure (including if the packet is a global request).
If synchronization with authorized_keys was enabled, and a user was logged off due to changed settings no longer permitting login, a null pointer read would occur. Fixed. The issue did not have consequences besides logging an error.
SCP: Reduced superfluous logging of I_SFS_GET_FILE_STATUS due to an internal event at the start of an SCP command.
Installation and upgrade:
In previous 8.xx versions, when upgrading from WinSSHD 4.xx and earlier (last such version was released in November 2008), users who should be limited to a specific directory would be incorrectly granted unlimited filesystem access. Fixed.
Automatic updates would fail for instances with non-normalized names (for example, names containing dots). Fixed. Users of affected instances may still need to manually update to this version or later by directly running the new version installer.
Added some verbosity in the installer, in particular to help diagnose situations where an antivirus might prevent the installer from launching a child process. This can prevent an installation or an update from completing.
The SSH Server EULA received a minor update to clarify the meaning of Machine. The meaning remains consistent with our current and past licensing practice.
Changes in Bitvise SSH Server 8.32: [ 18 April 2019 ]
The fix for the server-stopping issue in version 8.31 introduced a new issue where keyboard-interactive authentication would always fail if the setting Penalty login attempt delay was set to 0 seconds. Fixed.
The keyboard-interactive method is used for two-factor authentication using time-based one-time passwords (TOTP). It is also preferred by some clients as a way to perform password authentication.
DNS name rules now permit DNS names with underscores in any position where an alphanumeric character was previously valid. This accommodates users with internal host names that contain underscores (not otherwise valid on the internet).
SSH Server Control Panel: Fixed an issue which prevented a CSV file from being imported if it consisted of a single line without a line terminator.
Changes in Bitvise SSH Server 8.31: [ 15 April 2019 ]
This is not a new feature release, but a successor to 8.29 with continued maintenance updates.
We skip versions containing zeros to avoid misunderstandings. For example, 8.03 and 8.30 might both be called "8.3".
Fixed an issue where, given specific timing and combination of logon attempts, it was possible for the SSH Server to stop in an unplanned but controlled manner due to an unexpected condition.
Fixed a memory safety issue which seems to be hard to trigger, but could have security ramifications.
Added error descriptions for Windows error codes related to checking for new versions and downloading updates.
Fixed an issue where the password authentication failure reason AuthMethodDisabledGlobally was logged incorrectly as AuthMethodDisabledByClientVersion, and the other way around.
When exporting an OTP secret key as a 2D code image in monochrome bitmap format (1 bit per pixel BMP), an all-black image would be generated. Fixed.
Changes in Bitvise SSH Server 8.29: [ 23 March 2019 ]
The next Windows 10 update 19H1 is bringing a new terminal console incompatibility which would prevent the SSH Server's terminal subsystem from starting. This version addresses the issue.
Changes in Bitvise SSH Server 8.28: [ 15 March 2019 ]
Fixed an issue in previous 8.xx versions where, if an SSH Server instance configured as a slave or secondary master was upgraded from a version before 8.xx, it failed to create an update-related registry key. This caused an SSH Server thread to spin indefinitely with high CPU consumption.
The Sessions tab in the SSH Server Control Panel would incorrectly display an account type for connections that have not yet authenticated. Fixed.
The right-click pop-up menu on the Sessions tab to select session view columns was missing an option for IP location. Fixed.
File transfer: On drive letter root directories, such as C:\, Windows enables the attributes System + Hidden ("super-hidden"). The SSH Server will now remove these two attributes on drive letter root directories in stat requests and directory listings.
Changes in Bitvise SSH Server 8.27: [ 4 March 2019 ]
When using terminal modes other than bvterm, the SSH Server would previously generate the following keys as if they were coming from the numeric keypad: arrow keys, Insert, Delete, Home, End, Page Up, Page Down. These keys will now appear to programs running under SSH Server terminal emulation as if they are coming from dedicated (enhanced) keys.
Changes in Bitvise SSH Server 8.26: [ 22 February 2019 ]
Fixed issue introduced in version 8.22 where the Persistent Tray Icon setting would no longer function correctly in situations with multiple concurrently installed instances.
Changes in Bitvise SSH Server 8.25: [ 18 February 2019 ]
When a session was rejected because a configured Client version rule did not permit the client software version, the connection was kept around until a user authentication timeout expired instead of being disconnected immediately. Fixed.
Changes in Bitvise SSH Server 8.24: [ 26 January 2019 ]
Fixed installation and startup issues when there are instances named Bitvise SSH Server - WinSSHD or WinSSHD - Bitvise SSH Server and similar variants.
The LIST command can now also list an individual file path instead of only a directory.
A LIST command like LIST -al *.txt will now be interpreted as intended.
Directory listings returned by the LIST command will now have symbolic links resolved.
The OPTS UTF8 command is now supported.
Improved error reporting regarding certificate management.
To avoid unnecessary complications with re-verifying self-signed FTPS certificates, new self-signed certificates will now have a validity of 15 years.
Installation will now continue instead of failing when generation of a self-signed certificate fails. If the administrator wishes to use FTPS, a certificate can be generated later.
Fixed a number of BvShell corner case behaviors, especially related to text reading and command parsing.
Improved SCP exit code handling and use of the correct code page.
The ls command now supports the parameters -A and --almost-all.
The mkdir command now ignores the -p and --parents parameters instead of rejecting them. The default filesystem provider already creates parent directories by default.
When settings are changed locally, any reversibly encrypted passwords will no longer be re-encoded to avoid the logging of spurious diff segments. For the time being, when settings are changed remotely - using the SSH Server Remote Control Panel via Bitvise SSH Client - spurious diff segments related to passwords will still occur.
Reduced unnecessary logging of the Info-level log event I_LOGON_TOKEN_ELEVATION_CHANGE_FAILED.
Reduced unnecessary Info-level log events resulting from internal FTPS handling.
Changes in Bitvise SSH Server 8.22: [ 21 December 2018 ]
A trivial UI change in 8.21 prevented saving a group or account settings entry in Advanced settings if a mount point was configured with Allow unlimited access and its Real root path was empty. Fixed.
In addition to the fix in 8.21 to support filesystems mounted using the Windows Client for NFS, this version implements a further workaround for SetFileInformationByHandle, so that attributes such as file times can be correctly set.
Our testing indicates that Client for NFS filesystems should now again work well with Bitvise SSH Server.
The new 8.xx -certificates=... parameter for the SSH Server installer did not work. Fixed.
If the SSH Server Control Panel was run by a non-administrative user (requires disabling UAC), it would display a difficult-to-understand error. In this case, the SSH Server Control Panel will now display a more understandable message. If the SSH Server Control Panel was scheduled to run when the user logged in, the scheduled task will now also be removed.
When the SSH Server communicates a textual disconnect reason to a client; and a more accurate numeric disconnect reason is available than SSH_DISCONNECT_BY_APPLICATION; the SSH Server will now send the more accurate reason code.
Changes in Bitvise SSH Server 8.21: [ 17 December 2018 ]
In past versions, when using default settings for logging, the SSH Server would record its entire settings in the textual log file each time they were changed while the SSH Server was running. To improve readability of changes, and to reduce log spam on servers with large settings, the SSH Server will now record difference comparisons between old and new settings.
The Windows feature Client for NFS, used to mount network filesystems, does not support a file attribute operation on which the SSH Server has been relying since version 7.21. With filesystems mounted via Client for NFS, subdirectory traversal would fail with an error involving GetFileInformationByHandleEx and FileAttributeTagInfo. The SSH Server now implements a workaround for this issue.
A further workaround is necessary for SetFileInformationByHandle in order to correctly set attributes such as file times. We plan to release this in version 8.22.
Since versions 8.xx, Bitvise SSH Server and Client support an important new feature, host key synchronization. This allows a supporting client to automatically roll over to new server host keys without requiring manual configuration.
Host key synchronization requires clients – all that connect, including those that do not implement host key sync – to accept global requests. Almost all clients do – this is what RFC 4254 requires. Our users have identified clients which, in violation of the SSH protocol, disconnect when they receive a global request.
We have reports of the following SSH version strings sent by clients with this behavior:
- "WeOnlyDo" – older versions, but new ones send the same version info
- Ancient OpenSSH: clients older than version 3.1 (released 2002 – 2004)
To accommodate these clients, SSH Server 8.21 now implements a whitelist of clients which can handle global requests. For now, global requests will not be sent to clients not on the whitelist. In a future version, this will be configurable.
With versions 8.xx, the SSH Server Control Panel switched to newer, nicer Windows UI elements for dialogs such as exporting settings. It turns out these UI elements are unavailable on Windows Server Core. The SSH Server Control Panel will now detect Windows Server Core and use older versions of UI elements.
This may not resolve all issues on Windows Server Core. Administrators may need to use the BssCfg command line configuration utility or PowerShell scripting.
For FTPS clients, the SSH Server will now close the control connection if password authentication is not available or no longer available.
To improve compatibility with the vCenter SCP client, BvShell now responds to test -r and test -w in addition to previously supported test -d and test -f parameters.
The SSH Server implements further improvements to automatic IP blocking.
In previous 8.xx versions, the SSH Server would not import RSA private and public keys larger than 8192 bits. This limit is once again 16384 bits.
The SSH Server installer will now offer to wait instead of exiting when another Bitvise installation is already in progress.
Slightly improved the user friendliness of the installer and uninstaller for command-line installations.
We are receiving occasional inquiries about whether our software is affected by the libssh vulnerability CVE-2018-10933, where a client can bypass authentication by sending an SSH_MSG_USERAUTH_SUCCESS message to the server.
Bitvise software does not share common code with libssh. Our understanding is that the libssh issue arises due to commingling of authentication state for server-side and client-side purposes. In Bitvise software, authentication state is managed in separate client-side and server-side components. The server-side authentication component is not affected by this issue and will ignore any SSH_MSG_USERAUTH_SUCCESS message sent by the client.
Changes in Bitvise SSH Server 8.19: [ 18 November 2018 ]
In previous 8.xx versions, FTPS connections would fail incorrectly as if password authentication was globally disabled, even when it was not. Fixed.
In previous 8.xx versions, the automatic IP blocking feature could sometimes block an IP address prematurely. Fixed.
The BssCfg help paging can now be exited.
Changes in Bitvise SSH Server 8.18: [ 7 November 2018 ]
With versions 8.xx, the SSH Server implements major improvements to memory concurrency which allow it to more efficiently handle large numbers of simultaneous connections. This is incompatible with Application Verifier - a Windows quality assurance component used for debugging. The SSH Server will now disable some memory optimizations if it detects it's running under the Application Verifier, so it can run on systems where this is (potentially accidentally) enabled.
In previous 8.xx versions, if the system clock was moved back after a check for updates (in UTC, not time zone specific), an automatic check would be repeated with high frequency. This could consume 80 kbps in bandwidth until the clock caught up. Fixed.
In file transfer, the SSH Server supports atomic and non-atomic rename/move. Non-atomic move works as a copy + delete and is used when files are moved across SSH Server's virtual filesystem mount points, or across Windows filesystems. Non-atomic move is implemented in two ways, one way using Windows (for moves within the same SSH Server mount point) and another way in the SSH Server itself (for moves across mount points). The type of move used across SSH Server mount points is now more consistent with non-atomic move performed by Windows. The destination file size is now set when starting the copy, and the destination file is now locked for reading and writing until the copy is complete.
Changes in Bitvise SSH Server 8.17: [ 3 November 2018 ]
Fixed an issue in previous 8.xx versions where an SSH Server thread could hang and prevent the server from accepting further connections.
Fixed an issue in previous 8.xx versions where the terminal subsystem did not properly handle console input for applications which rely on the Windows ReadFile function to receive interactive input.
Improved SFTP rename compatibility with OpenSSH by allowing the extended request email@example.com to perform non-atomic renames.
Changes in Bitvise SSH Server 8.16: [ 29 October 2018 ]
In version 8.15, the SSH Server Control Panel had an issue where the Sessions tab did not show IP addresses for port forwarding channels (tunneled connections). Fixed.
Changes in Bitvise SSH Server 8.15: [ 25 October 2018 ]
The SSH Server can now accept incoming file transfer connections using FTPS. This is the FTP protocol over TLS (SSL). This is in addition to SFTP and SCP, which are the file transfer protocols associated with SSH, which the SSH Server has always supported.
Only authenticated and encrypted FTP connections over TLS (SSL) are supported. To work with Bitvise SSH Server, an FTPS client must support explicit TLS (using the AUTH TLS command), must use FTP passive mode, and must use TLS resume functionality for data connections. The SSH Server receives FTP data connections at the same port as control connections.
Unlike the SSH protocol, where our own Bitvise implementation is used, the SSH Server uses the Windows implementation of TLS (Schannel). Therefore, available TLS versions and configurations depend on the version of Windows on which the SSH Server is used. All versions of Windows that are in support by Microsoft will work. However, we recommend a recent Windows version.
Connections made using FTPS can log into the same Windows and virtual accounts as SFTP and SCP connections, and can interact with the same virtual filesystem. However, FTPS connections are limited to password authentication.
The SSH Server now supports automatic updates. The administrator can configure the SSH Server to automatically apply all updates; only recommended updates; only strongly recommended updates; to apply updates only manually; or to never check for updates.
The SSH Server will not automatically update to a new version if the new version would require an upgrade access extension for the activation code that's currently applied.
The SSH Server's terminal subsystem now fully supports the new Windows 10 console. ANSI escape sequences and other new console behaviors are supported. Processes such as bash under the WSL (Windows Subsystem for Linux) are now supported.
Note: In current Windows versions, WSL does not work for multiple users. It can be used via the SSH Server in a single-account setup, but for use on a production server with multiple accounts, we would at this time still recommend Cygwin or similar.
Two-factor authentication using time-based one-time passwords is now supported. The SSH Server implements RFC 6238, which is supported by a number of authenticator apps including Microsoft Authenticator, Google Authenticator, LastPass, Authy, and FreeOTP. The SSH Server allows configuring, individually for each account, a secret key which can be shared with the user either textually or as a two-dimensional code image. Once configured, the user's authenticator can generate a one-time password specific to the user, which the user's SSH client will prompt for, and which the user can use to log in. The SSH Server can be configured to require this one-time password for a user or a group of users in addition to authentication using a password or public key.
Bitvise SSH Client and SSH Server now implement automatic host key rotation. The SSH Client will synchronize keys from the SSH Server and any other servers that support the OpenSSH mechanism "hostkey update and rotation". The SSH Server will announce to clients all configured host keys, including those not employed, to facilitate host key rotation. The SSH Client will automatically trust new keys announced by a trusted server and remove any keys the server has removed, as long as they were added automatically.
Most lists in SSH Server settings can now be exported and imported in CSV format.
The graphical aspects of the SSH Server now support high resolutions and will display crisp text on high-DPI displays such as retina or 4K. The SSH Server now comes with new, higher resolution icons.
Instance names for new installations are now validated more strictly to avoid use of names that could lead to issues.
SSH Server Control Panel:
An option is now available to copy all fingerprints to clipboard, making it easier to share host key information with clients.
The Activity tab, as well as textual log files, now displays the country (if available) of incoming connections. The SSH Server uses the MaxMind GeoLite2 Country database (under license). The country database comes with the SSH Server installation and is not automatically updated, other than by updating the SSH Server itself.
In many domain environments, the domain logon names used by the SSH Server (in format DOMAIN\username) are generated and hard to read. The SSH Server Control Panel will now display User Principal Names (UPNs) on the Activity tab and in Statistics. Textual log files now also record UPNs in addition to domain logon names.
The Log Folder Viewer now supports an option to Force log rollover without having to stop and restart the SSH Server.
The Manage blocked IPs interface now supports selecting multiple IP addresses to permanently block.
The SSH Server will now keep track of whether any warnings or errors have been logged. If there are errors or warnings, the SSH Server Control Panel will now alert the administrator by displaying a yellow notification.
On the Sessions tab, it is now possible to disable real-time session monitoring to reduce load on busy servers.
Additive settings import now allows the administrator to select which aspects of settings to import. The administrator can review the final settings and choose whether to save them or to cancel the import.
It is now possible to configure IP address rules based on country instead of manually entered address ranges. The SSH Server uses the MaxMind GeoLite2 Country database (under license). The country database comes with the SSH Server installation and is not automatically updated, other than by updating the SSH Server itself.
An administrator can now force a virtual account to change password during their next logon.
The virtual account password policy can now be configured to prevent reuse of the user's existing password.
All IP address rules that previously used a subnet mask and significant bits are now configured as more readable IP address ranges.
In settings for a virtual filesystem mount point, full filesystem access - allowing access to all drives, limited only by Windows filesystem permissions - is now expressed with a more obvious, explicit setting instead of an empty Real root path.
Easy settings, and settings for delegated administrators, now support a Blind drop virtual filesystem layout. This maps to an Advanced settings mount point configuration appropriate for users that should be allowed only to upload, but not view or modify existing files.
The properties and methods available under $cfg - the root BssCfgManip object - have been substantially cleaned up and rationalized. Keypairs are now available under $cfg.keypairs, certificates under $cfg.certificates, activation state under $cfg.actState, information about installed instances under $cfg.instances, and so on.
Commonly called prologue and epilogue methods are now also rationalized. For example, $cfg.LockServerSettings is now $cfg.settings.Lock, while $cfg.SaveServerSettings is now $cfg.settings.Save.
The $cfg.SetSite method is now more appropriately called $cfg.SetInstance.
All list interfaces that previously had two forms, listNameEx and listName, have now been consolidated as listName and listName.entries.
To de-clutter the $cfg namespace, enumeration values are now under $cfg.enums.
The settings layout remains substantially the same, however some settings have moved. For example, IP blocking settings were previously under $cfg.settings.session and are now under $cfg.settings.ipBlock.
The SSH Server now supports the PROXY protocol for use with non-transparent load balancers. The PROXY protocol can be enabled in Advanced settings for individual port and interface bindings. If enabled, the SSH Server will require incoming connections on that binding to be prefixed with a PROXY protocol header which will be trusted to contain the IP address of the actual client.
In Advanced settings, under Logging, it is now possible to configure a list of whitelisted monitor IP addresses. Connections coming from these addresses will not be logged unless they exhibit SSH or FTPS protocol activity. This helps avoid filling up logs with trivial connections that can come from load balancers or health monitors several times per minute.
Greatly improved shutdown performance when the server is handling many concurrent sessions.
Bitvise SSH Server, SSH Client and FlowSsh once again support non-standard DSA keys larger than 1024 bits. We do not recommend using these keys, and new keys of this type cannot be generated. Also, these keys cannot be used when FIPS mode cryptography is enabled in Windows. Re-adding support for these keys is intended to resolve an obstacle that may still be preventing some users of 6.xx versions from upgrading.
When using Windows cryptography, Bitvise SSH Server, SSH Client and FlowSsh now implement a backup strategy for DH and ECDH key exchange. Windows implements key exchange, but it does not expose the agreed value in a form suitable for SSH. Bitvise software must retrieve the value by carefully traversing undocumented Windows structures. In versions 7.xx, this required our software to be upgraded to continue working after the Windows 10 1803 update. Our software will now log a warning and fall back to Crypto++ if it cannot perform key exchange because Windows internal structures have changed. However: if FIPS mode is enabled in Windows, this backup strategy is not used, and the software must be updated.
When importing keys, such as from files, the stage at which an import failed is now described in more detail.
Bitvise SSH Server and Client now support the elevation extension. In previous versions, if a Windows account with administrative rights connected to the SSH Server, the server would always elevate the session if possible. Otherwise, the user would not be able to get an elevated session because there was no way to convey the user's preference. With the elevation extension, the user can request a non-administrative security context by requesting no elevation (elevation is still applied by default). In command line clients including stermc, sexec and sftpc, this is controlled using the switch -elevation=n.
Bitvise SSH Server and Client now support the no-flow-control extension. This disables SSH flow control for clients that only support opening one channel. No flow control is now preferred by sftpc, stermc, sexec and spksc, which only need to open one channel in the SSH session.
Bitvise SSH Server and Client now support the delay-compression extension. Delayed compression reduces attack surface for unauthenticated clients by delaying availability of compression until after a user is authenticated. The delay-compression extension is an improvement over previously supported alternatives: the firstname.lastname@example.org method contains a by-design race condition, while the approach of invoking a second key exchange doubles the overhead of establishing an SSH session.
If the Omit server version setting was enabled, then in previous SSH Server versions, the server would send a trailing space at the end of its version string. Some versions of some clients incorrectly trimmed this space, which caused the session to abort with a key exchange error. This trailing space will now no longer be sent.
The SSH Server now supports global settings to completely disable password authentication; or to disable it for all Windows accounts, or for all virtual accounts.
If the SSH Server is configured in a way such that no Windows accounts could possibly log in, it will no longer perform any Windows account lookups during authentication.
The handling of public key authentication has been reorganized to reduce attack surface. For example, the SSH Server will halt public key processing early if it detects that the public key being used does not even exist in its configuration.
Bitvise SSH Server and Client now support the ext-auth-info extension. This allows the server to respond to user authentication failures with more detailed information in situations where this is safe. For example, if the client attempts to perform a password change but the new password does not meet complexity requirements, the server can communicate this instead of making the user guess.
The SSH Server now supports password authentication over the keyboard-interactive method, in addition to the standard password method. This accommodates some custom clients which may only support password authentication over keyboard-interactive.
The SSH Server now supports PuTTY and OpenSSH agent forwarding. In this situation, an SSH client A, which has access to an authentication agent, can connect to the SSH Server and make the agent available in the SSH session. Within the session, the user can now run client B, located on the server, which will be able to use public keys from the authentication agent on client A. The clients can be Bitvise SSH Client or any other client that supports PuTTY or OpenSSH agent forwarding. However, in the role of client B, Bitvise SSH Client and Cygwin OpenSSH will work; but the OpenSSH client included in Windows 10 will not work because it cannot communicate with an authentication agent outside of the Windows Subsystem for Linux.
The SSH Server will now apply an IP blocking penalty to sessions which make a large number of authentication attempts of a kind that would not otherwise be penalized, unless there are too many.
Terminal and exec requests:
An obstacle for users trying to configure a bash shell for rsync has been that the directory containing the bash and rsync executables may not be present by default in the PATH environment variable. When using the bash shell access type, the SSH Server now offers the option to add the bash directory to PATH.
If the exec request prefix configured for a user begins with cmd /c, and the user's client sends an exec request that also begins with cmd /c, the extra cmd /c prefix is now stripped. This results in more intuitive behavior for commands like cmd /c cd SomeDir && command. Before, the effects of cd would be undone by the time command was run because the cd would be executed by the inner cmd, and command by the outer.
Custom named subsystems are now supported and available by default to accounts with Shell access type set to Command Prompt, PowerShell or bash. A new powershell subsystem is defined by default, which supports PowerShell remoting over SSH if PowerShell 6 is installed on the system.
Execution of an On-upload command is now delayed for some time after the client closes the respective file. This allows a client to complete any follow-up actions, such as a file rename, before the On-upload command is executed. If the client renames the file, the On-upload command is now run with the final filename.
bvRun now supports a -pid command line option which will cause it to return the PID of the started process as an exit code.
Windows XP: All versions of our software that we recommend using are built using Visual Studio 2015. The C++ run-time library used by this Visual Studio version has a known issue where 1-2 kB of memory are leaked each time a new thread is created. This issue does not occur on later Windows versions; it does not occur e.g. on Windows Server 2003. Microsoft has stated they do not intend to fix this issue. Bitvise's view is that the impacts on our SSH Client and FlowSsh are manageable; whereas our SSH Server is rarely used on Windows XP. We therefore do not plan to work around this; but we warn that this can be a potential denial of service vector on Windows XP.