Changes in Bitvise SSH Client 9.59: [ 18 February 2026 ]$$$$$$Installation:$$$The SSH Client installer still requires administrative rights for installation; but can now be run without administrative rights for help with command-line parameters. Users who are preparing the SSH Client for portable use no longer need administrative rights to extract files in the installer.$$$$$$Authentication:$$$$$$If the user runs the PuTTY authentication agent using pageant --unix; and configures the SSH_AUTH_SOCK environment variable with the path to the Unix socket file; the SSH Client now detects this as an unsupported mechanism; and still tries connecting to the Windows OpenSSH agent. The SSH Client already connects to the PuTTY agent using the PuTTY mechanism; so it doesnt need a second connection to the same agent.$$$$$$In previous versions; this configuration would cause the SSH Client to display an error message; and it would not further try to connect to the Windows OpenSSH agent. The connection to the PuTTY agent would still work using the PuTTY mechanism.$$$$$$SFTP GUI:$$$$$$Switching between light mode and dark mode no longer requires the SFTP window to be closed and reopened in order to use the appropriate icons.

Changes in Bitvise SSH Client 9.55: [ 1 January 2026 ]$$$$$$Graphical SFTP:$$$$$$In previous 9.5x versions; when using dark mode; the SFTP window would hang if file icons were not yet available in the Windows Explorer icon cache.$$$$$$For the technically inclined: this is an interesting interaction between the Windows function SHGetFileInfoW; which is used to retrieve file icons; and the Windows List View control; if its set to use a transparent background: LVS_EX_TRANSPARENTBKGND.$$$$$$If a file icon is not yet cached by Windows; SHGetFileInfoW starts a nested message loop. This is so that the application can remain responsive during a potential extended adventure in search of the icon. In the case of the SSH Client; this nested message loop occurred in the middle of a List View paint cycle; because the List View requested an icon; and this is what caused the SSH Client to call SHGetFileInfoW. During the nested message loop; a new paint cycle is started; which is by design - maintaining UI responsiveness. Although List View is already in a paint cycle; the reentrant paint normally works; as long as the application has not set a transparent background. If it has; then the List View does not support reentrant paint with transparency; aborts the paint; and schedules a new paint. The new paint is scheduled in the nested message loop; which continues indefinitely until its drained. This causes an infinite cycle of attempted and aborted paints between List View and SHGetFileInfoW; and SHGetFileInfoW never returns.$$$$$$Microsoft appears to be aware of such issues: current documentation warns that calling SHGetFileInfoW on a UI thread may cause the UI to stop responding. The SSH Client got away with this for 20 years. With version 9.55; we are replacing this with a cache component which calls SHGetFileInfoW on a background thread. As a tradeoff; this causes uncached icons to appear slightly after the files are shown.$$$$$$Suggestion to Microsoft: Since current documentation already recommends applications to avoid calling SHGetFileInfoW on a UI thread; remove the nested message loop functionality from SHGetFileInfoW. It seems to be an unexpected feature which attempts to solve one problem by introducing other problems. For example - besides infinite paint cycles; stack overflow seems possible if SHGetFileInfoW keeps being called from the nested message loop again.

