SecureCRT® FAQ

Select by category

Yes, in most cases. SecureCRT and SecureFX® are available for export under U.S. Bureau of Industry and Security regulations governing strong encryption software. Import restrictions by other countries may also affect encryption software availability. For more information, please see our web page on Exporting Encryption Software.

What is the upgrade process?

SecureCRT is designed to be installed directly in place of prior versions, so you only need to download the installer, and then run it. There is no need to uninstall the older version prior to installing the newer one since in most cases the new version will automatically uninstall the old version for you. Cases where an older version may not be removed involve upgrading from very old versions of SecureCRT (5.5.4 and older) to newer versions of SecureCRT.

How do I keep my settings?

Default SecureCRT installations do not change, alter, remove, or otherwise put in jeopardy your existing sessions/settings. However, if your organization has deployed SecureCRT initially using a customized installation, you will need to seek assistance from your organization's deployment team in determining the expected behavior of an upgrade installation.

Is there a quick way to find out if I am eligible for an update?

Yes. Please visit the the Updates Policy page for more information.

How much does it cost?

Depending on the option chosen at the time of your license purchase, SecureCRT licenses include either 1 or 3 years of access to product updates and technical support. In SecureCRT versions 6.1 and newer, you can determine when the eligibility timeframe for your existing license expires by clicking on the main Help pull-down menu and choosing the About SecureCRT... menu item. If you are running SecureCRT on the macOS platform, the "about" dialog is available within the main SecureCRT pull-down menu. For more information or if you have an older version of SecureCRT, please see the Updates Policy page. If your license is not eligible for a free update, but you are interested in renewing your license, you can review upgrade pricing information and purchase online, or contact us.

SecureCRT does not have a "timeout" feature which automatically disconnect sessions. However, many servers disconnect idle sessions after a period of inactivity. Inactivity is sometimes defined by a server as no information received from the client, so it may timeout even if new data is continuously being displayed in the SecureCRT window. If you see a disconnect occur after a period of time elapses without any user input activity, the disconnect is being initiated by an idle timeout setting on the remote system or on a firewall/router/VPN server that resides somewhere in the network stack/path between SecureCRT and the remote system.

Why doesn't this happen to other applications like my web browser?

Other applications like web browsers can transparently retry failed communications because they do not have to maintain an open connection. This level of transparency is not available when SSH (or Telnet, etc.) sessions are disconnected by an idle timeout on a remote server or a firewall/router/VPN server.

Is there anything that can be done to prevent a connection from closing?

If you find your sessions being disconnected after a certain period of inactivity, you can take advantage of anti-idle features in SecureCRT to try and keep connections open for longer periods of time. You can find two anti-idle options in the Session Options / Terminal category: Send protocol NO-OP and Send string.

The Send protocol NO-OP option is available when using the SSH2 or the Telnet protocol. It sends data at the TCP protocol level and does not send any data to the remote which would be displayed. The Send protocol NO OP option is the suggested mechanism for anti-idle since it will typically not interfere with applications running on the remote system.

The Send string option simulates an actual key-press, so the data to send is sent to the remote and will be displayed (possibly interfering with an application running on the remote system). Since sending a key-press might have unintended consequences, the data to send should be chosen carefully. Simulating a space and backspace may be an optimal solution for many environments. To send space and backspace, enter " \b" (without quotes) in the Send string entry box.

Why does the SecureCRT window or tab close when I lose my connection?

SecureCRT provides an option that allows for automatically closing a window or a tab when the connection within it is closed. This option is not enabled by default, so if you're seeing this behavior, it's likely that you've enabled it (or it was enabled by whomever created the configuration files your installation of SecureCRT is using).

If you wish to keep the SecureCRT Window/tab open when the connection within the window/tab closes, you'll need to reset the option back to its default setting:

  1. Open the Session Options dialog.
  2. Select the Terminal category, and locate the Close on disconnect option.
  3. Ensure the Close on disconnect option is not enabled.
  4. Close the Session Options dialog to save your settings.

