For issues that might arise using the latest SSH Client versions, see Known issues.
Security Notification: [ 18 May 2018 ]
We have been informed of, and have taken steps to address:
- A security issue in common functionality used by Bitvise software.
- An initialization issue in a compression library used by Bitvise software.
This issue consists of an invalid memory access. At this time, we believe this memory access is always invalid and cannot be used for remote code execution.
This issue has the following impact on Bitvise SSH Server and Client:
High severity: When an affected Bitvise SSH Server version is installed on a 32-bit version of Windows, a remote unauthenticated attacker can cause the SSH Server's main service to stop abruptly.
This high severity impact is not present on 64-bit versions of Windows. The following other impacts are present on all versions of Windows.
Lower severity: An authenticated user connected to Bitvise SSH Server who is permitted to use the SFTP subsystem can cause the SFTP subsystem to stop abruptly. This can have an effect on what actions are logged. For example, an error might be logged instead of the last actions taken by the user.
Lower severity: A server to which a user connects using Bitvise SSH Client can cause the SSH Client to stop abruptly. Due to the limited effects, this would not be an interesting attack in most usage scenarios.
Low severity: If a user or administrator imports a specially crafted file when using either the local Bitvise SSH Server Control Panel; the remote Bitvise SSH Server Control Panel; or Bitvise SSH Client; then the process being used to import the file can stop abruptly. Due to the limited effects, this would not be an interesting attack in most usage scenarios.
In addition, this issue has the following impact on applications using FlowSsh:
If an application using the 32-bit version of FlowSsh connects to a server which sends a specially crafted packet that should cause FlowSsh to disconnect, the application will instead stop abruptly. The severity of this impact depends on the characteristics of the application.
At this time, we believe applications using the 64-bit version of FlowSsh are unaffected.
The following versions of our software are affected by issue 1:
- Bitvise SSH Server 6.xx, but not version 6.51 and future versions.
- Bitvise SSH Server 7.xx, but not versions 7.41 and higher.
- Bitvise SSH Client 6.xx and 7.xx, but not versions 7.41 and higher.
- FlowSsh 5.xx and 7.xx, but not version 7.41 and future versions.
We have addressed issue 1 in Bitvise SSH Server, Client, and FlowSsh versions 7.41 and higher. In addition, we have addressed issue 1 for Bitvise SSH Server 6.xx versions due to the high severity impact on 32-bit versions of Windows.
At this time, the limited impact does not seem to warrant applying this change to 6.xx versions of Bitvise SSH Client and FlowSsh. We encourage users of Bitvise SSH Client to upgrade to the latest versions free of charge. Users of FlowSsh 5.xx will need to have upgrade access to a 7.xx version to upgrade.
Issue 2 consists of incorrect delayed initialization in a compression library used by Bitvise software. We believe this could be used by one SSH session that uses compression to corrupt decompressed data in another simultaneous session that uses compression. However, for this to be likely, there must not have been another session that used compression since application startup. Therefore, the attack would have to occur at the same time as when the first legitimate session that uses compression begins after Bitvise SSH Server or an application using FlowSsh has started.
The following versions of our software are affected by issue 2:
- All older versions of Bitvise SSH Server, but not versions 7.41 and higher.
- All older versions of FlowSsh, but not version 7.41 and future versions.
Bitvise SSH Client only ever establishes one SSH session per process instance, so the issue cannot be exploited. A FlowSsh application could be affected if it simultaneously starts multiple concurrent SSH sessions after launching.
We recommend that all users of affected Bitvise SSH Server, Client, and FlowSsh versions upgrade to the newest current versions, which can be downloaded from our website:
- The latest version of Bitvise SSH Server – for example, 7.42 or newer.
- The latest version of Bitvise SSH Client – for example, 7.42 or newer.
- The latest version of FlowSsh – for example, 7.41 or newer.
In addition, users of Bitvise SSH Server versions 6.xx who do not wish to upgrade can download version 6.51, which also fixes issue 1, but not issue 2.
Changes in Bitvise SSH Client 7.42: [ 11 May 2018 ]
The End User License Agreement has been updated to try to bring it closer to the requirements of states and their contractors. Terms are otherwise unchanged. Situations in which licenses can be transferred are now laid out so that no permission will be needed in most cases.
The SSH Client now includes a new build of the SSH Server Remote Control Panel (WRC) for use with SSH Server versions 7.21 and above. The new build incorporates improvements to the SSH Server Control Panel since version 7.26.
The SSH Client continues to include older versions of the Remote Control Panel for use with older SSH Server versions. Those remain unchanged.
The graphical SSH Client will no longer mark a profile as changed when a password is changed, but the password is not configured to be saved in the profile.
Changes in Bitvise SSH Client 7.41: [ 29 April 2018 ]
This is not a new feature release, but a successor to 7.39 with continued maintenance updates. (We skip over versions containing zeros to avoid ambiguities. For example, 7.04 and 7.40 might both be referred to as "7.4".)
This version continues an upgrade amnesty. Any Bitvise SSH Client activation code that could activate a previous 7.xx version will also activate this version.
Fixed an issue in zlib compression provided by the Crypto++ library. There existed a race condition which could cause data to be decompressed incorrectly in specific circumstances. (The circumstances required for this to happen do not appear to exist in the graphical Bitvise SSH Client or its command line clients.)
Fixed a denial of service attack vector described in the associated security notification.
- File transfer:
When performing unattended file transfers, the command line client sftpc would previously send a fire-and-forget SSH_FXP_CLOSE message followed by immediately closing the SFTP channel and the SSH session. Depending on circumstances such as network latency, Bitvise SSH Server versions up to and including 7.39 could fail to process the SSH_FXP_CLOSE request and incorrectly log that the final transfer may not have completed as intended. This has been fixed in the SSH Server with version 7.41. But also, sftpc will no longer send a fire-and-forget SSH_FXP_CLOSE before exiting.
In the SFTP interface of the graphical SSH Client, in the Move to... dialog, removed a limit that incorrectly prevented entering more than a fixed number of characters. This prevented use of the Move to feature with long paths and file names.
Changes in Bitvise SSH Client 7.39: [ 20 January 2018 ]
SFTP: In past 7.xx versions, Bitvise SSH Client and FlowSsh would perform a Resume check regardless of the type of server if Overwrite was enabled for upload. We suspect this could cause creation of an empty file with the same name on servers that support creation of multiple files with the same name.
The Resume check will no longer be performed when connected to a server that does not support SFTP v6 check-file and check-file-blocks extensions. With a server that supports these extensions, the Resume check will continue to be performed for Overwrite, since in this case Resume and Overwrite are the same operation.
Security Clarification: [ 5 January 2018 ]
We have received inquiries about whether our software is affected by the Meltdown and Spectre vulnerabilities.
Meltdown and Spectre are fundamentally CPU vulnerabilities which require the attacker to be able to execute carefully selected code, in many cases with high-resolution timers. These vulnerabilities are generally not exploitable in situations where the attacker cannot run such code. If you are using Bitvise software for SFTP or SCP file transfer, port forwarding, Git access, or limited terminal access using the BvShell terminal shell, these types of access do not present an opportunity to exploit these vulnerabilities.
If you are using Bitvise SSH Server to provide terminal shell access to non-administrator users, then if these non-administrator users can run arbitrary programs, they can also run programs that could take advantage of Meltdown to gain administrative access. In this case, we recommend that you apply a Windows patch that attempts to mitigate the CPU vulnerabilities that enable Meltdown.
Changes in Bitvise SSH Client 7.36: [ 27 November 2017 ]
- Development, licensing, and US export control:
This is the first version of Bitvise SSH Server, SSH Client, and FlowSsh published from the United States.
All assets, operations, relationships, and agreements related to Bitvise software development and licensing; including license agreements for use of Bitvise software by users; have been transferred from Bitvise Limited incorporated in Gibraltar, to Bitvise Limited now incorporated in Texas.
Final builds are now performed in Texas. Our software development continues in Slovenia, Germany, and Hungary, and may include developers elsewhere in the future.
This move is an administrative change. Our development, ownership, pricing, support, terms and policies and relationship to customers generally remain the same.
For the purpose of export from the United States, our SSH Server, SSH Client and FlowSsh are self-classified as Mass-Market products using the ECCN 5D992, with the encryption authorization type identifier MMKT. These denote eligibility under License Exception ENC § 740.17(b)(1) of the Export Administration Regulations (EAR).
Bitvise SSH Server, SSH Client, and FlowSsh now come with new license agreements. Users must review the new EULAs, even though the terms remain substantially the same. We apologize for this inconvenience, and have attempted to draft the agreements in a way that this might not be necessary very often.
Windows 10 version 1709, OS build 17046.1000, changed internal Windows structures in a way that prevented Bitvise SSH Server, SSH Client, and FlowSsh from obtaining the agreed value in DH or ECDH key exchange. This prevented successful SSH connections using this new Windows build. Fixed.
There exist SSH implementations based on WeOnlyDo, e.g. freeSSHd, which might not send failure description and language tag fields when sending an SSH_MSG_CHANNEL_OPEN_FAILURE message. Bitvise SSH Server, SSH Client and FlowSsh will now behave as though these fields were sent as empty strings, instead of disconnecting due to an unexpected packet format.
- Command line:
Fixed an issue in command line parsing – most relevant for sexec, stermc, and sftpc – where parameters of the form -name=value would be assigned the last value provided anywhere in the command line; including in the trailing part that may contain one or more commands to run, which is a part from which parameters should not be parsed. Users who use scripts to construct command lines automatically, in a way that incorporates parts from untrusted sources – e.g. environment variable expansion or filename insertion where the source information may not be trusted – are suggested to upgrade. We also call attention to other ways such scripts can be vulnerable if they do not thoroughly validate inputs – for example, by exploiting the & operator if executed using the Command Prompt shell.
Now supports the command line parameter -git, which is shorthand for the new parameters -cmdQuoted and -exitZero. This allows sexec to be more easily configured for use with Git.
Now supports the command line parameter -cmdQuoted. This can be used when the remote command to execute is provided outside of the -cmd=... parameter, but is enclosed in single or double quotes.
Now supports the command line parameter -exitZero. If the remote command executes and returns exit code 0, this will cause sexec to return exit code 0 as well.
Now supports the command line parameter -p <portNr>. This can be used to specify the port number instead of -port=<portNr>.
Changes in Bitvise SSH Client 7.35: [ 16 September 2017 ]
- SFTP GUI:
- Fixed an issue which would cause a crash when all files are removed from the download or upload queue.
- Fixed visual artifacts that would arise while resizing in the SFTP Download or Upload window.
We have identified two compatibility issues in current and past versions of mod_sftp for ProFTPD:
- When using SFTP versions 4-6, when a client requests attributes not supported by mod_sftp, the server returns an incorrectly encoded response. With past Bitvise SSH Client and FlowSsh versions, this would result in a disconnect.
- When using SFTP version 6, mod_sftp indicates support for the check-file extensions, but disconnects if the client requests the server to hash a larger file block by block. This prevents Bitvise SSH Client and FlowSsh from performing hash-based synchronization of file content, which would normally be used instead of Resume or Overwrite if check-file extensions can be used.
We expect these issues to be resolved in future mod_sftp versions. However, mod_sftp now comes configured by default to not send its version in the SSH version string. A client therefore cannot distinguish between a newer version that will contain these fixes, and an older version which does not.
At this time, Bitvise SSH Client and FlowSsh will avoid the known compatibility issues by restricting SFTP protocol version to 3 when mod_sftp is detected. We would like to lift this restriction in the future if there arises a way to detect the mod_sftp version early enough.
We have identifed a compatibility issue with Van Dyke VShell:
- When using SFTP version 6, the VShell server indicates support for the check-file extensions, but does not support block-by-block hashing. This prevents Bitvise SSH Client and FlowSsh from performing hash-based synchronization of file content, which would normally be used instead of Resume or Overwrite if check-file extensions can be used.
- At this time, hash-based synchronization will be avoided when connecting to VShell, and Resume and Overwrite will be used instead.
- If VShell chooses to implement support for block-by-block hashing, Bitvise SSH Client and FlowSsh will once more use this functionality if the server advertises the extension name check-file-blocks in its supported2 packet.
Bitvise SSH Client and FlowSsh will now recognize the check-file extension indicator in the supported2 packet as required by the SFTP extensions draft, in addition to check-file-name and check-file-handle.
Bitvise SSH Client and FlowSsh will now recognize a check-file-blocks extension sent by servers. We suggest that future SFTP server implementations advertise support for check-file-blocks if all of the following are true:
- The server supports block-by-block file hashing.
- Any reasonable block size requested by the client is supported.
- A file can be hashed block-by-block starting from an arbitrary offset.
- Fixed an issue which would cause available public keys to be displayed incorrectly on the Login tab, under Authentication, after a profile was closed.
- Fixed issues involving the launch shortcut icons on the left side of the main SSH Client window. One issue would cause the SSH Client to crash if an icon was dragged out of the shortcut bar in the up direction.
Changes in Bitvise SSH Client 7.34: [ 1 August 2017 ]
- This version fixes a memory leak introduced in version 7.31.
Changes in Bitvise SSH Client 7.32: [ 7 July 2017 ]
- In Windows 10, there appears to be an undocumented change in the GetConsoleTitle function. In previous versions, this would prevent our command line clients (such as sftpc, stermc, sexec, stnlc) from starting when a long command line was used.
- In response to attacks on SHA-1, a number of server administrators appear to be reducing supported key exchange algorithms to only diffie-hellman-group-exchange-sha256. This algorithm involves compatibility issues arising from the dynamic generation of DH group parameters, and was disabled in recent SSH Client versions unless enabled explicitly on the SSH tab. Because some servers support only this algorithm, it is now enabled again by default, but algorithms without group exchange will be preferred, if available.
Changes in Bitvise SSH Client 7.31: [ 3 May 2017 ]
- This is not a new feature release, but a successor to 7.29 with continued maintenance updates. (We skip over versions containing zeros to avoid ambiguities. For example, 7.03 and 7.30 might both be referred to as "7.3".)
- Small changes in key places improve CPU efficiency on the order of 30% (impact may depend on the system). This improves transfer speeds where CPU is the bottleneck – or maintaining same performance, allows for a greater number of simultaneous connections. Users who were previously maxing out a single core and seeing transfer speeds of e.g. 150 MB/s, may now see e.g. 200 MB/s.
- Fixed VT-100 keyboard mappings. Function keys will now be sent correctly over VT-100 and xterm when VT-100 mode is enabled. Adapted navigation keys for VT-100, including: Insert, Delete, Home, End, Page Up, and Page Down.
- Removed unnecessary input length limitations in user authentication input boxes by permitting scrolling. This should allow the use of long YubiKey two-factor authentication strings using the method keyboard-interactive.
- Diffie-Hellman key exchange algorithms that use group exchange are once again deprioritized, regardless of which cryptographic provider is in use. This means other key exchange algorithms will again be preferred. In version 7.21, we stopped deprioritizing these algorithms because our Windows CNG cryptographic provider can handle dynamic DH group parameters generated by servers like OpenSSH. However, there remain older servers, such as SunSSH, which generate DH groups which are not acceptable to any of our cryptographic providers.
Changes in Bitvise SSH Client 7.29: [ 31 March 2017 ]
- Fixed a rarely occurring race condition which could cause the SSH Client to terminate when closing an SFTP channel.
Changes in Bitvise SSH Client 7.27: [ 21 February 2017 ]
- Implemented changes to reduce the incidence of MSI error 1638 during installation of the FlowSshNet component.
- Fixed positioning of the right-click menu for the SSH Client system tray icon on systems with larger than normal (more than 100%) display DPI settings.
Changes in Bitvise SSH Client 7.26: [ 7 February 2017 ]
- Incorporates an update to the Bitvise SSH Server Remote Control Panel for SSH Server versions 7.21+. The update fixes an issue introduced with version 7.21, where exporting a single server host keypair in Bitvise format, using the "Manage host keys" interface in the SSH Server Control Panel, would result in a corrupted file. (Multiple key export worked fine.)
Changes in Bitvise SSH Client 7.24: [ 14 January 2017 ]
- SFTP compatibility improvements for older versions of Cerberus FTP Server:
- When downloading a textual file using the file transfer mode Auto Std, the SSH Client will now close the file before reopening it in text mode. This is to avoid issues with servers that do not properly handle two open handles to the same file simultaneously.
- The default file transfer mode when connecting to Cerberus FTP Server is now Binary.
- When the uninstaller detects that a file is still in use, it can now display the names of applications keeping the file open. (Requires Windows Vista or later.)
Changes in Bitvise SSH Client 7.22: [ 3 January 2017 ]
- Incorporates an update to the Bitvise SSH Server Remote Control Panel for SSH Server versions 7.21+ included with the SSH Client.
Changes in Bitvise SSH Client 7.21: [ 31 December 2016 ]
- On Windows Vista, Windows Server 2008, and newer, our SSH Server, SSH Client, and FlowSsh now support server and client public key authentication using Ed25519, and ECDH key exchange using Curve25519. These algorithms are not available when Windows is running in FIPS mode.
- We have updated support for OpenSSH private keys, so that our software is now able to import and export them in their new format as introduced by OpenSSH in December 2013.
- Our SSH Server, SSH Client, and FlowSsh now support Diffie Hellman key exchange with 3072-bit and 4096-bit fixed groups, using SHA-512 as the exchange hash; and with the 2048-bit fixed group using SHA-256 as the exchange hash.
- On Windows Vista, Windows Server 2008, and newer, our SSH Client and FlowSsh no longer deprioritize key exchange methods that use DH group exchange. On Windows XP and Windows Server 2003, the group exchange methods are still deprioritized by default, because ephemeral DH groups generated by most SSH servers do not pass validation by the Crypto++ cryptographic module we use on these older platforms.
- All current and past versions of Bitvise SSH Client support GSSAPI (SSPI) key exchange methods when Kerberos is available. In previous versions, these key exchange methods were enabled all at once by either selecting SSPI/Kerberos 5 key exchange in the graphical SSH Client; or by passing -sspi to command line clients. Now, the GSSAPI key exchange methods can be enabled and disabled individually on the SSH tab of the graphical SSH Client; or using the -kex=... parameter to command line clients.
- Most references to "SSPI/Kerberos 5 key exchange" have been renamed to "GSS/Kerberos key exchange". In command line clients, the parameters -sspi and -sspiDlg have been renamed -gkx and -gkxDlg. The previous parameter names continue to be supported as aliases.
- Password and keyboard-interactive:
- The graphical SSH Client and command line clients now support a new combined initial authentication method: publickey+kbdi. This is intended for easier authentication with servers that require both public key and keyboard-interactive authentication.
- The graphical SSH Client and command line clients now also support a separate password/kbdi authentication method (-pwKbdi). This can be used to instruct the client to send the password outright over keyboard-interactive, without trying password.
- For consistency with the password authentication method, the initial authentication method publickey+password can now also send the password via keyboard-interactive if the password method fails.
- Authentication methods password and publickey+password now support an explicit setting Enable password over kbdi fallback. This is enabled by default, but can be disabled to prevent the SSH Client sending the password over keyboard-interactive if the password method fails.
- Graphical SFTP:
- A Create link... feature is now available through the context menu on the Local files and Remote files panes.
- A number of commands now support new switches -lit and -wild to force either a literal interpretation, or a wildcard interpretation, of a remote path. Commands that currently support this are: get, dir, move, copy, del, chmod, chown, and chgrp.
- Port forwarding and FTP Bridge:
- Both the graphical SSH Client and stnlc will now automatically retry failed attempts to establish dynamic proxy forwarding; client-to-server or server-to-client port forwarding rules; or to open an FTP bridge.
- In the graphical SSH Client, fixed an issue which would cause the Apply link to not show after some types of changes on the Services, C2S, and S2C tabs.
- In stnlc, fixed an issue which would cause the command-line client to not disconnect as intended if a client-to-server or server-to-client port forwarding rule configured on the command line could not be established.
- Listening sockets created by the SSH Client, such as for client-to-server port forwarding, now use a larger backlog value to reduce the likelihood of connections being refused.
- In the graphical SSH Client, the setting Sensitive information accessibility is now on the Options tab.
- Improved detection and reporting of incorrect obfuscation settings.
- When upgrading, the uninstaller will now automatically retry moving files that are still in use for a brief period before prompting.
Changes in Bitvise SSH Client 7.15: [ 4 September 2016 ]
- Updated EULA to make more explicit our licensing and support policies. The policies themselves remain unchanged.
- In command line clients (sftpc, stermc, sexec, stnlc, spksc), the parameter -proxyPassword had no effect. Fixed.
Changes in Bitvise SSH Client 7.14: [ 3 August 2016 ]
- SSH implementations have a chance of generating RSA signatures slightly smaller than expected with a small probability (e.g. 1:200). Windows CNG has been found to not validate such signatures as presented. With our software versions 7.12, this has resulted in occasional connection or login attempt failures. Our SSH Server, SSH Client, and FlowSsh now re-encode RSA signatures, so that smaller-than-expected ones can verify correctly.
- Windows CNG, as used by our new cryptographic provider in versions 7.xx, has been found to return an incorrect signature size for odd-sized RSA keys (e.g. for 1023-bit or 2047-bit keys). Most SSH implementations do not generate odd-sized RSA keys, but there are old versions of PuTTY which do (e.g. version 0.62). Our SSH Server, SSH Client, and FlowSsh now take steps to support generating and validating signatures using such keys.
- Certain implementations (e.g. OpenSSH version 7.2, but not 7.2p2) have been found to encode RSA signatures using the new signature methods rsa-sha2-256 and rsa-sha2-512 in a way that is not compatible with the specification of these methods. For compatibility, our SSH Server, SSH Client, and FlowSsh will now accept these alternate signature encodings.
- Our SSH Server, SSH Client, and FlowSsh now have improved Windows error reporting, distinguishing NTSTATUS error messages from those associated with HRESULT.
Changes in Bitvise SSH Client 7.12: [ 25 June 2016 ]
- Important: DSA keys larger than 1024 bits are no longer supported. The implementation of these keys in Bitvise software pre-dated the NIST standard for large DSA keys, and was incompatible both with the NIST standard and other implementations that might use it. In general, support for the DSA algorithm is being deprecated by SSH implementations. For interoperability with older SSH installations, we continue to support 1024-bit DSA keys, but we recommend migrating either to 3072-bit RSA, or ECDSA.
- On Windows Vista, Windows Server 2008, and newer, our software now uses a new cryptographic provider, CiWinCng, which uses built-in Windows cryptography. This provider adheres to FIPS 140-2 requirements as long as FIPS mode is enabled in Windows security policy. In FIPS mode, ECDSA and ECDH are supported with curves nistp256, nistp384 and nistp521, but not with curve secp256k1 because this curve is not implemented in Windows. When FIPS mode is disabled in Windows, the curve secp256k1 remains available (implemented using Crypto++).
- On Windows XP and Windows Server 2003, our software continues to use our previous cryptographic provider, which uses the Crypto++ 5.3.0 DLL. This DLL was FIPS-certified, but its certificate has been moved to the historical list due to changed random number generator requirements since January 1, 2016.
- When using the new CiWinCng cryptographic provider - default on all recent Windows versions - the encryption/integrity algorithms aes256-gcm and aes128-gcm are now supported. Our implementation is interoperable with the OpenSSH implementation of these algorithms.
- New RSA signature algorithms rsa-sha2-256 and rsa-sha2-512 are now supported for host authentication.
- The EXT_INFO extension negotiation mechanism is now supported, allowing for the use of new RSA signature algorithms rsa-sha2-256 and rsa-sha2-512 for client authentication.
- When connecting to an SSH server for which some host keys are already known (as full host keys - not fingerprints), the preference list of host key algorithms will now be reordered to favor algorithms for which host keys are known. Previously, if an SSH server added a new host key using an algorithm preferred by the client over an algorithm of a previous host key already trusted by the client, the new host key would have to be manually verified for the very next connection, or else the connection would fail.
- In previous versions, the SSH Client would trim whitespace in a user authentication banner received from the server. This would affect formatting, so the trimming is no longer performed.
- When authenticating using a passphrase-protected keypair, entering the passphrase in the authentication dialog had no effect if the key had not yet been accepted. Fixed.
- The Client key manager will now automatically load public keys configured for the user on the SSH Server if opened during a connected session. This feature is available if the SSH server supports the SSH Public Key Subsystem.
- The SSH Public Key Subsystem channel will now be closed after the Client key manager window is closed. This avoids a spurious "session is still active" dialog that would previously appear if the user's public keys configured on the server were queried or set during the session.
- A Create file feature can now be used to create an empty remote file, which can then be edited using the Edit feature.
- When the server supports file hashing in SFTP version 6, files that already exist on both sides will now be transferred with greater efficiency, and ensuring greater correctness, by comparing hashes of the portion of the file that already exists on both sides, and transferring only the parts determined to be different. This transfer mode overrides the normal Overwrite and Resume modes that are otherwise available with servers that do not support file hashing.
- The Local and Remote panes in the graphical SFTP client now support a filter to display only files with names matching a provided pattern.
- The SSH Client now supports viewing and changing Windows attributes of remote files, if this is supported by the server.
- It is now possible to configure custom POSIX permissions for uploaded files. This is configured in the graphical SSH Client in the main window on the SFTP tab, and supported in the sftpc command line client using the -m=mode and -dm=mode parameters to the put command.
- Copy-and-pasting files in the same directory will now duplicate the files.
- There is now a Move to... feature in the Remote pane menu and the right-click context menu for remote files, allowing remote files to be moved using the graphical SFTP client.
- It is now possible to switch between SFTP tabs using Ctrl + PgUp/PgDn and Ctrl + Tab / Ctrl + Shift + Tab.
- Key combinations Alt + Left and Alt + Right can now be used as shortcuts for Forward and Backward.
- An error message is now displayed if upload fails after a remote file that's being edited is saved.
- Due to an implementation mistake that OpenSSH opted to preserve, the target and link path parameters are swapped by OpenSSH and related servers in SymLink and Link SFTP requests. The SSH Client now swaps these parameters when connected to OpenSSH or ProFTPD.
- Implemented several compatibility workarounds to improve compatibility with Wing FTP Server.
- Addressed issue with navigating to the user's local home directory.
- An attrib command is now supported to query and set Windows attributes of remote files, if supported by the SFTP server.
- The put command now supports parameters -m=mode and -dm=mode to control the POSIX permissions of uploaded files and directories.
- The put and get commands now support the parameter -noTime to disable synchronizing file modification times.
- Creation of hard links is now supported when using SFTP version 6, or using the email@example.com extension.
- Implemented new values for the -progress=... parameter, and improved the progress type used by default when output is redirected to a file.
- Implemented improvements for when paths and filenames contain wildcard characters (* or ?).
- The message "Listing remote directory" will no longer be displayed by chown, chmod and del commands, or when performing put/get with wildcards.
- A variety of copy and paste hotkey combinations can now be individually enabled and disabled using the Properties menu in the graphical Client's terminal window.
- A Select All feature is now available in the graphical Client's terminal window, allowing the entire screen buffer to be selected (e.g. to copy).
- The SSH Client's terminal windows now support alternative Shift + function key combinations. This is enabled in the graphical Client using the profile setting Alt. Shift+Fn on the Terminal tab, and in stermc using the -altShiftFunc parameter. When enabled, this will cause the xterm protocol to send Shift + function key combinations compatible with PuTTY. Note that, in this mode, the escape sequences for Shift + F1/F2 and Shift + F11/F12 are the same as for plain F11/F12.
- In xterm, key combinations of Alt, Shift, Ctrl (in any combination) + F1-F4 are now sent using the same escape sequences as on Linux. For compatibility with older Bitvise SSH Server versions, previous sequences continue to be sent when connected to Bitvise SSH Server.
- The default terminal window size is now 100 columns by 35 rows, with 1,000 history lines. The previous default was 80 x 25 with 300 history lines.
- Fixed an issue which could cause the graphical Client's terminal window to crash after screen buffer resize.
- Port forwarding:
- For server-to-client port forwarding rules, the listening interface is now free-form, allowing it to be used with e.g. DNS names or Unix sockets.
- When a server-to-client port forwarded connection is received from the server, and the reported listening interface is not recognized, the SSH Client will now attempt to match the connection based on port number only. The forwarded connection will still be refused if there are multiple possible port-based matches, and no match for the listening interface.
- Fixed an issue which caused the SSH Client to not properly remove C2S and S2C port forwarding rules where the listening port was set to 0.
- In the stnlc command line client, the commands "c2s list" and "s2c list" were incorrectly showing the listening port as the destination port. Fixed.
- The enabled states of port forwarding rules on the C2S and S2C tabs are now checkboxes, making them easier to enable or disable.
- It is now possible to create or reset a profile with a blank default state using the New profile or Reset profile button.
- SSH Client profiles may contain sensitive information such as a password with which to authenticate to the server, or client authentication keypairs. In previous versions, such information was stored encrypted with a static key that could be decrypted on any computer. It is now possible to save SSH Client profiles in a way such that any passwords or keypairs can be decrypted only on the current computer, or only by the current user. This setting only affects sensitive fields; the rest of the profile will still load on another computer.
- The command line clients sftpc, stermc and sexec will now tolerate a server disconnect if it occurs after the client has closed the session channel. In previous versions, a disconnect would cause an error message and a non-zero exit code even if it occurred at this late point.
- The most useful information now appears at the beginning of window titles for terminal, SFTP, and the main SSH Client window. This makes it easier to distinguish connections to multiple servers.
- The Client key manager can now import multiple keypairs at once in the Bitvise format.
- Versions 6.4x targeted the SSE2 instruction set, which caused them to not run on old computers lacking support for SSE2. Versions 7.xx now target the SSE instruction set, which allows for compatibility with old CPUs, at the cost of a small performance penalty - in our measurements, between 0 and 0.5%.
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.