Changes in Bitvise SSH Client 9.55: [ 1 January 2026 ]$$$$$$Graphical SFTP:$$$$$$In previous 9.5x versions; when using dark mode; the SFTP window would hang if file icons were not yet available in the Windows Explorer icon cache.$$$$$$For the technically inclined: this is an interesting interaction between the Windows function SHGetFileInfoW; which is used to retrieve file icons; and the Windows List View control; if its set to use a transparent background: LVS_EX_TRANSPARENTBKGND.$$$$$$If a file icon is not yet cached by Windows; SHGetFileInfoW starts a nested message loop. This is so that the application can remain responsive during a potential extended adventure in search of the icon. In the case of the SSH Client; this nested message loop occurred in the middle of a List View paint cycle; because the List View requested an icon; and this is what caused the SSH Client to call SHGetFileInfoW. During the nested message loop; a new paint cycle is started; which is by design - maintaining UI responsiveness. Although List View is already in a paint cycle; the reentrant paint normally works; as long as the application has not set a transparent background. If it has; then the List View does not support reentrant paint with transparency; aborts the paint; and schedules a new paint. The new paint is scheduled in the nested message loop; which continues indefinitely until its drained. This causes an infinite cycle of attempted and aborted paints between List View and SHGetFileInfoW; and SHGetFileInfoW never returns.$$$$$$Microsoft appears to be aware of such issues: current documentation warns that calling SHGetFileInfoW on a UI thread may cause the UI to stop responding. The SSH Client got away with this for 20 years. With version 9.55; we are replacing this with a cache component which calls SHGetFileInfoW on a background thread. As a tradeoff; this causes uncached icons to appear slightly after the files are shown.$$$$$$Suggestion to Microsoft: Since current documentation already recommends applications to avoid calling SHGetFileInfoW on a UI thread; remove the nested message loop functionality from SHGetFileInfoW. It seems to be an unexpected feature which attempts to solve one problem by introducing other problems. For example - besides infinite paint cycles; stack overflow seems possible if SHGetFileInfoW keeps being called from the nested message loop again.

Changes in Bitvise SSH Client 9.54: [ 22 December 2025 ]$$$Graphical terminal:$$$When rendering multiple characters at a time; the SSH Client now specifies the width of each character. This avoids cumulative misalignment if Windows chooses to render text using a wider font; in particular when using bold style.

Changes in Bitvise SSH Client 9.46: [ 26 July 2025 ]$$$$$$SFTP:$$$In recent versions; text mode transfers would fail if resume was enabled. Text mode is incompatible with resume; but transfers would fail for new files that do not need resume. Fixed.$$$The transfer mode Text is renamed to Text Std. Updated help text related to Text Std and Auto Std.$$$

Changes in Bitvise SSH Client 9.46: [ 26 July 2025 ]$$$$$$SFTP:$$$In recent versions; text mode transfers would fail if resume was enabled. Text mode is incompatible with resume; but transfers would fail for new files that do not need resume. Fixed.$$$The transfer mode Text is renamed to Text Std. Updated help text related to Text Std and Auto Std.$$$

Changes in Bitvise SSH Client 9.45: [ 2 June 2025 ]$$$$$$General:$$$$$$When loading profiles; the SSH Client now strips whitespace at the start of most strings; including Unicode whitespace.$$$$$$The SSH Clients installation directory path hijack check can now be disabled by configuring the DWORD value DisableInstDirCheck; with value 1; under the Windows registry key HKLM\Software\WOW6432Node\Bitvise. This also disables the check in recent versions of Bitvise SSH Server.$$$$$$Proxy support:$$$$$$When configured to connect via an HTTP CONNECT proxy; the SSH Client now sends an HTTP/1.1 request; including a Host header. Previous versions sent an HTTP/1.0 request (no Host header).$$$$$$Graphical SFTP:$$$$$$Cut-and-paste in the Local files pane can now move local files across drives and filesystem volumes. Directories cannot be moved in this manner.$$$$$$The Filter feature in the Local files and Remote files panes now applies to both files and directories. Previously; it would filter only files.$$$$$$Fixed additional issues in reporting of final size and reused bytes when using synchronization.

Changes in Bitvise SSH Client 9.45: [ 2 June 2025 ]$$$$$$General:$$$$$$When loading profiles; the SSH Client now strips whitespace at the start of most strings; including Unicode whitespace.$$$$$$The SSH Clients installation directory path hijack check can now be disabled by configuring the DWORD value DisableInstDirCheck; with value 1; under the Windows registry key HKLM\Software\WOW6432Node\Bitvise. This also disables the check in recent versions of Bitvise SSH Server.$$$$$$Proxy support:$$$$$$When configured to connect via an HTTP CONNECT proxy; the SSH Client now sends an HTTP/1.1 request; including a Host header. Previous versions sent an HTTP/1.0 request (no Host header).$$$$$$Graphical SFTP:$$$$$$Cut-and-paste in the Local files pane can now move local files across drives and filesystem volumes. Directories cannot be moved in this manner.$$$$$$The Filter feature in the Local files and Remote files panes now applies to both files and directories. Previously; it would filter only files.$$$$$$Fixed additional issues in reporting of final size and reused bytes when using synchronization.