The SSH protocol has two generations: SSH, the initial draft protocol dating to 1995, which is now labeled SSH1, and SSH version 2, usually called SSH2, which was first published in 1998. SSH2, the current version of the Secure Shell protocol, was developed under the Internet Engineering Task Force (IETF) Secsh working group.

SSH1 was developed through 1998, when the technical focus on security issues and optimization shifted to SSH2. The SSH2 protocol was a complete reconception of the protocol and is intended to remove limitations in SSH1, such as the absence of message authentication codes (MACs). The SSH1 draft documentation is not part of the IETF process and does not match the current SSH1 server implementations. SSH1 has a significant installed base, particularly among early adopters of Secure Shell, and has a more open server licensing for some organizations. However, the maturity and improved security of SSH2 make it VanDyke Software's preferred protocol.

VanDyke Software believes that SSH2 is the current best choice protocol. Revised from the ground up, SSH2 has many architectural and practical improvements over SSH1, including addressing potential security flaws. The most immediate advantage to SSH2 is that port forwarding multiple channels is faster and more reliable. One channel can no longer consume all available bandwidth and slow other channels or sessions to a crawl, as in SSH1. SSH2 is also the protocol where new development effort at several companies is being focused, whether OS support for new platforms or in extending SSH2's capabilities. Security concerns specifically are best addressed in the SSH2 protocol.

Organizations that used SSH1 servers for licensing reasons now have a choice of alternative SSH2-based solutions. VanDyke Software offers VShell® SSH2 servers for both Windows and popular UNIX platforms. The OpenSSH server project undertaken by OpenBSD developers also supports SSH2, and is available under a freeware license for OpenBSD and other UNIX / Linux operating systems.

Note: This information applies to SecureCRT for Windows®.

The following steps will help you get VNC running over VShell. These steps assume that you are using SecureCRT as your port-forwarding client.

On the VShell/VNC server:

  1. In the VNC interface, set the following parameters:
    1. Check the Accept Socket Connections check box.
    2. Set "Display number" to "02" (this will configure the server to listen on port 5902).
    3. Set the password.

    Note: Setting "Display number" directly to "5902" may cause an error with the client.

  2. Create the following Registry entry:

    AllowLoopBack REG_DWORD "1"

    (hex) under the following key:


  3. Restart the VNC service.

In your SecureCRT client:

  1. Select File / Connect... to open the Session Manager.
  2. Click on the New Session button and configure a SSH2 session that connects to the VShell/VNC server.
  3. Select the Connections / Port Forwarding category and press the Add button.
  4. Create a port forward entry with the following settings:
    1. Name: VNC (or whatever name is meaningful to you)
    2. Local Port: 5902
    3. Remote Port: 5902
    4. Clear the Destination host is different for the SSH server check box.
  5. Click on the OK button until you are back at the Session Manager and then click on the Connect button to initiate your new session.

In your VNCViewer:

  1. Enter "localhost:02" in the Connection details dialog.

The likely cause of this behavior is that when you attempt to change the session colors, you are actually changing the foreground and background color values for one of the globally defined color schemes.

To have each session use a different combination of foreground and background colors, you will need to create a color scheme for each color combination you wish to use.

For example, if "Session1" is using a custom color scheme named "blue-black" and you want another session to have a red foreground and a black background, you would create a new color scheme (e.g., named "red-black") and have Session2 use that color scheme.

The problem you are experiencing is that RedHat by default uses UTF-8 to encode its output. Either the version of SecureCRT® that you are using does not support UTF-8 encoded output, or the output encoding is not set to UTF-8 for the session in use.

The following are three possible solutions to this problem:

Solution 1: Enable UTF-8 output encoding for the session in use

