VanDyke Software

Upgrading VShell® for Windows®

Index

Upgrading VShell for Windows

There are two scenarios in which you may be upgrading VShell:

  1. You are upgrading VShell in place on the same server
  2. You are upgrading VShell and moving it to a different server

This tip discusses both of these situations.

Upgrading VShell in place on the same server

If you are upgrading VShell and do not intend to move the installation to a different computer, then the upgrade process is simple:

  1. Back up your VShell configuration.
  2. Run the new VShell installer.

Back up your VShell configuration

We do not anticipate that you will experience any problems during your upgrade.  However, it is best to be on the safe side in case anything should go wrong (for example, if your hard drive was to fail in the midst of the upgrade).  For this reason, you should always export your VShell  configuration to an XML file.  Then, in an emergency, you will be able to re-create the earlier VShell configuration. 

See the VShell Tip on How to Export and Import the VShell  Configuration for details.

Run the VShell installer

The VShell installer icon (on a dark desktop)
  1. Double-click on the VShell Installer icon to start the installer. 
  2. Respond to the prompts, which should be self-explanatory.  
  3. At the end, you will be prompted to reboot your computer.  You must restart your computer before the LSA Authentication module, which provides support for public-key authentication, can be used.  If your VShell configuration will not use public-key authentication to allow clients to connect, you can postpone the reboot until later.

Upgrading VShell and moving it to a different server

Instructions are provided in the VShell Tip on Moving VShell to a Different Server.

+ Special considerations if upgrading from 3.5 to 4.1 (and newer)

In May 2015 a potential vulnerability with SSH key exchange was discovered.  This vulnerability, similar to the Logjam attack, could allow a man-in-the middle attack during a Diffie-Hellman key exchange.   See  https://weakdh.org  for details.

To address this vulnerability, as of VShell version 4.1.1, the Diffie-Hellman key exchange method was disabled by default, and all 1024-bit primes were removed from VShell's primes.txt file.

Upgrading from VShell 3.5.x to VShell 4.1.x (and newer) will introduce potential compatibility issues with older SSH2/SFTP clients that do not support any key exchange algorithms newer/stronger than Diffie-Hellman (or Diffie-Hellman group with a prime larger than 1024 bits).

Because of this research, Diffie-Hellman can largely be considered as weak/deprecated much the same way as 3DES and MD5 are now considered weak/deprecated.

Wherever possible, it is strongly advised to upgrade client applications to a version that can support newer, stronger, larger-than-1024-bit primes for Diffie-Hellman group key exchange.

If your client(s) cannot be upgraded, and cannot be configured to perform Diffie-Hellman group exchange with anything larger than a 1024-bit prime, contact support@vandyke.com for assistance to restore support for these deprecated methods.