Changes in Bitvise SSH Client 9.44: [ 6 April 2025 ]$$$$$$Installation:$$$$$$When installing the FlowSshNet library component; the SSH Client installer now specifies the full path to msiexec in the Windows System32 directory. This is to avoid running any unintended executable also named msiexec which may have been placed in the same directory as the installer.$$$$$$On a system with multiple users; administrators should never run executables from a directory where a non-administrator user can write files outside of the administrators control.$$$$$$SFTP:$$$$$$In the sftpc command-line client; the remote directory listing commands dir and ls; and the local versions ldir and lls; now support parameters to group directories and files separately; sort by name; sort by time; or reverse sorting order.$$$$$$

Changes in Bitvise SSH Client 9.43: [ 16 March 2025 ]$$$$$$SSH cryptography:$$$$$$Starting with 9.43; the latest versions of Bitvise software no longer use OpenSSL:$$$$$$OpenSSL no longer supports versions 1.1.1. Our recent software versions used this to support a handful of algorithms not supported by Windows.$$$$$$There are new fixes only available in OpenSSL 3.x.$$$$$$OpenSSL 3.x promotes opaque interfaces and hides details. This is the opposite of our requirements.$$$$$$OpenSSL 3.x is even larger than 1.1.1; and dramatically increases linker bloat. Updating OpenSSL 1.1.1 to 3.4.1 increases the size of CiWinCng64.dll from 3.3 MB to 5.0 MB. Removing OpenSSL reduces the size to 1.4 MB. The difference; 3.6 MB; is a lot of complexity to support some marginal algorithms.$$$$$$This change does not affect most algorithms. We support most algorithms using Windows cryptography. Only the following is affected:$$$$$$chacha20-poly1305: We now support this algorithm using public domain ChaCha20 implementations from Goll & Gueron (on most CPUs with AVX2); Daniel J. Bernstein (on CPUs without AVX2); and Poly1305 from Andrew Moon (poly1305-donna).$$$$$$In new Bitvise software installations; chacha20-poly1305 is disabled by default; because it is the most susceptible to the Terrapin attack if the counterparty does not implement strict key exchange. This algorithm is secure if both parties support strict key exchange. In Bitvise software; strict key exchange is supported in versions 9.32 and newer.$$$$$$ECDSA and ECDH over the curve secp256k1: On Windows 10 and newer; and Windows Server 2016 and newer; we continue to support this curve using Windows cryptography. On these Windows versions; there is no change.$$$$$$On Windows Vista to 8.1; and Windows Server 2008 to 2012 R2; secp256k1 is now supported using Crypto++ 5.6. This implementation is not constant-time; so in this case; we enable signature timing mitigations. The timing mitigations favor security over performance: a signature is delayed to take e.g. 50 ms instead of 1 ms.$$$$$$In SSH; this prime field curve is rarely used. We support it for compatibility with previous versions. We originally added this curve because it is used in Bitcoin; so it is subject to intense scrutiny. However; users who want elliptic curve cryptography; but doubt the widely used NIST curves; have usually chosen Curve25519 and Ed25519.$$$$$$If FIPS 140-2 cryptography is enabled in Windows; there is no change. If FIPS mode is enabled; Bitvise software already restricts itself only to algorithms supported by Windows. In this case; chacha20-poly1305 is not available; and secp256k1 is available only on Windows versions 10 and newer; which support it.$$$$$$Bitvise software versions 9.xx remain compatible with Windows XP and Windows Server 2003. To support SSH cryptography on these platforms; our installers include DLL files CiCpFips32/64.dll and CryptoPP530Fips32/64.dll. These DLLs are not used on Windows Vista and newer; but were previously installed on all Windows versions. They are now no longer installed on Windows versions where they are not used.$$$$$$SFTP:$$$$$$When resuming or updating files using hash-based synchronization; progress was being reported incorrectly. When the destination file was larger than the source; the final file size was also displayed incorrectly. Fixed.$$$$$$Terminal:$$$$$$In previous versions; the SSH Clients xterm implementation would stop parsing unrecognized CSI escape sequences at the first unrecognized byte; and render the bytes which follow. The SSH Client now continues to parse unrecognized CSI sequences according to ECMA-48; and ignores them. This avoids unexpected characters in output when a server application sends sequences which the SSH Client does not support. For example; the fish shell sends such sequences associated with the Kitty Keyboard Protocol.