If you are using a version of SecureCRT prior to 4.0.1, you will need to update your version. This may be a free upgrade for you depending on when you purchased your SecureCRT license. Please check the Upgrades Pricing page on the VanDyke website to determine if you qualify.

To enable UTF-8 encoding for a session in SecureCRT 5.0, go to the Session Options dialog. In the Terminal/Appearance category, set the Character encoding in the Fonts group to "UTF-8".

To enable UTF-8 encoding for a session in SecureCRT 4.0.1 through 4.1.x, go to the Session Options dialog. In the Emulation/Advanced category, set the Output entry in the Character encoding group to "UTF-8".

Solution 2: Turn off UTF-8 encoding for your user on the RedHat machine

In your .bash_profile, add the following lines (this is for the bash shell; if you are using a different shell, the settings may be slightly different):


Note: The above commands use en_US as an example; other languages can also be used.

Solution 3: Turn off UTF-8 encoding system wide on the RedHat machine (Note: This solution requires that you have root access.)

In the file /etc/sysconfig/i18n there is a line that reads:


Change the line to read:


Note: The above commands use en_US as an example; other languages can also be used.

Note: This tip is for use with SecureCRT® for Windows®.

  1. If you have SecureCRT 5.5 or later, open the Global Options dialog and navigate to the Web Browser category.
  2. Click the Make SecureCRT Your Default SSH2 Application button.

If you want to open connections in tabs, you will need to edit the registry value as noted below:

WARNING: If you use the registry editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Before making changes to the registry, you should back up any valued data on your computer.

  1. Open regedit and navigate to HKEY_CLASSES_ROOT\ssh
  2. Change registry value from:

"C:\Program Files\VanDyke Software\Clients\SecureCRT.EXE" %1"


"C:\Program Files\VanDyke Software\Clients\SecureCRT.EXE" /T %1

You will now be able to start SecureCRT from your web browser by typing "ssh2://<hostname>" or by inserting that link in a web page.

Changing the following settings should improve the emulation when the remote machine is running SCO OpenServer 5.0.6 or later:

  1. On the SecureCRT® Session Options dialog, Emulation category, select "SCOANSI" as the Terminal emulation. The SCOANSI emulation should be used with any SCO server. Also, ensure that the rows and column settings are appropriate. SCO applications generally prefer 25x80.
  2. On the Session Options dialog, Emulation/Advanced category, check the Terminal type check box and enter "ansi" in the associated text box. This will send "ansi" instead of "scoansi" when you connect. In SCO OpenServer 5.0.6 and later, "scoansi" is no longer mapped to "ansi", and so "ansi" must be specified manually.
  3. In versions of SecureCRT prior to 4.1, the Terminal font works best. On the Session Options dialog, Appearance category, select Terminal as the Normal font. Make sure that the Character encoding option is set to "Default" in the Emulation/Advanced category.
  4. In SecureCRT 4.1 and later, use the Terminal font by selecting "Terminal" as the "Normal font" on the Session Options dialog, Appearance category. Make sure that Character encoding is set to "Default" in the same category.

    It is also possible to use a TrueType Windows font. To do this, on the Session Options dialog, Appearance category, select a TrueType Windows font such as Courier New or Lucida Console and set "Character encoding" to OEM.
  5. Finally, on the remote machine, make sure the TERM environment variable is set to "ansi".

Note: This tip is for use with SecureCRT® for Windows®.

If you cannot hear beep sounds when SecureCRT receives BELL characters while connected to a remote system, the first step is to make sure that your SecureCRT session is configured to play the beep sounds:

  1. From the SecureCRT Options menu, select Session Options.
  2. In the Terminal category of the Session Options dialog, verify that the Audio bell option is enabled.
  3. If you still cannot hear beep sounds, the next step is to check the system audio settings.

  4. From your system's Start menu, select Control Panel.
  5. Open the Sounds and Multimedia applet. In Windows XP, this is called Sounds, Speech, and Audio Devices and then you will have to select Sounds and Audio Devices.
  6. Select the Sounds tab on the Sounds and Audio Devices dialog.
  7. Make sure that the Windows/Default Beep event is set to something other than "(None)". You can test this setting by pressing the "Play" button (the button with the right-facing arrow next to the "Sounds" field).
  8. If the "Play" button is grayed-out or you can't hear a sound when you press it, then you probably need to install or repair your system's sound drivers.

