Bitvise SSH Client 7.43 License Key Full Download
Leana Eckes
'Tunneling' or 'port forwarding' refers to the ability of an SSH client (a) to have the SSH server initiate a TCP/IP connection to another server on the SSHclient's behalf (called client-to-server tunneling), or (b) tohave the SSH server accept incoming TCP/IP connections on a server's interfaceand port and forward those connections to the client (called server-to-client port forwarding). (You can learn more in our Short guide to SSH port forwarding.)
If your requirements are simple, Bitvise SSH Server provides two easy ways to control a user's or group's access to tunneling. In the Bitvise SSH Server settings entry for the account or group, there are fields Permit C2S port forwarding and Permit S2C port forwarding. Disable the first and the user will not be able to tell the SSH server to initiate outbound connections. Disable the second and the user will not be able to instruct the SSH server to listen for connections to forward to the SSH client.
Sometimes, such simple controls are not sufficient. For example, you may want to allow the user to use port forwarding to access a service provided by a particular machine on the server's local network; but you don't want to allow the user to use this capability to access any server on the internet, e.g. as a proxy for web browsing.
Such fine-grained control is provided by the Connect rules and Listening rules settings available in Bitvise SSH Server Advanced settings, separately for each group or account settings entry.
Connect rules control what destinations the SSH client will be able to connect to using client-2-server port forwarding. There are four types ofconnect rules: those that match IPv4 addresses, IPv4 addresses, DNS names, and a separate rule type that matches everything.
A DNS name rule allows you to specify a destination either using aspecific DNS name or a wildcard of the form *.com, *.bitvise.com or*.research.bitvise.com. A lone wildcard (just *) will match anydestination, and is equivalent to a match-all rule.
If Bitvise SSH Server gets a client-to-server tunneling request for which there is no match in the account's Connect rules, the Connect rules of the corresponding group settings entry will be processed. If no match is found in the group Connect rules either, the connection is rejected.
By default, the Connect rule list for a group contains a single entryallowing access to all destinations if 'Permit C2S port forwarding' forthe user is true. An account's Connect rule list is empty by default,passing all decisions to Connect rules defined for the user's group.
Listen rules control what server interfaces and ports the user will be able to bind in order to accept connections and forward them to the SSH client. There is a separate list of listening rules for IPv4 and IPv6 requests.
A listen rule identifies an IP address of one of the server's network interfaces, and a port range for which the SSH client is allowed or denied listening. The special address 0.0.0.0 for IPv4, or "::" for IPv6, matches any interface.
A listen rule may contain additional Accept rules which control the origin hosts from which connections to the interface and port range defined in the listen rule will be accepted. By default, the accept rule list contains a single entry allowing connections from all sources.
If Bitvise SSH Server gets a server-to-client tunneling request for which there is no match in the account's Listen rules, the Listen rules of the account's group settings entry will be processed. If no match is found in the group Listen rules either, the tunneling attempt is rejected.
By default, the Listen rule list for a group contains a single entry allowing all interfaces and ports to be bound if 'Permit S2C port forwarding' for the user is true. An account's Listen rule list is empty by default, passing all decisions to Listen rules defined for the user's group.
Suppose your SSH server resides on machine 10.10.10.5 in your internal network, and you wish to allow the user to connect, via SSH tunneling, to a Remote Desktop service running on machine 10.10.10.16. You would first need todecide whether to configure this policy for the user's group or for theindividual user. If for the individual user, you would need to add aBitvise SSH Server account settings entry for the user if one does not yet exist. Then, in Advanced settings, you would open the group or account settings entry that you wish to configure this restriction for, and perform the following:
In this example, if you wanted to prohibit the user from setting up any kind of server-to-client port forwarding whatsoever, you would simply set 'Permit S2C port forwarding' to false. Otherwise, if you wanted to configure a specific range of ports and interfaces where the SSH client may instruct the SSH server to listen, you would add appropriate Listen rules as in the Example 2 (below).
Suppose your SSH server machine has two network interfaces: 10.10.10.5 isthe private IP address in the local area network and 123.23.12.111 isthe server's public IP address on the internet. You know that the userwho will be logging into the SSH server will need to run a program on theserver side which will initiate a TCP connection to the client, and theuser will achieve this using server-to-client port forwarding. You wantto allow the user to forward connections from the server's localnetwork through the server's 10.10.10.5 private network interface, aswell as from the server itself using the 127.0.0.1 loopback interface,but you do not wish to allow the user to listen for connections fromthe internet through interface 123.23.12.111. You also want to restrictthe user to listening only on ports 1024-65535.
Again, you would first need to decide whether to configure this policy for the user's group or for the individual user. If for the individual user,you would need to add a Bitvise SSH Server account settings entry for the user if one does not yet exist. Then, in Advanced settings, you would open the group or account settings entry that you wish to configure this restriction for, andperform the following:
In this example, if you wanted to prohibit the user from setting up anykind of client-to-server forwardings whatsoever, you would simply set'Permit C2S port forwarding' to false. Otherwise, if you wanted toconfigure a specific range of destination servers and their ports towhich the SSH client may connect, you would add appropriate Connectrules as in Example 1 (above).
Bitvise SSH Client 9.38
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
Bitvise SSH Client 9.35
sftpc:
- Improved behavior of the -noBuf parameter for put and get commands
Bitvise SSH Client 9.34
Installation:
- When installing using command-line parameters, the -autoUpdates parameter could previously be used only to disable automatic updates. It now also supports other values (stronglyRecommended, recommended or allAvailable).
- The FlowSshNet library, an optional SSH/SFTP scripting feature included with the SSH Client, now uses the Universal C Runtime. This allows the SSH Client to no longer include the outdated Visual C++ 2010 CRT. As a result, FlowSshNet is now installed only on Windows 7 SP1 or newer. (Previously, this feature was compatible with Windows Vista or newer.)
SFTP drive:
- Updated the WinFsp version included with the SSH Client to 2.0.23075.
- Improved the WinFsp installation process.
SSH:
- When connecting through an SSH jump proxy, interactive authentication methods can now be used to authenticate against the jump proxy. Previously, only pre-configured (unattended) authentication could be used.
- When the SSH Client fails to connect to a server, the error message now contains more detailed information about IP addresses to which the client attempted to connect.
stermc:
- In certain versions of Windows, the Windows function ScrollConsoleScreenBufferW fails if the destination coordinate is the same as the origin. This would cause previous stermc versions to exit with an error. Fixed.
sftpc:
- The sftpc command-line client now supports new get/put command parameters:
- -rv: Resume verifiably. Acts like -r for Resume, but does not resume unless the server supports synchronization using block-by-block hashing. This avoids corruption which is possible if heuristic resume detects the file can be resumed, but there are subtle changes in the middle of the file.
- -noSync: Disables synchronization using block-by-block hashing, even if the server supports it. This can be used with -r to achieve a faster heuristic resume, but corruption is possible if there are subtle changes in the middle of the file.
- -noBuf[=yn]: If the server supports the extended SFTP attribute [email protected], this allows the user to express a preference whether the server should open the file for unbuffered I/O.
SFTP:
- The graphical SFTP interface now remembers its maximization state.
- The graphical SFTP interface now offers an option to clear recent folder history.
- When using cut & paste (rather than copy & paste) between Local and Remote panes, files are now moved instead of copied.
- In both graphical SFTP and sftpc, the Resume and Overwrite options are now once again available separately, even if the server supports synchronization using block-by-block hashing. This allows the user to express a preference to resume a file, but only if the partial destination file is unchanged relative to the source.
- When uploading, the SSH Client now includes the extended SFTP attribute [email protected] to communicate the final intended size of the file. This can help detect and diagnose incomplete transfers.
- The mirror feature would incorrectly remove destination files after they were mirrored, if the file names were present in the destination with a different case than in the source. Fixed.
- The mirror feature now supports a fast skip option which attempts to skip files which are present in both source and destination with the same size and last modification time. This can dramatically improve the speed of large mirror transfers where most files are unchanged, but at the cost of not verifying the content of skipped files.
Bitvise SSH Client 9.33
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.
Bitvise SSH Client 9.31
Fixed:
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
User interface:
- Names and strings containing the & character were not properly displayed in lists
File transfer:
- When using the Move to dialog in the SFTP window, the SSH Client could crash
Bitvise SSH Client 9.28
Installation:
- If Install WinFsp was unchecked, the SSH Client installer would still unpack WinFsp files, without registering them. The installer will no longer unpack WinFsp files unless Install WinFsp is selected.
SSH:
- The SSH Client is now compatible with the OpenSSH-style authentication agent in 1Password. The SSH Client previously refused to connect to the Windows named pipe created by 1Password because the pipe owner is not a member of the Administrators group or Local System. For compatibility with this agent, the SSH Client no longer checks pipe ownership, but implements more validation of information received over the pipe.
Port forwarding:
- The command-line parameters -c2sFile and -s2cFile now also import comment fields, if present
Terminal:
- If the accent color was enabled for window title bars in Windows, the SSH Client's terminal window title could be hard to read
- Double-click word selection did not work correctly on the first word of the first line in the terminal window
- The terminal window now supports 5-hexadecimal-digit Unicode characters, i.e. Unicode code points higher than 65535
Bitvise SSH Client 9.27
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 window's system menu. Fixed.
Bitvise SSH Client 9.26
EULA:
- We updated our EULAs to formalize our existing practices regarding the nature and behavior of our software (it is a product, not a service; the data it handles is not sent to Bitvise; risk tradeoffs with updates) and the way we provide support (via email and our case management system, in written form).
Installation:
- The SSH Client installer now offers the option whether to install WinFsp. WinFsp is required to use the SSH Client's SFTP drive feature, but is not needed for other functions.
- The SSH Client can now use WinFsp installed from another source, such as the official WinFsp distribution, or installed by a third-party application, instead of installing its own. We cannot guarantee reliability or performance when using such other versions of WinFsp. However, the SSH Client now tries to use them.
Cryptography:
- OpenSSL version updated to 1.1.1s. 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.
Terminal:
- Since version 9.23, the SSH Client's terminal window disables client-side scrolling when the server switches to the alternate screen. This is correct behavior, and it avoids confusing users, but it has confused other users, who were used to scrolling in the alternate screen.
- The SSH Client's terminal window now displays a padlock icon in the title bar when the alternate screen is enabled. This indicates that the terminal window is in a special state and explains why scrolling is disabled.
- The SSH Client's terminal window did not work on Windows XP. Fixed.
SSH Server Remote Control Panel:
- When using the SSH Client to remotely administer Bitvise SSH Server, the SSH Server Remote Control Panel would exit unexpectedly when trying to manually apply an update. Fixed.
Bitvise SSH Client 9.25
Graphical client:
- User Authentication Banner dialog text can now be selected and copied to clipboard
- Improved default file browse filter for client authentication keypair import
Bitvise SSH Client 9.24
General:
- SSH Client help windows now allow selection and copy & paste
- Updated keyboard shortcuts in the pop-up menu for the SSH Client icon in the system notification area. This resolves conflicts and makes the shortcut keys consistent with Ctrl+Shift shortcuts in SSH Client windows.
SSH:
- The SSH Client now displays the signature algorithm used during client authentication with a public key
- The default list of submethods for keyboard-interactive authentication is now empty
Command-line clients:
- Improved output of command-line clients when output is piped into another program, or redirected into a file
sftpc:
- When output is redirected, sftpc no longer truncates file and directory paths shorter than 1,000 bytes. For easier processing, file transfer results such as "OK" and "in sync" are now displayed as "" and ""
- The remove/delete commands del, ldel, rm, lrm, rmdir and lrmdir now support the -ifExist parameter. If passed, this parameter causes the command to test whether the path exists before attempting to delete it. If the path does not exist, the command succeeds.
Terminal:
- Due to Ctrl+Shift+... keyboard shortcuts new in versions 9.xx, the terminal window in the graphical SSH Client would no longer send to the server Ctrl+Shift key combinations such as Ctrl+Shift+F1. These combinations are now sent again.
- The clear command now causes the terminal window to scroll down instead of overwriting visible screen content
- A full reset, or a soft terminal reset, now avoids clearing the primary screen buffer, such as when the screen command exits
Bitvise SSH Client 9.23
Terminal:
- When the alternative window buffer is activated, the terminal window now prevents client-side scrolling. This interfered with display of server-side applications which provide their own scrolling via keyboard.
SFTP drive:
- There exist servers, such as GlobalSCAPE, which support neither the SFTP request space-available, nor the alternative [email protected]. These requests are used to query free space on the server. With such servers, this information cannot be queried, so the SSH Client will now report a very large amount of free space on the SFTP drive. The client previously reported zero free space, which prevented some applications from writing files.
Bitvise SSH Client 9.19
Terminal:
- Restored behavior from previous SSH Client versions, including 8.xx, where right-click can be used immediately after selecting to copy-and-paste the selected text
- The DECSTBM message (Set Top and Bottom Margins) should now be handled correctly
spksc:
- The command-line client for the SSH Public Key Subsystem, spksc, now supports commands to list local keys in addition to public keys configured for public key authentication on the server.
- If Ctrl+C was pressed during command execution, spksc would previously hang
Host key manager:
- When using the Modify Host Key dialog, pasting a host address containing spaces would cause the SSH Client to crash
Bitvise SSH Client 8.53
- When using one of the key exchange methods with Diffie Hellman group exchange, the SSH Client and FlowSsh could perform an invalid memory access. Invalid DH group size parameters could be sent to the server. Fixed.
Security Clarification:
- We are receiving many inquiries about whether our software is affected by the recent Log4j vulnerability CVE-2021-44228
- Bitvise software does not use Log4j, and does not interact with it
Bitvise SSH Client 8.52
This is not a new feature release, but a successor to 8.49 with continued maintenance updates:
Graphical client:
- Certain user interface elements would not display correctly on Windows 11. Fixed.
Command-line use:
- The SSH Client's command-line clients (sftpc, stermc, sexec, stnlc, spksc) now support the widely accepted "--" syntax to identify the end of named parameters and the beginning of positional parameters.
Bitvise SSH Client 8.49
SFTP:
- When used under Parallels for Mac, the SSH Client was unable to list folders shared by the Mac (for example, MacHomeDesktop). This arose because the SSH Client used an advanced Windows filesystem API which the Mac does not implement. The SSH Client now uses a simpler version of this API, allowing the listing of Mac folders.
sftpc:
- The get command now supports a -wait switch. This causes the get command to wait for the server's confirmation that the file has been closed before continuing any further actions. When used with conjunction with -del, this causes sftpc to wait for the server's confirmation that the file has been closed before attempting to delete the file.
- sftpc now supports a new wait command. This causes sftpc to wait until it receives from the server any pending confirmations for file and directory close requests, before proceeding with any other actions. If there are no outstanding close requests pending confirmations, the wait command does nothing.
stermc:
- When using the stermc terminal shell command-line client, if the remote shell exited with a non-zero exit code, the SSH Client's totermc or bvtermc terminal client process would continue to run after stermc exits. These processes would potentially interfere with console input. Fixed.
Command-line clients:
- When input or output is redirected, then by default, the SSH Client's command-line clients (including sftpc, sexec, stnlc, stermc and spksc) will now use the input/output code page associated with the console in which they run (Windows functions GetConsoleCP and GetConsoleOutputCP), instead of the system-wide ANSI code page (Windows function GetACP). This causes output from Bitvise command-line clients to respect the code page set using chcp. For example, when chcp has been used, sftpc >> file.txt will now use the same code page as echo xxxx >> file.txt.
- Improved BOM handling when output is redirected with code pages UTF-8, UTF-16, and UTF-16BE. The BOM will now be consistently emitted when redirecting into an empty file, but not when redirecting into a non-empty file or a stream.
Bitvise SSH Client 8.48
General:
- The Notes tab is now scrollable and may contain much more text
SFTP:
- SSH Client version 8.46 introduced an issue where text file uploads would not work when using the file transfer modes Auto Std or Text, which are available in SFTP protocol versions 4 and 6. Fixed.
- When downloading a file using the Auto Std file transfer mode, which is available in SFTP protocol versions 4 and 6, the SSH Client first opens the file in binary mode. If the client detects that the file is textual, it closes and reopens the file using the flag SSH_FXF_TEXT_MODE.
- Some servers do not handle this scenario gracefully and do not allow the file to be reopened. With these servers, the Auto Std mode cannot work. In this case, the SSH Client will now display a more useful error to suggest changing the file transfer mode.
- The SFTP v4 draft specification from 2002 contains a typo in the definition of SSH_FILEXFER_ATTR_PERMISSIONS. This flag is defined with incorrect value 0x40 instead of the correct value, 0x04. This conflicts with previous and subsequent SFTP versions, as well as SSH_FILEXFER_ATTR_ACL defined in the same draft. Implementations should use the correct value, 0x04.
- There exist implementations of SFTP v4 that do not identify this error, and do not use the correct value. To aid compatibility with such servers, the SSH Client will no longer request SSH_FILEXFER_ATTR_PERMISSIONS as part of SSH_FXP_LSTAT if the Permissions column is not enabled on the Remote pane of the Browse tab.
Bitvise SSH Client 8.47
SSH:
- The SSH Client will now recognize a server with "MFT" in its SSH version string as a variant of "J2SSH_Maverick". This means the SSH Client will no longer send SSH_MSG_EXT_INFO by default to such servers. See the previous compatibility change for J2SSH_Maverick, in version history for SSH Client version 8.42.
Authentication:
- When the -keypairFile parameter is used to specify a password-protected keypair in a non-Bitvise format, and no valid passphrase is provided, the log message will now be more useful.
Remote Desktop:
- When using the single-click Remote Desktop forwarding feature on an ARM version of Windows, the SSH Client will now disable hooking of the Remote Desktop client (MSTSC). The SSH Client normally does this on Windows x86 and x64 so that the Remote Desktop window title can reflect the destination of the Remote Desktop connection. However, this prevented single-click Remote Desktop forwarding from functioning on ARM versions of Windows.
Bitvise SSH Client 8.46
SFTP:
- Since version 8.45, the SSH Client now uses SFTP v6 file open block flags SSH_FXF_BLOCK_WRITE and SSH_FXF_BLOCK_ADVISORY if the server advertises support for them. This helps avoid corruption of files while they are being transferred. We have received a report of a server that advertises support for these flags, but fails an open request if the flags are used. The SSH Client will now repeat an open request that fails this way, without the flags.
Command-line clients:
- When using Bitvise SSH Client command line clients sftpc, stermc, sexec, stnlc or spksc using a -keypairFile parameter that points to an encrypted keypair in non-Bitvise format, but without a -keypairPassphrase parameter that would provide a decryption passphrase, the SSH Client would display a cryptic error. The error is now less cryptic.
Bitvise SSH Client 8.45
Automatic updates:
- 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
- Improved the automatic update locking mechanisms
SSH:
- When displaying the host key received from the server, the SSH Client will now display the signature algorithm (e.g. RSA over SHA-256) rather than just the host key algorithm (e.g. RSA)
Graphical client:
- When the SSH Client was started hidden in the system notification area, it would cause a phantom Alt-Tab menu entry to appear
SFTP:
- When uploading files using SFTP v6; and if the server advertises support for either the block flag SSH_FXF_BLOCK_WRITE or the combination SSH_FXF_BLOCK_WRITE SSH_FXF_BLOCK_ADVISORY; then the SSH Client will request one of these block flags when opening the file. This is to prevent premature actions by other server-side processes or file transfer clients that can modify or corrupt the file before the upload is complete.
- Uploading to a blind drop location that does not permit a directory listing could crash the SFTP window or the SSH Client process
- For improved compatibility with blind drops, it is now possible to navigate the Local and Remote panes to any location, even one that results in an error or does not allow a directory listing. An error dialog will be displayed when attempting to list such a directory, but it is now possible to try transferring files to or from such locations regardless.
Command-line clients:
- The log utility would output its own newlines as CRLF, but would record newlines from child processes as they were written by the process. If the child process used LF newlines (without CR), the output newline convention would be inconsistent. The log utility now consistently outputs newlines as CRLF.
Bitvise SSH Client 8.44
SSH:
- Bitvise SSH Client and FlowSsh will now recognize servers with "Maverick_SSHD" and "GoAnywhere" in th