Changes in Bitvise SSH Client 9.42: [ 9 December 2024 ]$$$$$$FlowSshNet:$$$$$$In previous 9.xx versions; the FlowSshNet constructor Keypair.CreateFromData would block indefinitely if the application provided a passphrase-protected keypair; but the passphrase was incorrect. Fixed.$$$$$$

Changes in Bitvise SSH Client 9.41: [ 20 November 2024 ]$$$$$$Installation:$$$$$$Windows Server 2025 ships with Windows Terminal 1.18. This contains an issue where; if a console application enlarges the screen buffer height; Windows Terminal later crashes due to division by zero.$$$$$$In previous Bitvise software versions; the installer would enlarge the screen buffer height if it is small. If the installer is run with Windows Terminal as the console application; and Windows Terminal has not yet updated to a more recent version; this would cause a later installation step to fail with error code 0xC0000142. The issue does not occur if Windows Terminal has already updated.$$$$$$To improve compatibility with Windows Terminal; Bitvise installers no longer increase the screen buffer height if the console reports it as equal to the window height.$$$$$$Command-line clients:$$$$$$The command-line clients sftpc; stermc; sexec and spksc no longer enable the no-flow-control extension by default; unless it is enabled using an explicit parameter. The extension prevents opening additional SSH channels; which prevents the use of the exec command in sftpc; and agent forwarding in stermc.$$$$$$sftpc:$$$$$$sftpc now displays the default file transfer mode on startup. The default file transfer mode depends on the server and SFTP protocol version. It is either b (binary) or std (automatic text file detection; text files use SFTP v4+ text mode).$$$$$$sftpc now detects the Maverick SSHD server via the vendor-id extension; and sets the default file transfer mode for this server to binary instead of std. This SFTP server does not properly implement SFTP v4+ text mode; so the std file transfer mode causes file transfer errors.$$$$$$SFTP:$$$$$$For downloads; text file auto-detection should now work with servers such as Maverick SSHD; which do not support re-reading data that was already read.$$$$$$When errors occur while using SFTP v4+ text mode; the error description will now include a remark that the file was opened using SFTP v4+ text mode.$$$$$$If the server sends a vendor-id SFTP extension; the information is now displayed or logged as part of the SFTP version message.$$$$$$stermc:$$$$$$On Windows 10 versions up to 1909; the Windows function ScrollConsoleScreenBufferW can return errors even though it succeeds. stermc now ignores errors from this function on these Windows versions.

Changes in Bitvise SSH Client 9.39: [ 2 August 2024 ]$$$$$$General:$$$$$$When used with -noRegistry; the SSH Client would still create a disk-based lock file for update checking. The SSH Client now avoids creating this lock file when used with -noRegistry.$$$$$$SSH:$$$$$$A server which identifies itself as SSH-2.0-HOSTED~FTP~ SFTP claims to support SSH_MSG_EXT_INFO; but disconnects if the client sends it. The SSH Client now automatically disables sending of SSH_MSG_EXT_INFO to this server by default. This is controlled by the setting Send EXT_INFO on the SSH tab in the main SSH Client window; or using the command-line parameter -sendExtInfo.$$$$$$SFTP:$$$$$$The graphical SFTP interface now shows in its menus keyboard shortcuts which were already supported. Furthermore; the F3 shortcut for Edit was previously shown; but did not work. Fixed.$$$$$$Terminal:$$$$$$If a server-side program enables mouse tracking in the terminal window; the graphical SSH Clients terminal now supports overriding mouse tracking (for selection and copy to clipboard) using either Shift key. Previously; only Left Shift would override mouse tracking.