If the system audio setting appears to be correct and you still do not hear beep sounds in SecureCRT, it may be due to a registry setting made by Tweak UI, which is an optional utility application from Microsoft.

  1. From the Start menu, select Control Panel.

  2. If you see Tweak UI on the list of Control Panel applets, open it and verify that the Beep on errors option on its General tab is enabled. If you change this setting, you may need to reboot in order for it to take effect.

If you still cannot hear beep sounds, please contact VanDyke Software technical support at

If you are having problems getting color scheme settings to work, you may need to uncheck the ANSI Color option on the Emulation page in the Session Options dialog. The ANSI Color option will override any color scheme defined in the Appearance/Color Schemes page in the Global Options dialog.

For more tips, see our Overview of Color Configuration in SecureCRT.

SecureCRT has filters that control who can connect to port forwards that have been set up in SecureCRT. By default, only connections coming from the machine that SecureCRT is running on can connect to the port forwards.

You can change the port-forward filters by following the steps below.

  1. If SecureCRT is running, exit the program before continuing.
  2. Find the .ini file associated with the session that you want to modify. The .ini files are located in the SecureCRT Config folder under the subfolder called Sessions. The Global Options dialog also displays the location of the SecureCRT Config folder in the Configuration folder field.

  3. Open the .ini file in Notepad.
  4. Look for the following line:

    S:"Port Forward Filter"=allow,,0 deny,,0
  5. Modify the line to read as follows:

    S:"Port Forward Filter"=allow,,0 allow,,0 deny,,0

    Alternately, you could modify the line to read as follows allowing any IP address to connect to the port forward:

    S:"Port Forward Filter"=allow,,0

The instructions below describe how to move your sessions and settings to other machines and/or platforms. SecureCRT 7.3 and newer includes an import/export tool that makes it easier to create a backup or copy SecureCRT settings from one machine to another.

SecureCRT 7.3 and newer

  1. Install SecureCRT on the destination machine.
  2. On the source machine, run SecureCRT and select Export Settings from the Tools menu. Choose the folder location and specify a name for the XML file that will be created (e.g., SCRTConfig.xml).
  3. Copy the file created in Step 2 to the destination machine.
  4. On the destination machine, run SecureCRT and select Import Settings from the Tools menu.
  5. In the Import from file box, select the XML file from Step 3.

Note: If the configuration is set up to use a personal data folder, sensitive data such as usernames, passwords, and automated logon information will not be copied. If you would like everything to be copied, you will need to temporarily revert back to a single configuration folder. The Personal Config Data: 3) Reverting Back to a Single Config Folder Video on the VanDyke Software YouTube Channel shows how to do this or you can contact technical support for assistance.

SecureCRT 7.2 and earlier

Note: This information is specific to copying the entire session database from an old machine to a new machine. If you have created sessions on the new machine that you didn’t have on the old machine, the new sessions will be deleted. A number of paths (host key database, download/upload folder, etc.) are platform-specific, and may need to be modified after copying a configuration from one platform to another.

  1. Install SecureCRT on the destination computer.
  2. On the destination computer, open the SecureCRT Global Options dialog, select the General category, and note the Configuration folder location.
  3. On the source computer, open the Global Options dialog, select the General category, and note the Configuration folder location. The Configuration folder is set the first time SecureCRT is run after installation.
  4. Close all instances of SecureCRT on both the source and the destination computers.
  5. Copy the contents (including sub-folders) of the Configuration folder on the source computer to the Configuration folder on the destination computer.

