SecureCRT® FAQ

Select by category

Can SecureCRT be exported outside of the United States?

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 for SecureCRT? How do I keep my settings? How much does it cost?

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. Open the main Help pull-down menu and select the Check for Updates... menu item. The information on the website to which you are directed will provide upgrade specifics. For example:

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 Update Eligibility 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.

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

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.

SecureCRT supports two versions of the Secure Shell protocol. What's the difference between SSH1 and SSH2?

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.

What Secure Shell protocol does VanDyke Software recommend?

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.

How do I get VNC to run securely over SSH2 using SecureCRT and VShell®?

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.

I keep trying to change my foreground and background colors for just one session, but when I do, the colors for all of my sessions change. Am I doing something wrong?

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.

Why am I seeing strange characters on the screen when I log onto RedHat, particularly when I look at man pages?

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 update eligibility 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.

How can I make SecureCRT the default SSH2 application for Windows so that I can launch it from a web browser?

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.

What settings should I use so that the emulation is correct for SCO OpenServer?

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".

Why isn't the audio bell working?

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

How do I get my color scheme settings to work?

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.

How do I modify port-forwarding filters 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

How do I move my SecureCRT sessions and settings to other machines and/or platforms?

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.

Will my SecureCRT license keys work on the macOS and Linux versions?

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.

The Upgrade Eligibility page shows what versions your license keys will work for.

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

In the Mac version of SecureCRT, I would like to select an identity file in the .ssh folder. How can I see hidden folders and files in the file selection dialog?

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

How do I get port forwarding to work with loopback addresses in SecureCRT for macOS?

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.

How do I import my sessions from SecureCRT for Windows, Mac, or Linux to SecureCRT for iOS?

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.

In addition to session settings, keys used for public-key authentication are included in the import/export process.

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. In addition to session settings, keys used for public-key authentication are included in the import/export process.

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

How do I connect to a server that only supports Diffie-Hellman key exchange?

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.

Four 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.
  4. Subscribe to our What's New page for tips, solution ideas, and product news.

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.