VShell(R) Server 5.0 (Beta 1) -- January 15, 2026 Copyright (C) 1995-2026 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 5.0 (Beta 1) -- January 15, 2026 -------------------------------------------------- New features: - Added two new trigger types that fire when uploads and downloads fail. - A new option, subconfigurable by location, allows specification of the host key algorithms that VShell will offer to clients. - SSH2: Added support for the diffie-hellman-group15-sha512 and diffie-hellman-group17-sha512 key-exchange algorithms. - SSH2: A new option allows restriction of the algorithms accepted for public-key authentication. With this feature, a new Public Key Options page was created in the VShell Control Panel for all public-key related options. - SSH2: A new option allows configuration of the minimum bit size for RSA public keys. - SSH2: Added pseudo terminal (PTY) support. - SSH2: To assist when informing end users of the need to verify new host keys before accepting them, a new button copies the fingerprints of all configured host keys to the clipboard. - Windows: Added a new trigger type that fires every time an authentication attempt fails. - Windows: A new trigger condition allows a trigger to fire only when a file or folder name matches the specified pattern. - Windows: Subconfiguration XML files can now be generated from the VShell Control Panel. - Windows: A new button on the VShell Control Panel lets you run a set of checks to validate the current VShell configuration. Changes: - At login, no single virtual root will block other virtual roots from being resolved. This results in improved responsiveness when one or more roots are slower than the others to resolve. - The default debug level for logging is now 5. - Session channel failing unsupported request messages are now logged only at debug level 3. - SSH2: The maximum value of the "Session Channel Maximum Packet" option is now 256K. - FTPS, HTTPS: A warning is now logged when a *.crt or *.cer file is loaded that does not have a public key matching the configured *.pfx file's private key. - FTPS, HTTPS: TLS versions 1.0 and 1.1 are now disabled by default. - HTTPS: Modified the HTTPS response headers so that Content- Security-Policy no longer includes 'unsafe-inline' for "default-src". - HTTPS: Added a new option, "HTTPS Enable OPTIONS". When enabled, requests of the OPTIONS method are allowed; when disabled, a "403 Forbidden" response status code is returned. - HTTPS: Modified the HTTPS response headers as follows: + Deleted X-XSS-Protection + Deleted X-Frame-Options + Changed Content-Security-Policy to "default-src 'self' 'unsafe-inline'; script-src 'self' 'unsafe-inline'; img-src 'self'; connect-src 'self'; frame-ancestors 'none'; upgrade-insecure-requests" + Added Referrer-Policy set to "no-referrer" + Added Permissions-Policy set to "bluetooth=(), camera=(), display-capture=(), microphone=()" - Windows: During public key authentication, if Kerberos Protocol Transition (KPT) failed due to the connecting user not having a UPN formatted name configured, VShell would not try KPT for subsequent authentication attempts by that user until VShell was restarted. - Windows: When the size of the Access Control List is reached and no more entries can be added, the message displayed now explicitly states the issue. - Windows: When a Virtual Root is added or edited, and no users or groups have been granted access to it, a prompt to add users or groups is displayed. - Windows: For SFTP Virtual Roots, VShell now logs the messages sent between VShell and the remote SFTP server when files are transferred. - Windows: VShellConfig now requires a non-blank passphrase when exporting a configuration that contains saved credentials. - Windows: When the VShell configuration is exported, the resulting XML file now contains the version information. - Windows: When importing or exporting the configuration, the resulting log file now includes the version and all arguments of the command executed to perform the import or export. - Windows: When the Help button on the VShell Control Panel is pressed, the help page displayed is now the one for the currently selected Category. - Windows: SSH2: When managing public keys for user authentication, the bit size of the keys is now displayed. - Windows: FTPS, HTTPS: In the VShell Control Panel, the SHA-1 thumbprint is no longer shown on the Listen Addresses pages. Bug fixes: - When a login trigger was configured with an Email action to fire for all users, and a large number of users logged in at or near the same time, VShell could crash. - When file types were disallowed using the "Restrict File Types" option, VShell would still allow a file to be renamed or copied using the restricted file extension. - When using newer versions of OpenSSH's scp client to recursively upload a directory structure to VShell, the upload may have failed if the base directory name did not already exist on the remote host. - Authentication settings specified in a subconfiguration would not take effect when VShell was used with an evaluation license. - If a user had access to a virtual root but the virtual root folder was inaccessible, a misleading error would be logged stating the user did not have any virtual roots specified. - FTPS: When an FTPS file transfer client disconnected from the server normally, VShell may have incorrectly logged the message "The specified network name is no longer available". - FTPS: When an FTPS client disconnected from the server, VShell may have unexpectedly logged a "426 Connection closed; transfer aborted" error. - HTTPS: When accessing VShell via the HTTPS User Web Interface and the full path to a file was specified as part of the URL, the file may have been opened by the browser instead of downloaded. - HTTPS: With Single Sign On (SSO), if a login error occurred, the standard login page could appear behind the error dialog. - HTTPS: VShell could leak memory when it closed HTTPS connections, and when it performed a directory listing in response to a PROPFIND request. - HTTPS: When an HTTPS file transfer client disconnected from the server normally, VShell may have incorrectly logged the message "Received illegal SSL shutdown from the client". - HTTPS: When uploading a folder structure with a filename that matched a character sequence in the parent folder, the folder would have been created with the incorrect name. - Windows: If RADIUS authentication was disabled while a client was attempting to authenticate using that method, VShell could crash. - Windows: If an empty file was specified for a subconfiguration, VShell could crash when the file was loaded. - Windows: The VShell control panel could crash when attempting to read an invalid certificate placed in a user's public key folder. - Windows: When a configuration was imported that included an SFTP virtual root configured with password authentication, the PublicKey authentication method may have been unexpectedly enabled after the import. - Windows: Edited LDAP users would be displayed with the old username in the VShell Control Panel. - Windows: If a client specified a UPN formatted username (i.e., user@domain) that the remote system was unable to translate, VShell would use an empty username for logging and authentication. - Windows: When a "Send email" or "SFTP Transfer" trigger action was executed and the option to allow the action time to complete was enabled, an "OnRead: The pipe has been ended" message may have been logged. - Windows: When exporting the configuration, the evaluation license may have been unexpectedly included in the export. - Windows: If a user's public key folder contained unusually large files, a configuration export could appear to hang while those files were being processed. - Windows: If a client sent xterm-256color for the terminal type, TTY mode would be unexpectedly used. - Windows: When multiple instances of VShell's "who" utility were run in parallel, some instances may not have reported their open connections correctly. - Windows: When the license in place has expired and an older evaluation license key existed in the registry, VShell may not have run using a new evaluation license as expected. - Windows: When a remote SFTP virtual root was accessed via an HTTPS or FTPS connection, the connection from VShell to the remote SFTP virtual root target may have been left open after the client disconnected. - Windows: When the Deny Host feature was enabled and multiple authentication attempts from the same host failed simultaneously, the host's IP address could have been duplicated in the deny host file. - Linux, macOS: If the subconfiguration file path specified as part of the SubconfigurationNetworkMap option included any spaces before the path, the subconfiguration would not have been loaded. - Linux: When a user with an expired password connected to VShell, the prompt indicating a password change was required would have been displayed 3 times. - Mac: On certain macOS operating systems, connecting to VShell using keyboard-interactive authentication may have resulted in the vshelld child process crashing.