Most session and setting information is used the same way on both platforms. These are some settings which are not.

  • For fonts, the default font is used (fonts are not guaranteed to exist on all platforms).
  • Serial port definitions may need to be modified.
  • Local folder locations may need to be modified. These may include host key database, identity, download, logging, logon scripts, and scripts associated with mapped keys or buttons.
  • Custom menus and toolbars are currently only supported on Windows.
  • Rlogin, TAPI, and Telnet/SSL connection protocols are currently only supported on Windows.

SecureCRT licenses are not currently platform-specific, but the license usage restrictions set forth in section three (3) of the End User License Agreement still apply:

3. USE AND EVALUATION PERIOD. You may use one copy of this Software on one client computer. For the purposes of this agreement, "computer" means a physical device or a virtual machine. A copy of this Software is considered "in use" when loaded into main memory (i.e., RAM). You may also use a copy of the Software on one additional computer, provided you make certain only one copy of the Software is "in use" at a time. You may use an evaluation copy of the Software for only thirty (30) days in order to determine whether to purchase the Software.

If SecureCRT is only running on one machine at any given time, then a SecureCRT license can legally be used to register SecureCRT on one (1) secondary Windows/Mac/Linux machine.

However, if SecureCRT needs to be running on multiple machines at the same time ever, a separate SecureCRT license must be purchased for each machine (regardless of OS platform).

Note: This usage policy is governed by the current license agreement for SecureCRT and is subject to change in future releases of SecureCRT.

If you need to purchase an additional SecureCRT license to run concurrently on a different machine, go to the Purchase page.

The older version of SecureCRT you are running is not designed for use on macOS Monterey 12.x. Since versions of SecureCRT prior to v9.2 are not supported on the macOS Monterey platform, individuals running older versions are encouraged to upgrade SecureCRT to resolve the issue.

Individuals who have licenses that are not eligible for registering a newer version of SecureCRT can either contact or visit the Pricing page for information on purchasing upgrade licenses.

To temporarily see hidden folders and files in a file section dialog, press the COMMAND+SHIFT+. key combination.

SecureCRT users who have used SecureCRT on the Windows platform may be accustomed to being able to specify loopback addresses other than "localhost" or "" when manually selecting the local IP address on which to allow connections in port forward configurations.

Specifying loopback addresses like "" or any 127.* loopback address works "out of the box" in a Windows environment because the Windows operating system has built-in support for such loopback addresses.

In contrast, macOS only provides SecureCRT with the following network interfaces "out of the box":

  • The machine's IP address
  • localhost

macOS users with root or administrator privileges may be able to use the "ifconfig" command to configure aliases for additional loopback address within macOS for use with port forwarding configurations in SecureCRT. For example, issuing the following command within a "Local Shell" connection within SecureCRT would create an additional "" loopback alias:

sudo ifconfig lo0 alias

Note: "sudo" is used to launch the command because "ifconfig" requires root privileges. If you do not have root/administrative privileges on your macOS machine, contact your system administrator for assistance in getting additional loopback addresses set up for use with SecureCRT.

The instructions below describe how to import your sessions from other platforms to SecureCRT for iOS.

iCloud Instructions (macOS)

  1. Make sure iCloud is enabled on the macOS system.
  2. On the macOS system, run SecureCRT 7.3 or newer and select Export Settings from the Tools menu. Navigate to the iCloud drive in Finder and specify a name for the XML file that will be created (e.g., SCRTConfig.xml).
  3. Make sure iCloud is enabled on the iOS device.
  4. In SecureCRT for iOS, select Manage Archives in the Global Options.
  5. Select Import (upper right).
  6. Select the XML file that was created in Step 2 above. The import will begin.

Although most session settings are imported with this process, private keys used for public-key authentication are not currently included in the import operation.