Changes in Bitvise SSH Client 9.38: [ 7 May 2024 ]$$$$$$Graphical interface:$$$$$$The graphical SSH Client now supports command-line parameters for Window behavior preferences. Users who are running the SSH Client in a portable manner; or using the -noRegistry parameter; and who relied on the previous default for Closing behavior; can now select that behavior using the parameter:$$$$$$BvSsh -wndClose=hideIfConn$$$$$$

Changes in Bitvise SSH Client 9.35: [ 12 April 2024 ]$$$$$$sftpc:$$$$$$Improved behavior of the -noBuf parameter for put and get commands.

Changes in Bitvise SSH Client 9.33: [ 20 December 2023 ]$$$$$$Security:$$$$$$Terrapin - CVE-2023-48795: Researchers have identified an issue where all SSH connections which use the encryption algorithm ChaCha20-Poly1305; or any integrity algorithm of type encrypt-then-MAC; are vulnerable to packet sequence manipulation by an active attacker; if the attacker can intercept the network path. This can be used to sabotage SSH extension negotiation. This affects extensions with security impact; such as server-sig-algs.$$$$$$Since the attacker can only remove packets sent before user authentication; this does not seem to fatally break the security of the SSH connection. However; it is a cryptographic weakness to address.$$$$$$Bitvise software versions 9.32 and newer support strict key exchange. This is a new SSH protocol feature which mitigates this attack. The SSH client and server must both implement strict key exchange for mitigation to be effective. Other SSH software authors are also releasing new versions to support this.$$$$$$If you must interoperate with SSH software which does not support strict key exchange; consider disabling the encryption algorithm ChaCha20-Poly1305; as well as integrity algorithms of type encrypt-then-MAC. These are the newer data integrity protection algorithms whose names contain -etm.$$$$$$Bitvise software versions 8.xx and older are not substantially affected because they do not implement algorithms where this issue is practically exploitable. Nevertheless; we suggest updating all SSH software to new versions that support strict key exchange.$$$$$$The encryption algorithms aes256-gcm and aes128-gcm are substantially immune from this attack. Users who are committed to older SSH software versions should consider using AES GCM. If this is not possible; the data integrity protection algorithms which are not named -etm are not entirely immune; but are also not believed to be practically exploitable. For compatibility with SSH software which does not support strict key exchange or AES GCM; an algorithm combination such as AES CTR with non-ETM data integrity protection may continue to be acceptable.$$$$$$Graphical client:$$$$$$Error and warning popups would not be shown if the main SSH Client window was visible when the message was logged; but lost focus immediately after. This would happen; for example; if there was an issue with terminal session logging; which occurs just before opening the terminal window.$$$$$$The SSH Client now shows popups if the main window loses focus immediately after errors or warnings were logged.$$$$$$SFTP:$$$$$$The SSH Client now prefers to open remote files using the flags SSH_FXF_BLOCK_WRITE and SSH_FXF_BLOCK_ADVISORY; instead of only SSH_FXF_BLOCK_WRITE. This allows the server to strip the block flag if it is not supported by a part of its filesystem.

Changes in Bitvise SSH Client 9.31: [ 24 September 2023]$$$$$$Command-line clients:$$$$$$Even when output was redirected; the command-line clients sftpc; sexec; stermc; stnlc and spksc would not run unless the process was associated with a console window. Fixed.$$$$$$User interface:$$$$$$Names and strings containing the & character were not properly displayed in lists. Fixed.$$$$$$File transfer:$$$$$$When using the Move to dialog in the SFTP window; the SSH Client could crash. Fixed.

Changes in Bitvise SSH Client 9.27: [ 14 February 2023 ]$$$$$$Cryptography:$$$$$$OpenSSL version updated to 1.1.1t. Bitvise software primarily uses Windows CNG for cryptography. We use OpenSSL for specific cryptographic algorithms not supported by Windows. Currently; these are chacha20-poly1305 and on older Windows versions; the elliptic curve secp256k1. Our software does not use OpenSSL features affected by recent OpenSSL security advisories.$$$$$$Terminal:$$$$$$The key combination Alt+Backspace would incorrectly open the terminal windows system menu. Fixed.