SSH Protocol 2 Required

As of October 1, 2003 Secure Shell (SSH) Protocol 2-compatible applications are required for connecting to NERSC computers. The SSH Protocol 2 is more secure version 1. (Note that these protocol versions are not the same as the software revision and/or version numbers of the numerous SSH applications available.)

For security reasons, support for Protocol 1 support was discontinued at the end of FY 2003.

Some SSH clients support both versions of the SSH protocol, and many users already use Protocol 2 to access NERSC computers. Users whose appllications support only Protocol version 1 will have to obtain and install new software.

Frequently Asked Questions

• What are the differences between the two versions of the SSH protocol?
• How can I check whether my client supports v2?
• How can I make v2 my default?
• Where do I find an SSH v2-capable Client?
• Why isn't my X11 connection forwarded by default any more?
• How can I use keys with v2?
• Why isn't the connection to my authentication agent forwarded by default any more?
• How can I overcome host key issues?

What are the differences between the two versions of the SSH protocol?

Most of the differences between are in the details of the protocol and are transparent to users. Protocol 2 provides additional mechanisms for confidentiality (the traffic is encrypted using 3DES, Blowfish, CAST128 or Arcfour) and integrity (hmac-md5, hmac-sha1). Note that protocol 1 lacks a strong mechanism for ensuring the integrity of the connection.

Unix users will notice that some auxiliary files have new names. Public keys are now stored in ~/.ssh/authorized_keys2 instead of ~/.ssh/authorized_keys and the host keys are stored in ~/.ssh/authorized_hosts2 instead of ~/.ssh/authorized_hosts.

If you are staying with the same client and changing only the protocol version, defaults such as the X11 forwarding and the forwarding of a connection to your authentication agent should remain unchanged. On the other hand, if you need to install a new client, it is worth checking and modifying the defaults, as they might be not the same as for your old client (see: Why isn't my X11 connection and/or connection to my authentication agent forwarded by default, as it used to be?).

Note also that the older versions of the F-Secure SSH software commonly used under Windows and older Macintosh operating systems may not be capable of both SSHv1 and v2.)

How can I check whether my client supports Protocol verion 2?

Most clients can be forced to use SSHv2 by specifying a -2 option on the command line. For example:

% ssh -2 seaborg.nersc.gov

Try to use this option with your client.

The Windows F-Secure SSH client, starting with v 5.2, supports both protocols and automatically adjusts its protocol version to match server requirements. If you are using this product, check the version you have and upgrade if necessary.

How can I make v2 my default?

You may have determined that you can force your client to use protocol v2, and yet find that it reverts to v1 by default. This could happen when v1 is set to be the default in the client configuration. Most Unix clients have two places where this could be set. One of them is user's ~/.ssh/config. Check whether you have such a file and if you do, check whether it contains a line: Protocol 1. Removing this line, or changing it to Protocol 2, might solve your problem. If you have no such file or no such line in the file, it may be specified in the /etc/ssh/ssh_config file (on Linux, check with your sys admin for other flavors of Unix). You can either ask your system administrator to replace it with Protocol 2,1 or just create/edit your ~/.ssh/config and place the line: Protocol 2 in it. For other clients check the documentation or contact the vendor.

Why isn't my X11 connection and/or connection to my authentication agent forwarded by default, as it used to be?

If you are staying with the same client and changing only the protocol version, the defaults, such as X11 forwarding and forwarding connections to your authentication agent, should remain unchanged. On the other hand if you had to install a new client it is worth checking and modifying defaults as they might not be the same as for your old client. On Lnix hosts the defaults for the SSH client are stored in /etc/ssh/ssh_config and in the F-secure SSH (the Windows client) you can access then via Edit Settings. For other SSH clients check the documentation provided by your vendor.

If the SSH client configuration files are owned by root and you have no permission to modify them then you can force the X11 and/or the authentication agent forwarding either by using command line parameters (-A for the authentication agent and -X for the X11 forwarding) or by modifying your ~/.ssh/config (add ForwardX11 yes for the X11 forwarding and ForwardAgent yes for the authentication agent forwarding). Those steps should be viewed as temporary and you should contact your system administrator to make permanent changes for the system defaults (especialy for the X11 forwarding).

How can I use keys with v2?

Your SSH keys and SSH agent will no longer work, after switching to Protocol 2. This is because Protocol 2 uses a different format for the keys. Generate a new pair and then place the public key on the targeted NERSC host in a ~/.ssh/authorized_keys2 file.

How can I overcome host key issues?

When you try to log in for the first time using Protocol 2, you'll see the following question asked by your client:

% ssh seaborg.nersc.gov
The authenticity of host 'seaborg.nersc.gov ()' can't be established.
RSA1 key fingerprint is (they key for Seaborg listed here)
Are you sure you want to continue connecting (yes/no)? 

Just type yes; the version 2 host key will be remembered, and you'll never see this question again.

Sometimes you might see:

% ssh seaborg.nersc.gov
No RSA1 host key is known for seaborg.nersc.gov and 
	you have requested strict checking.
	Host key verification failed.

If this is not against your site policy (check with your sys admin if in doubt), add a command-line argument (needs to be done only once):

% ssh -o StrictHostKeyChecking=no seaborg.nersc.gov
Warning: Permanently added 'seaborg.nersc.gov' (RSA1) 
	to the list of known hosts.

If your site policy requires StrictHostKeyChecking to be in place contact NERSC consultants.