iTunes Instructions (Windows, macOS, or Linux)

  1. On the Windows, macOS, or Linux system, run SecureCRT 7.3 or newer and select Export Settings from the Tools menu. Choose the folder location and specify a name for the XML file that will be created (e.g., SCRTConfig.xml).
  2. On the machine that syncs the iOS device with iTunes, start iTunes and connect your iPad or iPhone.
  3. Navigate to the iOS device in iTunes and choose File Sharing under Settings (on left).
  4. Choose SecureCRT under Apps.
  5. In SecureCRT Documents, click the Add... button and select the file that was created in Step 1 above.
  6. Sync the iPad or iPhone.
  7. Eject the iPad or iPhone.

The next time you start SecureCRT on the iOS device, you will be asked if you want to import the archive. Select Yes to import the archive. Although most session settings are imported with this process, private keys used for public-key authentication are not currently included in the import operation.

If you need further assistance importing your sessions to SecureCRT for iOS, please contact us.

If you're using SecureCRT® 8.0 or newer, a connection attempt to a server that supports only Diffie-Hellman key exchange can result in the following error:

Key exchange failed.
No compatible key exchange method. The server supports these methods: diffie-hellman

In SecureCRT 8.0 and later, the Diffie-Hellman key-exchange method is off by default because of the Logjam vulnerability. For the security-minded professional, Diffie-Hellman should be left disabled, and SSH2 server implementation should be upgraded or configured to support a more secure key exchange algorithm.

Diffie-Hellman should only be enabled in rare circumstances where the device to which you are connecting does not support a more secure key-exchange algorithm, and where upgrading the SSH2 server implementation isn't an option.

If you must enable the Diffie-Hellman key-exchange method to successfully connect to a legacy server that has no possibility (or low probability) of supporting more secure key-exchange algorithms, you can configure SecureCRT accordingly. Here are instructions for allowing a session to use this deprecated key-exchange method:

  1. Open the Session Options dialog for the session that needs to use Diffie-Hellman key exchange.
  2. Select the Connection/SSH2 category.
  3. In the Key exchange group, enable "diffie-hellman".
  4. Press OK to save the session.

If installing a newer version of SecureCRT causes the newer version of SecureCRT to run in evaluation mode, it means the license data in place on your machine is not eligible to register the newer version.

Avoiding the Issue

To avoid installing a newer version of SecureCRT for which the existing license data is not eligible to register, individuals should use the Update Now... functionality found in SecureCRT's main Help pull-down menu. In SecureCRT 9.3 and later, the item Update Now… is found on the Update pull-right menu.

Update Now Walkthrough

Alternatively, individuals can use the Check for Updates... functionality in the same Help pull-down menu to view a web page, which will show any newer versions available and whether or not the existing license data is eligible for registration. In SecureCRT 9.3 and later, the item View Available… is found on the Update pull-right menu.

Check for Updates

In SecureCRT 9.3 and later, there is an option called Check at Startup on the Update pull-right menu. When this option is set, SecureCRT will automatically check at startup for the availability of a newer version that is valid with the current license.

Resolving the Issue

If you installed a newer version of SecureCRT for which the existing license is not eligible to register, SecureCRT will provide you with 30 days of evaluation in which you can continue to use the newer version and evaluate whether the additional capabilities of the newer version are worth purchasing an upgrade license.

If your time spent evaluating the newer version does not convince you that it's worth purchasing an upgrade license, you can install the older version you were running prior to installing the newer version.

Installers for prior versions of VanDyke Software products can be found on the Previous Releases page or in the Previous Releases link in the blue footer navigation bar at the bottom of the VanDyke website.

Previous Releases on Website

Three Fast Ways to Learn More…

  1. Read or download one of our secure solutions white papers.
  2. Download a free evaluation copy of our products.
  3. Let us help define the right Secure Shell solution for your company.

VanDyke Software uses cookies to give you the best online experience. Before continuing to use this site, please confirm that you agree to our use of cookies. Please see our Cookie Usage for details.