Newer versions
Bitvise SSH Server 9.xx Version History
Bitvise SSH Server 8.xx Version History
Bitvise SSH Server 7.xx Version History
Bitvise SSH Server 6.xx Version History
Bitvise SSH Server 5.xx Version History
WinSSHD 4.xx Version History
Support for these software versions has ended:
You are viewing version history for outdated Bitvise software versions. These versions contain known issues which are resolved in newer releases. These versions will not receive updates, whereas the most recent versions will.
We recommend all users to use Bitvise software versions not older than one year, or newer in case of recent security fixes.
It is one of our top priorities that users should experience as few problems as possible when updating to the latest versions of our software. If an upgrade causes you trouble, let us know.
The main outlier in ease of upgrading is the SSH Server's scriptable configuration language. If you rely on this feature, upgrades to new SSH Server feature releases require adjustments to scripts.
Changes in WinSSHD 4.28: [ 28 November 2008 ]
- Port forwarding: fixed an issue where a server-to-client port forwarding socket might not be closed, causing subsequent attempts to accept connections on that port to fail until WinSSHD was restarted.
- Added known versions of the MS Firewall Client 2004 Windows Sockets Layered Service Provider to the list of LSPs that WinSSHD will trust to use. This enables port forwarding for users who have this firewall client installed.
Changes in WinSSHD 4.27: [ 14 July 2008 ]
- WinSSHD now deactivates WoW64 filesystem redirection before executing child programs on Windows x64. This provides terminal shell users with the 64-bit version of the Command Prompt, and the ability to run other 64-bit system programs, rather than being limited to 32-bit versions as before.
- WinSSHD now makes it possible for other programs, running on the same machine under an administrator or local system account, to retrieve information about current sessions and tunneled connections. A new command line utility, 'wstat', is provided, allowing this information to be queried from the command line. The source code for this program is provided in the WinSSHD installation directory as a sample for third party application developers.
- WinSSHD now explicitly enables the TCB privilege so that it can perform UAC user elevation when the WinSSHD service is being run under an administrator account other than Local System. In order for this to work, the service account under which WinSSHD is running must be granted the right "Act as part of the operating system".
Changes in WinSSHD 4.26: [ 25 February 2008 ]
- For compatibility with Windows Vista and Windows Server 2008, WinSSHD now automatically elevates an administrator's token upon login. When Kerberos authentication is used, the SSH client must be run elevated in order for administrative access to be available on the server side under SSH.
- Added a setting to make WinSSHD run as a lower-than-normal or higher-than-normal priority process. This helps busy sites which want to favor another application at the expense of WinSSHD, or WinSSHD at the expense of other programs.
- WinSSHD now keeps only one copy of settings for all SSH sessions, rather than making a separate copy for each thread. This improves performance for sites with high load and a large number of accounts in WinSSHD Settings.
- The SFTP server subsystem now initiates no TCP loopback connection to WinSSHD if all SFTP log events are disabled. This helps sites with persistent high frequency of connections which may run out of ports over time.
- The WinsshdCfgManip COM object now uses a heap-based rather than a stack-based buffer for settings and keypair. This permits programmatic manipulation of WinSSHD settings from IIS, and stack-constrained environments in general.
- A bug in the WinSSHD installation process caused no keypair to be generated when installing a new non-default site. Fixed.
- A bug in WinSSHD settings handling used to cause all key exchange algorithms to be offered, even if some were disabled. Fixed.
Changes in WinSSHD 4.23: [ 23 March 2007 ]
- The WinSSHD installer and all contained executables are now digitally signed with the Bitvise private key. Windows Explorer will now show a 'Digital Signatures' tab if you right click on one of the executables and open its properties.
- Fixed incorrect narrow-to-wide character conversion used in SFTP logging that could result in an empty path name being logged.
Changes in WinSSHD 4.22: [ 25 December 2006 ]
- WinSSHD now installs and works normally on Windows Vista. (With previous versions, explicit user action was necessary to make the installer and the WinSSHD Control Panel run as administrator.)
- wcfg and WinSSHD Settings Query: the Erase instruction in the user public key list would incorrectly erase all keys after the one that should have been erased. Fixed.
Changes in WinSSHD 4.21: [ 29 October 2006 ]
- The logon delayer component that was reimplemented in WinSSHD 4.19 had a bug which could cause the WinSSHD service to stop when a number of simultaneous unsuccessful login attempts from multiple IP addresses were being made. Fixed.
- WinSSHD was using the new logon delayer component incorrectly when Windows rejected a logon attempt because the user's password had to be changed. The problem would cause the user's session and all further password authentication requests for the same user or from the same IP address to hang. Fixed.
- As a result of case sensitivity changes in WinSSHD 4.16, recent WinSSHD versions would require a virtual user name to be supplied with correct casing when logging into a virtual account. Virtual account names are now case insensitive again.
The domain controller lookup logic that was changed in WinSSHD 4.19 to accomodate Windows 2003 domain forests could fail to find an NT4 domain controller, preventing logins into NT4 domain accounts. The domain controller lookup and account info retrieval logic is now more flexible to allow for various combinations of domain types.
When you try to log into an NT4 domain account for the first time after WinSSHD starts, there may now be a 10 second delay compared to WinSSHD 4.18 and earlier. This delay is because WinSSHD tries to lookup the domain controller with 2000+ Windows functions first, and then falls back to NT4-style lookup. Subsequent login attempts should be faster because WinSSHD remembers the NT4 domain type.
- WinSSHD and Tunnelier would trim trailing spaces in the other side's SSH version string. This would cause key exchange failure when the other SSH implementation sent a version string with trailing spaces. Fixed.
- The WinSSHD installer GUI could mis-detect a WinSSHD version 3 installation and fail to enable the 'Replace' or 'Upgrade' button, requiring the WinSSHD version 3 installation to be uninstalled first before the 4.xx installer was run. Fixed.
- WinSSHD 4.19 introduced a static dependency to a Windows API function which isn't available on NT4. This would prevent recent WinSSHD versions from working on NT4 unless Active Directory Client Extensions were installed. Fixed.
Changes in WinSSHD 4.20: [ 12 October 2006 ]
WinSSHD subsystems toterm, bvterms, scp and sftps are now executed in the WinSSHD installation directory instead of the logged-on user's initial directory. This fixes a privilege-escalation vulnerability where a user limited to SFTP access could upload a specially crafted DLL into his initial directory, and Windows would load and execute that DLL when starting the SFTP server, allowing the user to execute arbitrary code with the permissions of the account into which he is logged in.
This vulnerability was most pronounced on servers running OS versions older than Windows 2003 or Windows XP SP2. On these systems, Windows uses an unsafe DLL search order by default. However, it was still possible to exploit this vulnerability on some Windows XP SP2 and Windows 2003 systems if certain products were installed that inject unresolved DLL dependencies into programs. This version fixes this vulnerability by starting the subsystems from the WinSSHD installation directory and having the subsystems change directory to the desired location themselves.
Changes in WinSSHD 4.19: [ 12 September 2006 ]
- The logon delayer component is now reimplemented to gracefully handle many simultaneous clients logging in at the same time. Public key and GSSAPI login attempts are now not delayed at all, so as to provide an avenue of access when an ongoing brute force password guessing attack blocks an account.
- WinSSHD now uses more appropriate Windows functions to obtain the name of the domain controller for a domain, improving compatibility with multiple-domain forests.
Changes in WinSSHD 4.18: [ 24 August 2006 ]
- An SSH session could hang while consuming 100% CPU when a port forwarding tunnel was closing. Believed fixed.
- An SSH session could hang indefinitely waiting for a graceful shutdown of the SSH TCP connection. Fixed.
- Fixed synchronization issue in sessions with larger numbers of concurrently opened channels (for example, a session with many concurrent port forwardings).
Changes in WinSSHD 4.17: [ 17 August 2006 ]
- Previous versions of WinSSHD would start the SSH protocol by sending a version line immediately followed by the server's KEXINIT packet. This would cause problems with buggy clients like Perl's Net::SSH::Perl and Ruby's Net::SSH, which have race conditions due to incorrect use of I/O buffering in their version string handling logic. Unfortunately, these clients are many and fixes for them difficult to deploy. WinSSHD therefore now sends the KEXINIT packet only after receiving the client's version string to avoid triggering the race condition in these clients.
Changes in WinSSHD 4.16: [ 04 July 2006 ]
- WinSSHD now does not uppercase account names internally in order to improve interoperability with case-sensitive Kerberos domains.
- SFTP: aggressive SFTP protocol version checking had been added into the SFTP module, and this caused problems when renaming files with CuteFTP Pro because it fails to initialize the SFTP protocol with a version packet. Scaled back version checking for interoperability with CuteFTP.
- WinSSHD Settings would embed extra nulls into filenames and pathnames when these were obtained through the browse button. Fixed. The nulls are now also automatically ignored when loading settings.
- The SSH implementation would sometimes prematurely let through higher-layer packets sent by some SSH implementations which do not mind their output during key re-exchange. This could result in the session terminating due to conflicting transport state.
- Improved SSH packet tracing.
- Fixed socket closing issues where deinitialization functions could be attempted on a socket after it had already been closed.
- Decreased severity of common sockets errors to info, uncommon ones to warning. (Previously, common socket errors were logged as warnings and uncommon ones as errors.)
- Added trace logging capability for the domain controller-locating process.
Changes in WinSSHD 4.15a: [ 08 May 2006 ]
- WinSSHD now tries multiple ways of looking up usernames in Active Directory and uses the scheme that delivers best performance and results.
- WinSSHD would not correctly escape spaces in usernames when performing Active Directory lookup. Fixed.
- WinSSHD now loads the user's profile on login if the 'Map remembered shares' or 'Map remote home directory' setting is set to ensure that Windows will correctly report the data these settings require if the user has not logged on before.
- WinSSHD Settings could freeze on some machines in some circumstances when a new window was opened. Fixed.
Changes in WinSSHD 4.15: [ 27 April 2006 ]
- Environment variable expansion is now supported for explicitly configured network share mappings.
- Concurrent session limits can now be configured per individual user or for the entire server.
- Under heavy port forwarding stress, a WinSSHD session thread could block in a tight CPU-consuming loop. The service would continue to be responsive, but a restart would be required to get rid of the CPU-using thread. Believed fixed.
- Previously, WinSSHD did not use the 'exclusive' option when binding its listening sockets. This meant that any locally logged on user that could execute programs could also mount a man-in-the-middle attack against incoming SSH sessions by intercepting connection attempts intended for WinSSHD. Such attacks could be detected on the client because an unprivileged user cannot fake the SSH server's host key. However, on Windows NT SP4 and higher, WinSSHD now binds its listening sockets exclusively. Unfortunately, binding exclusively involves a tradeoff which makes sense for long-term listening sockets but not for ephemeral ones. Binding ephemeral listening ports exclusively would allow a remote denial of service putting these ports out of use. Therefore, the listening sockets WinSSHD opens on clients' behalf during port forwarding are not at this point opened exclusively. This means that port forwarding sockets are still subject to interception by other locally logged on users. Security policies need to be crafted accordingly.
- The broken session detection feature would not be applied before the client's version string was fully received. This would result in a session thread idling until Windows reported disconnection. This could take a long while, occupying resources in the mean time. WinSSHD now detects a broken session in this stage, as well.
Changes in WinSSHD 4.14: [ 29 March 2006 ]
- Fixed: if server-side forwarding rules were configured, they would be refreshed on configuration change even if the client had not sent the server-side forwarding invitation.
Changes in WinSSHD 4.13: [ 17 March 2006 ]
- Fixed: the Proxy profiles feature (allowing client-2-server port forwardings to use a SOCKS or HTTP CONNECT proxy for outgoing connections) didn't work for HTTP CONNECT proxies.
- Fixed a memory corruption issue in code that unmaps network resources on SSH session cleanup. Corruption would occur if there were multiple network resources to unmap and some of them failed. This may have been a reason for reported occurences of service failure associated with events such as 'Unexpected exception while unmapping remote directories during logoff'.
- For compatibility with newer clients, the WinSSHD SFTP server now identifies itself as SFTP version 3. Should still support SFTP version 2 clients (if any).
- Improved settings copying efficiency. When using a configuration with very many (hundreds or thousands of) account or group settings entries, settings should now occupy less memory and cause less delay when establishing new SSH sessions.
Changes in WinSSHD 4.12: [ 15 January 2006 ]
- Security fixes:
- When the WinSSHD installer created the WinSSHD installation directory, its security descriptor would be inherited from the parent directory. In the most common case, when WinSSHD was installed under 'C:\Program Files', this would result in the Power Users group on desktops, or the Server Operators group on servers, receiving write access to WinSSHD.exe. A member of these groups could exploit this for privilege escalation. The installer now creates the WinSSHD installation directory with a security descriptor which grants write access to local administrators and the Local System account only. The security descriptor is also set this way during an upgrade unless the DACL has been changed (contains non-inherited ACEs).
- WinSSHD would register itself as an 'interactive' service in order to be able to display a message box when evaluation was about to expire or when a rare type of critical failure occurred. Such message boxes always closed after 10 seconds, but while one was displayed, a skilled but unprivileged local user could exploit it for privilege escalation. WinSSHD is now not registered as an interactive service and does not display message boxes when running as service. When evaluation expires or is about to expire, a separate program without privileges launches the WinSSHD Control Panel when an administrator logs in.
- WinSSHD Settings improvements:
- It is now possible to create a new list entry by copying an existing one.
- Lists now include additional columns containing summaries for some of the entries' sub-entities such as passwords (set or not set) and lists of public keys (number of keys).
- Other fixes:
- When upgrading from version 3.xx, the Initial Directory, Terminal Shell, and SFTP Root Directory settings weren't being decoded properly - if any was set, the corresponding 'Use default' setting would not be disabled.
- A call to CreateEnvironmentBlock() could fail on NT4 when use in a way not supported on NT4. The session would be terminated when this happened.
Changes in WinSSHD 4.11: [ 12 December 2005 ]
- WinSSHD was making it possible for someone with ability to connect to the server, but without the ability to authenticate, to find out if a specific username is valid by looking at user authentication failure response timing. To prevent this, user authentication failure responses are now delayed for the configured login attempt delay interval.
- Added support for 'localhost' and '' (empty string) as listening interface in a server-to-client port forwarding request (introduced by recent SSH2 protocol improvements; eases interoperability with newer versions of OpenSSH).
- The SFTP server module now gracefully ignores common Windows pipe exceptions on termination; previously logged unnecessary errors.
- WinSSHD would fail on Windows NT4 running on Intel processors with SSE2 capability. Windows NT4 does not support this capability, and WinSSHD was checking only for the processor feature and not also for operating system support. Fixed.
- Errors from the LogonUser() API function were being logged incorrectly when tracing was enabled. Fixed.
Changes in WinSSHD 4.10: [ 24 November 2005 ]
- Added multi-site support. Multiple WinSSHD installations can now coexist by installing additional installations in directories of the form 'WinSSHD-SiteName'.
- The uninstaller interface can now be automated from the command line. When upgrading, the installer will now smoothly uninstall the previous version without additional clicks.
- Halved the size of the distributable due to a better compression scheme and size optimizations in the installer.
- Added description fields to the various kinds of accept rules and port forwarding rules that can be configured in WinSSHD Settings.
- Fixed incorrect criterion for enabling the 'Do not load profile' setting in on-logon and on-logoff command settings.
- User friendliness improvements to the WinSSHD Settings utility.
- The terminal servers now support screen buffer switching (e.g. when using 'telnet').
- Negotiated encryption, MAC and compression algorithms can now be logged by enabling the SESSION_ALGORITHMS trace log message.
Changes in WinSSHD 4.06a: [ 02 October 2005 ]
- Users do not any more need read access to the parent of the SFTP Root Directory.
- End-User License Agreement overhauled.
Changes in WinSSHD 4.06: [ 24 September 2005 ]
- Fixed a resource leak in the VT-100/xterm terminal server module (toterm.exe) which caused the Windows CSRSS.exe process to start leaking memory as VT-100 or xterm sessions were kept open for prolonged periods of time. Bvterm sessions (using Tunnelier) were unaffected.
- Improved online help in WinSSHD Settings. There is now more help text which appears in more places that need it.
Changes in WinSSHD 4.05: [ 13 September 2005 ]
- Fixed a resource leak which led to decreased server performance over time, especially at sites making heavy use of port forwarding. Upgrade encouraged. All activation codes valid for previous 4.xx versions will work with 4.05 regardless of upgrade expiration.
- User interface improvements to WinSSHD Settings under low resolutions and non-standard contrast settings.
Changes in WinSSHD 4.03a: [ 11 August 2005 ]
- Windows NT4 has a quirk in domain name SID lookup which led to failed logins into NT4 local accounts. WinSSHD now recognizes this quirk to enable local NT4 accounts to work as expected.
Changes in WinSSHD 4.03: [ 05 August 2005 ]
- Implemented configurable domain order for user account lookup when the login username is not explicitly qualified.
- Groups are now looked up and matched based on SIDs, not names.
- Logon type (network or interactive) is now configurable. Windows group entries now default to interactive logon; virtual group entries now default to network logon.
- Fixed password pasting problem in WinSSHD Settings.
- Fixed incorrect display of GUI elements in WinSSHD Settings on computers using a non-default display DPI setting.
- Fixed handle leak when logging in under an administrator account.
- Improvements to toterm.exe error reporting (on failure launching a child process, now reports the error code).
- Implemented support for tracing the user authentication process to help with error diagnosis.
Changes in WinSSHD 4.02: [ 11 July 2005 ]
- When picking an initial directory for when a user's profile has not yet been created, WinSSHD 4.01 would select the 'Default User' profile directory. Now, the 'All Users' directory is selected on Windows 2000, XP, and 2003, and the parent directory is used on NT4.
- Added the Microsoft Firewall LSP to the list of supported Windows Sockets 2 Layered Service Providers. Port forwarding will now work correctly on machines relying on this LSP for cross-firewall connectivity.
- Minor WinSSHD Settings graphical user interface improvements.
- WinsshdCfgManip.idl was being incorrectly installed as WinsshdCfgManipIdl.dll. Fixed.
- When returning a directory listing, the SFTP protocol represents file timestamps in two fields: a primary field with high fidelity, and a lower-fidelity secondary field that is part of a more human-readable Unix-type listing. WinSSHD would encode the correct file modification time in the primary, high-fidelity field, but would encode an incorrect time in the secondary field. Most SFTP clients would still display the right file modification time, except clients like Directory Opus which rely on the human-readable lower-fidelity field instead of the higher-fidelity one intended for use by programs. Fixed.
- When using log file rollover by time and when the configured rollover base hour was not divisible by the repeat time hours, WinSSHD would not start. Fixed.
Changes in WinSSHD 4.01: [ 30 June 2005 ]
- New features:
- Now supports GSSAPI/SSPI key exchange and host authentication with Kerberos 5.
- Now supports GSSAPI/SSPI user authentication with NTLM and Kerberos 5.
- Now supports multiple virtual accounts with different WinSSHD settings, backed by a single (local or domain) Windows account.
- Now supports Windows group-based configuration, automatically applying group-wide settings if no account-specific WinSSHD settings are defined.
- Ability to accept connections on multiple ports and interfaces simultaneously.
- More reliable text file logging with automatic rollover capability based on file size or time of day.
- Ability to manage the WinSSHD password cache from the WinSSHD Control Panel, and also remotely through the Remote Control Panel in Tunnelier.
- Supports password change during user authentication using clients that support it (e.g. Tunnelier from version 4).
- All-new graphical WinSSHD Settings:
- Immediately accessible help text for each configurable item.
- Makes available for visual configuration many settings previously only configurable textually through wcfg.
- Blends visual and script configuration into a single interface: view settings graphically in Configuration tab, query using wcfg script language in Query.
- SSH improvements:
- Now uses explicitly the Microsoft Windows Sockets 2 Layered Service Provider (LSP) to avoid compatibility issues with poorly written third-party LSPs. This seems to solve reported compatibility issues with NOD32, PGP version 9 and other software that installs a badly written LSP.
- Improved socket EOF handling in some cases.
- Implemented graceful handling of data received after EOF, for compatibility with poorly written clients.
- To avoid a disconnect, active keep-alives are now not sent during user authentication - passive keep-alives are sent instead.
- Additionally, a number of non-Bitvise clients misbehave and disconnect when receiving an active keep-alive, so WinSSHD now sends only passive keep-alives to non-Bitvise clients.
- Fixed data packet sending to respect the maximum size that the remote party specifies.