VShell(R) Server 4.3 (Beta) -- July 27, 2017 Copyright (C) 1995-2017 VanDyke Software, Inc. All rights reserved. This file contains a VShell product history. It includes lists of new features, changes, and bug fixes sorted by release. For a product description, installation notes, registration, and contact information, please refer to readme.txt (downloaded with this package). Changes in VShell 4.3 (Beta 3) -- July 27, 2017 ----------------------------------------------- Changes: - VShell now logs disconnect messages received from clients as informational instead of as errors. - UNIX: Changed the VShell installers to no longer explicitly create the directories where the VShell files will be placed. If the directories do not exist, they will be implicitly created as part of the file copy. This addresses an issue on rpm based platforms (RHEL, CentOS, Suse) in which VShell would be listed as the package owner of these system directories. Bug fixes: - Windows: The "Use single virtual root" option was not being honored when set via a subconfiguration and the user's virtual root had the home checkbox selected. Changes in VShell 4.3 (Beta 2) -- July 6, 2017 ---------------------------------------------- New features: - Windows: Added support for multiple backup LDAP servers. If a configured LDAP server is down, VShell will automatically fall back to the next enabled LDAP server. The fall back behavior will only happen when an LDAP server is unreachable. - Windows: Added an option to control whether VShell will automatically accept and save an SSL certificate sent by an LDAP server. Changes: - Windows: The base64 encoded SHA-2 fingerprint is now displayed for all host keys on the VShell Control Panel Host Keys page. - Windows: Added an option that prevents VShell's management provider (WMI) from logging to the Windows Event log. The WMI logging is used for debugging purposes only, so the logging is disabled by default. Bug fixes: - VShell could crash under some circumstances if the deny hosts file in use had the wrong file permissions. - Windows: When the "Attempt Interactive Logon" registry only option was disabled, subconfiguration files were not loaded for users from the internal user database. - VShell FTPS was not sending the correct file size for files larger than 4GB when the client used the LIST command for directory listings. Changes in VShell 4.3 (Beta 1) -- May 18, 2017 ---------------------------------------------- New features: - Windows: Added support for user authentication via an external LDAP server. LDAP users can be granted or denied access to all VShell services, including all file transfer, shell, port forwarding, and remote execute. - Windows: Streamlined the process of setting up public-key authentication by adding a new interface that allows the administrator to easily view, add, and remove user public keys stored on the server. - Added support for the firstname.lastname@example.org authenticated encryption cipher. - Windows: Added an option to limit the total number of concurrent connections allowed to the server. - Windows: Added a registry only option that allows the administrator to control whether VShell will attempt an interactive logon (Logon Type 2) before a network logon (Logon Type 3). If the option is disabled, VShell will only attempt a network logon. - Windows: The VShell Control Panel Host Keys page now displays the SHA-2 fingerprint of each host key. - UNIX: File and folder access permissions can now be set on a per user, per virtual root basis. Permissions include file read, write, delete, and folder list, create, and delete. - UNIX: The virtual root a connecting user is initially placed in can now be specified. This is useful for users with access to multiple virtual roots with a need to land in a specific one. - Support added for Windows Server 2016. - Support added for Ubuntu 16. Changes: - Windows: VShell now performs public-key assistant operations (add, delete, list) in the context of the VShell service account (SYSTEM by default). This avoids needing to set permissions on the public-key folder that could end up being too permissive. - Windows: The VShell configuration key is now stored in the registry instead of a file to allow for more cluster-friendly operation. - Windows: The default filename displayed on the host key generation dialog now includes the host key algorithm as part of the name. - Windows: When adding or editing a virtual root, any forward slashes that appear in the path are now automatically replaced with backslashes. This is to fix an issue where forward slashes were allowed to be entered in the path, but would fail when VShell attempted to resolve the path when a user connected. - Windows: On the VShell Control Panel Email Server page, increased the space used to display results from sending a test email. - Windows: Internal user database users that are specified in a Deny Users file are now denied immediately upon connecting. Previously, these users would be allowed to go through the authentication process before being denied. - VShell FTPS now ignores invalid flags that a client may include as part of a LIST command. Bug fixes: - Windows: Shell connections to VShell running on Windows Server 2016 would sporadically fail with a ReadConsoleOutput error. - Windows: Unexpected failures could occur if an internal user database file was specified as part of a location subconfiguration. - Windows: After upgrading from VShell version 2.6 or earlier to version 3.8 or later, access to virtual roots failed due to incorrect file and folder access permissions. - Windows: When using the Apply button in the VShell Control Panel to save changes, all options were written out to the registry whether they had been changed or not. - VShell could crash when attempting to add an IP address to a deny hosts file that did not have the correct permissions. - VShell FTPS could crash if a user disconnected at the same time the connection was closed by the server due to an idle timeout. - Large file downloads by certain SFTP clients could fail with an insufficient resources error. Added a registry only option ("SFTP Send Queue Byte Limit") that allows administrators to fine tune VShell's allowance for consecutive read requests. - UNIX: VShell would errantly log a "Lookup failed for child" error after a trigger operation completed.