For issues that might arise using the latest SSH Client versions, see Known issues.
Security Notification: [ 27 October 2019 ]
Authors of the Minerva attack have identified a small but significant timing information leak in the Crypto++ implementation of ECDSA over prime field curves. This attack may allow discovery of a private key through repeated observation of signature timing. If the leak can be utilized, an attacker could compromise a server host key or a client authentication key using a practical number of connections across a network.
The following is the impact on Bitvise SSH Server, SSH Client and FlowSsh versions before 8.36:
On all recent Windows versions (Vista and higher), there is no effect on users of Bitvise software versions 7.xx and 8.xx who use private keys of algorithms RSA, Ed25519, or ECDSA over the NIST curves nistp256, nistp384 or nistp521. On all recent versions of Windows, and using recent Bitvise software versions, these algorithms use Windows cryptography, which is unaffected by Minerva. In the case of Ed25519, we similarly use a non-Crypto++ implementation, which is unaffected.
On all versions of Windows, using all versions of Bitvise software, the Minerva issue may apply to users who generated, and are using, host keys or client keys of type ECDSA/secp256k1. Bitvise software versions 8.35 and earlier use Crypto++ to implement this algorithm on all platforms. We encourage such users to update to our latest software versions.
On Windows XP and Windows Server 2003, regardless of Bitvise software version; and for Bitvise software versions 5.xx and 6.xx, regardless of Windows version; the Minerva issue may apply to users of ECDSA private keys of any type. We encourage such users to update to our latest software versions, and/or to update to newer versions of Windows.
With Bitvise SSH Server, SSH Client and FlowSsh 8.36, we are releasing the following mitigations:
On all recent Windows versions (Vista and higher), where we previously used Crypto++ to support ECDSA/secp256k1, we are switching to alternatives. If the version of Windows is recent enough (for example, Windows 10, Windows Server 2016 and 2019), our default cryptographic provider (CiWinCng) now uses Windows cryptography to support ECDSA/secp256k1 as well as ECDH/secp256k1. Where Windows does not support secp256k1 (for example, Windows Vista to 8.1 and Windows Server 2008 to 2012 R2), we now support it using OpenSSL.
On Windows XP and Windows Server 2003, we face the issue that maintained cryptographic libraries that continue to support these platforms are hard to switch to and harder to find, while the number of users is small and diminishing. In current versions, we continue to rely on Crypto++ on these platforms, but implement mitigations to make it harder or impossible to observe signature timing across the network.
On all versions of Windows, we continue to use Crypto++ to support non-standard DSA keys. These are DSA keys as used in SSH of size other than 1024 bits. Since versions 7.xx, we have discouraged the use of DSA keys of any size. Also, DSA is not within scope of the Minerva research, so the current attack does not apply directly. Nevertheless, because we use Crypto++ to support non-standard DSA keys on all platforms, we now activate mitigations for these keys to make it harder or impossible to observe signature timing remotely.
Changes in Bitvise SSH Client 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.
When using single-click Remote Desktop forwarding, the SSH Client now runs mstsc.exe using its full system path. Previously, if the SSH Client was run by double-clicking a profile, and there was a copy of mstsc.exe or an impostor executable in the same directory, the potentially unintended executable would be run.
The SSH Client can now import OpenSSH private keys encrypted using CTR mode algorithms.
Changes in Bitvise SSH Client 8.35: [ 20 August 2019 ]
With version 8.17, the profile settings RDP > Authentication > Password and Store encrypted password in profile were changed to take effect the same way as similar settings under Login > Authentication, but their UI layout was not updated. Fixed.
Changes in Bitvise SSH Client 8.34: [ 17 June 2019 ]
When creating a new profile or when using the SSH Client's command line clients (sftpc, sexec, stermc, stnlc, spksc) without the -profile=... parameter, the SSH Client will now by default prefer Curve25519 and ECDH key exchange over traditional Diffie Hellman. Classic DH is significantly slower and more computationally expensive, while there continues to be no known reason to de-prefer Elliptic Curve cryptography. Existing profiles are unaffected and will keep their algorithm preference order.
In Windows 10 version 1903, when using the Open action or when double-clicking a file whose extension has no file association, Windows may no longer offer to select a program with which to open the file, but may instead fail the action. The SSH Client will now automatically use Open with if the Open action fails in this manner.
The SFTP GUI now supports mouse button 4 to trigger the Back action and mouse button 5 to trigger Forward, in a manner consistent with common browsers.
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").
Polished a few issues in BvSshUpdate, the SSH Client's command-line version update utility.
Changes in Bitvise SSH Client 8.32: [ 6 May 2019 ]
sftpc: Fixed an issue which prevented the -cmdFile=... parameter from working if the file contained only a single line without a line terminator.
Fixed an issue in how command line clients (sftpc, sexec, stermc, stnlc, spksc) were initializing the default key exchange algorithm list. This caused the following issues:
If the -gkx parameter (or its -sspi alias) was passed to enable GSSAPI (Kerberos) key exchange, the requisite GSS key exchange algorithms had to be additionally enabled via -profile=..., -kexAlgs=... or -kexMod=.... The -gkx and -sspi parameters will now again correctly enable GSS key exchange algorithms as intended.
Outdated key exchange algorithms, such as diffie-hellman-group1-sha1, were enabled by default when they should not be. With this change, backward compatibility may be broken for users connecting to servers that require outdated key exchange algorithms. If you are connecting to such a server using one of our command line clients, you will need to enable the outdated algorithm using either -profile=..., specifying a profile where the algorithm is enabled; or via -kexMod=..., as in the following examples:
sftpc -profile=C:\Path\Profile.tlp ... sftpc user@host -kexMod=diffie-hellman-group1-sha1 ...
Changes in Bitvise SSH Client 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 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.
Changes in Bitvise SSH Client 8.29: [ 23 March 2019 ]
Fixed an issue in previous 8.xx versions where, if the SSH Client had not been updated to a new version for longer than 42 days, trying to apply an update would fail due to a Windows registry Access denied error.
Users experiencing this problem can use one of the following workarounds:
Run the SSH Client elevated (right click > Run as administrator) before attempting to update.
Download the installer for the latest version from the SSH Client download page and run it manually.
Changes in Bitvise SSH Client 8.27: [ 4 March 2019 ]
In the graphical SFTP interface, the new directory auto-completion feature could cause the SSH Client to crash when entering a remote path. Fixed.
When using the GSSAPI key exchange method gssapi-keyex, the SSH Client could incorrectly log a warning about failing to save the server's host key. Fixed.
Changes in Bitvise SSH Client 8.26: [ 22 February 2019 ]
Fixed issue introduced in version 8.25 where the recent locations drop-down in the graphical SFTP interface would no longer function correctly.
Fixed issue introduced in version 8.24 where the SSH Server Remote Control Panel could no longer be launched when connected to SSH Server versions 7.xx and earlier.
Changes in Bitvise SSH Client 8.25: [ 18 February 2019 ]
- Regular files are no longer shown for auto completion of directory paths.
- Tab and Shift+Tab now behave consistently with auto-completion in other apps.
- File transfer events no longer cancel the auto-completion drop-down.
To improve UI responsiveness, directory listings are now performed in a background thread.
Changes in Bitvise SSH Client 8.24: [ 7 February 2019 ]
We have identified additional situations where loading a profile fails due to the ZoneId check which is new in 8.xx versions. The SSH Client will now ignore ZoneId-related errors returned by Windows offline files (ERROR_ONLY_IF_CONNECTED) and the Dokany virtual filesystem driver (ERROR_INVALID_PARAMETER).
The SSH Client now implements a Notes tab. This allows users to enter comments which will be saved with the profile and can be viewed later.
Version 8.22 introduced behavior to restore the main SSH Client window so it's not forgotten in the system notification area when a dependent window is closed. This version improves a couple of situations so that the main SSH Client window actually restores instead of flashing in the task bar.
Via a user report, we identified a type of Dropbear server which does not respond to SSH_MSG_GLOBAL_REQUEST. This may work properly in other Dropbear servers, but since the affected server cannot be distinguished from others by its SSH version string, the SSH Client will no longer send global requests to Dropbear servers.
Fixed an issue which caused initial terminal output, such as a welcome message received at the very start of the terminal session, to be cut off.
Automatic path completion is now supported for both local and remote path browsing.
The Filter feature now displays an X that can be clicked to cancel the filter instead of having to clear it via keyboard.
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.
When an update was launched at the same time as the default registry-based profile was opened with pending changes, the SSH Client would incorrectly ask whether to save the profile to a file. Fixed.
The SSH Server Remote Control Panel included with the SSH Client for SSH Server versions 8.15 and higher will now properly show available updates for the SSH Server.
Changes in Bitvise SSH Client 8.23: [ 27 December 2018 ]
Fixed an issue in previous 8.xx versions which would prevent Bitvise SSH Client and FlowSsh from connecting to a server that supports host key synchronization and employs a key type the client does not support. This affected connections from Windows XP and Windows Server 2003, where our cryptographic provider does not support Ed25519; and use under FIPS mode, where Ed25519 and ECDSA/secp256k1 are not supported.
Changes in Bitvise SSH Client 8.22: [ 21 December 2018 ]
A proportion of users are closing the main SSH Client window when connected so that it minimizes into the Windows notification area (the system tray). Users forget about that SSH Client instance and launch new instances for new sessions. Forgotten sessions stay online indefinitely and terminal window settings do not appear to save because the SSH Client is never closed.
To fix this, the SSH Client will now restore its main window if it's still hidden in the notification area after closing a related window such as terminal or SFTP. This behavior can be configured with a new setting found under Closing and minimization.
Since the changes related to password authentication in 8.17, the graphical client's command line parameter -password=... did not take effect if the SSH Client profile was configured to use password authentication but the checkbox Store encrypted password in profile was disabled. Fixed.
sftpc: Updated help text for get and put commands to clarify how the -r and -o parameters control when hash-based synchronization, heuristic resume or overwrite is used.
Changes in Bitvise SSH Client 8.21: [ 17 December 2018 ]
The graphical SSH Client's terminal window for xterm (and other non-bvterm terminals) implements a Select mode intended to behave like the Windows console's QuickEdit mode. A difference was catching users off-guard: canceling a mouse text selection with an arbitrary key press would not send the key to the server. For users who began a selection without noticing, it appeared as though the terminal window was eating a key press for no reason. Consistently with the Windows console, the SSH Client will now send key presses that cancel a selection to the server.
In previous versions, if the graphical SSH Client failed to load a profile specified on the command line, it would fall back to the last used profile and still act on the -loginOnStartup parameter if also provided. This would result in bewildering behavior. If a profile specified on the command line fails to load, the SSH Client now loads the default profile (stored in the Windows registry) and ignores -loginOnStartup.
In previous 8.xx versions, loading an SSH Client profile from a network share would fail when the ZoneId alternative data stream could not be opened. If the ZoneId ADS cannot be opened, a profile will now be loaded as if its origin is the local computer.
We have identified niche situations where one-click Remote Desktop forwarding might fail to start when an SSH Client DLL is not found. To resolve this, this version makes changes to how the Remote Desktop client is started.
There exist SSH clients which, in violation of RFC 4254, disconnect if a server sends a global request after successful authentication. A server might send a global request for purposes such as host key synchronization or disconnect detection. If the server supports RFC 8308, then to indicate it supports global requests, the SSH Client will include the extension global-requests-ok in its SSH_MSG_EXT_INFO.
In previous 8.xx versions, the SSH Client would not import RSA private and public keys larger than 8192 bits. This limit is once again 16384 bits.
The SSH Client 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.
Changes in Bitvise SSH Client 8.19: [ 18 November 2018 ]
In previous 8.xx versions, the icons for the New terminal console, New SFTP window and New Remote Desktop actions were too similar. The SSH Client now sports updated icons that are easier to distinguish.
In previous 8.xx versions, when the SSH Client reconnected after losing a connection, it failed to continue ongoing transfers. Fixed.
SFTP interface: When connecting to SFTP servers that support synchronization using the SFTP v6 extensions check-file-name, check-file-handle and check-file-blocks, the resume and overwrite modes are now more clearly overridden by synchronize in the SFTP user interface.
sftpc: When connecting to SFTP servers that support synchronization, the -r and -o options for get and put commands now both act as aliases for synchronize. Previously, only -o acted as an alias for synchronize, and -r was unavailable.
Changes in Bitvise SSH Client 8.18: [ 7 November 2018 ]
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 while the graphical SSH Client was running until the clock caught up. Fixed.
In previous 8.xx versions, an automatic check for updates would be performed if the graphical SSH Client was run with -noRegistry. An automatic check is no longer performed in this situation, but can be performed manually.
Changes in Bitvise SSH Client 8.17: [ 3 November 2018 ]
In version 8.15, loading a profile which was last saved by a previous version would cause the SSH Client to send an invalid elevation extension value to the server. This caused SSH Server versions 8.xx to disconnect. The SSH Client will now send a valid elevation extension value in this circumstance.
The Remote Desktop forwarding feature Use SSH login credentials would previously work only if the password authentication method was used for client authentication, but it did not work for password authentication over keyboard-interactive. This will now also work with password over keyboard-interactive.
In the graphical SSH Client, on the Login tab, setting Initial method to password could result in unintuitive behavior. Password change was not easily discoverable, and setting Initial method to password without entering a password caused the SSH Client to send an empty password at start of connection, incurring an authentication penalty.
This has been redesigned so that Initial method can be set to password without entering a password. In this case, a password dialog will dependably appear when connecting. As part of this change, it is no longer possible to enter a password on the Login tab without enabling Store encrypted password in profile.
In version 8.15, in command line clients, the -keypairFile parameter did not override a public key configured as an initial authentication method in a profile specified using -profile. The -keypairFile parameter will now once again override any public key configured in the profile.
Changes in Bitvise SSH Client 8.15: [ 25 October 2018 ]
The SSH Client now supports automatic updates. An administrator can configure the SSH Client to automatically apply all updates; only recommended updates; only strongly recommended updates; to apply updates only manually; or to never check for updates.
Currently, the SSH Client does not install an update service. It needs to be started from time to time by an administrative user in order to apply updates.
The graphical SSH Client and sftpc now support recursive directory mirroring. A directory and all of its subdirectories and files can be synchronized either in the upload or download direction. The SSH Client can synchronize updated files and detect and automatically remove files and directories from the target location that are not present in the source.
The graphical SSH Client and sftpc can now display hashes (cryptographic digests) of local and remote files if the server supports the SFTP v6 check-file extension.
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.
The SSH Client now supports high resolutions and will display crisp text on high-DPI displays such as retina or 4K. The SSH Client now comes with new, higher resolution icons.
SSH Client profiles downloaded from the internet will now be considered unsafe. If a profile is marked by a browser using which it was downloaded as originating from an unsafe zone, the SSH Client will now load safe parts only. When loading a profile interactively in the graphical SSH Client, a prompt will be displayed, allowing the user to mark the profile as safe. If the user confirms, the profile can be fully loaded.
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. The graphical SSH Client does not support no-flow-control because it requires multiple channels.
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.
Bitvise SSH Server and Client now support the delay-compression extension. Delayed compression reduces attack surface for unauthenticated clients by delaying availability of compression until after a user is authenticated. The delay-compression extension is an improvement over previously supported alternatives: the email@example.com method contains a by-design race condition, while the approach of invoking a second key exchange doubles the overhead of establishing an SSH session.
Settings for the graphical xterm/vt100 terminal console window (totermw) are now stored in the SSH Client profile instead of in the Windows registry.
In the graphical SFTP interface, the Open and Edit commands will now be much more responsive if a transfer is already in progress. The in-progress transfer will be paused and the file associated with the Open or Edit command will be transferred as a priority.
Both the graphical SFTP interface and sftpc can now work with local paths longer than 259 characters, as well as unsafe paths not permitted by Windows in some contexts (e.g. "C:\Com1\file").
A new file transfer mode, TextLf, is now supported. This works the same as AutoLf, but forces newline conversions without relying on file type detection.
The SSH Client now displays the country (if available) of remote IP addresses. The SSH Client uses the MaxMind GeoLite2 Country database (under license). The country database comes with the SSH Client installation and is not automatically updated, other than by updating the SSH Client itself.
Command line clients:
It is now easier to connect to SSH servers that accept connections on non-default ports. If no port is specified on the command line, but the SSH Client knows a host key for the destination server, the SSH Client will automatically connect to the port associated with the server in the host key database. If there are multiple port associations, however, the port still needs to be specified, unless one of them is 22.
It is now easier to enable and disable individual algorithms with our command-line clients. Previously, to use non-default algorithms, either a -profile needed to be used, or a complete algorithm list had to be supplied using -hkey, -kex, -encr or -mac. It is now still possible to pass a whole list using the same parameters, or using their new aliases -hkeyAlgs, -kexAlgs, -encrAlgs or -macAlgs. In addition, it is possible to modify the default algorithm lists using -hkeyMod, -kexMod, -encrMod or -macMod. When using the "Mod" versions, provide a comma-separated list of algorithm names with optional prefixes. Names prefixed with "+" are added to the front of the list; names without a prefix are appended to the end; and names prefixed with "!" are removed. Example: -encrMod=+aes256-gcm,!3des-ctr
The log utility now supports filesystem paths in Unicode.
To use an OpenSSH authentication agent, you must use a third-party distribution of OpenSSH, for example the version that comes with Cygwin. The version of the OpenSSH agent that comes with Windows runs under the Windows Subsystem for Linux and uses Unix sockets in a way that's currently inaccessible to native Windows applications.
LastPass for Applications achieves some of its functions by injecting a DLL with foreign code into other applications. As of February 2018, the DLL injected by LastPass has been observed to cause a crash in Bitvise SSH Client when connecting to a server.
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.