NERSC logo National Energy Research Scientific Computing Center
  A DOE Office of Science User Facility
  at Lawrence Berkeley National Laboratory 		Site Map | Help | Search
Login
Home About News & Media Systems Support & Services Science & Tech
Restore navigation column

Connecting to NERSC

All NERSC computers (except HPSS) are reached by use of programs that implement the Secure Shell (SSH) communication and encryption protocol, version 2, or by Grid tools that use trusted certificates.

HPSS can be accessed securely with ftp or hsi, via the use of encrypted tokens. Please see the HPSS pages for a description of this procedure.

For security reasons, all network ports into NERSC systems are blocked, except for those running SSH or Grid services (a side effect of this is that ftp "tunneling" is not available for file transfers). If you have a need for incoming port access, please use this form, or contact NERSC consulting.

Contents

Computer Hostnames

Many NERSC systems have multiple login nodes, and many nodes have several aliases. Users should always connect to NERSC systems using the "generic" system name, not the name of a specific node. The main exception to this rule is for Grid access, where a grid-specific node must be specified.

Computational Systems

Hopper
Generic name: hopper.nersc.gov
Grid name: hoppergrid.nersc.gov
Franklin
Generic name: franklin.nersc.gov
Grid name: franklingrid.nersc.gov
Carver
Generic name: carver.nersc.gov
PDSF
Generic name: pdsf.nersc.gov
Grid name: pdsfgrid.nersc.gov

Mass Storage

HPSS
Generic name: archive.nersc.gov
Grid name: garchive.nersc.gov

Servers

DaVinci
Generic name: davinci.nersc.gov
Grid name: davinci.nersc.gov
CVS -
Generic name: cvs.nersc.gov
Grid name: N/A

Secure Shell (SSH)

Users must use SSH via protocol version 2. There is no SSH access to the mass storage system at NERSC. See the HPSS pages for more information about connecting to HPSS.

What is SSH?

SSH (Secure Shell) is a program to log into another computer over a network, execute commands on a remote machine, and move files from one machine to another. It provides strong authentication and secure communications over unsecure channels. All communications are automatically and transparently encrypted, including passwords. This prevents "password sniffing", one of the most common means by which computer system security is compromised. The UNIX version of SSH also provides a remote copy operation (scp). Another utility for secure file transfer is available with many SSH implementations is known as sftp. Additionally, SSH allows secure X Window connections.

Similar to many other communications packages, SSH is implemented with a server "daemon" (sshd) to handle inbound connections, and a client (ssh) to handle outbound connections. NERSC is running an SSH daemon for the version 2.0 and 1.5 SSH protocols on its machines.

Some terminology:
ssh and slogin
The ssh and slogin are the standard UNIX command names for interactive login from a shell or terminal window. They are secure replacements for the older remote connection commands, "telnet", "rlogin", and "rsh".
sftp
The sftp utility is a secure replacement for the standard file transfer utility, "ftp".
scp
The scp command is a secure replacement for the Unix remote file copy command, "rcp".
Both sftp and scp allow secure file transfers between machines.

SSH Information

SSH-Capable Applications

Below is a partial list of client software that supports the SSH protocol. Note that some of the following may support only the Version 1 SSH protocols, which is not supported at NERSC as of October 1, 2003.

NERSC neither recommends nor supports any product listed below. However, NERSC consultants will attempt to help users successfully connect using their software package.

UNIX
PCs
Windows 95, 98, NT, 2000, XP Commercial Products:
  • WRQ SSH supports SSH protocol 2 and sftp file transfers.
  • SecureCRT from Van Dyke Technologies, Inc. supports the sftp protocol via its vcp command.
  • SSH Communications Security offers a free client for non-commercial use.
Windows Free Software:
  • PuTTY, Simon Tatham's 32-bit Windows SSH client supports scp and sftp file transfers (version 0.50 and above).
  • FiSSH, Mass Confusion's 32-bit SSH client for Windows
Macintosh
Commercial Products:
  • Apple includes a modern version of OpenSSH with OS X: see the man pages for more info. Updates are included in their frequent software updates to OS X.
  • Gideon, an sftp client for Mac OS X.
Free Software and Shareware:
VAX/VMS
See FISH, an SSH client for VMS.
BeOS
See: BeOS SSH client (no version 2 support yet).
PalmOS
Top Gun SSH.

Secure Connections from a Unix System using SSH

SSH allows users of Unix workstations to secure their terminal and file transfer connections. This page shows the straightforward ways to make these secure connections.

NERSC users are strongly encouraged to use the version 2.0 SSH protocol. This page discusses version 2 access except for mention of issues pertaining to protocol 1 to protocol 2 transition.

SSH provides the functional equivalent to the rlogin utility, but in a secure fashion. SSH is freely available for Unix-based systems, and should be installed with an accompanying man page. The most simple usage is described here.

Run ssh on your local workstation, specifying the remote destination machine as follows: 

workhorse% ssh -l bopshewah franklin.nersc.gov
bopshewah@franklin.nersc.gov's password: <enter password here>

franklin %

In the above, a user named "bopshewah" connects via a workstation named "workhorse" to the system named "franklin".

Password-less logins and file transfers

You can use SSH to set up a convenient environment for connecting and copying files remotely without being prompted for a password each time. Below we outline the way this is typically done. If this does not work, you may have to ask your system administrator for help.

SSH connections can be authenticated using "passphrase" authentication. The user generates a private/public key pair to be used by SSH for authentication. This can be very convenient once it is set up. For example, the user can store his/her passphrase in memory on a local workstation once at the start of the workday and then connect to other machines from that workstation without being prompted for passwords or passphrases.

To set up passphrase authentication, on your local machine:

  1. Make sure you have SSH installed on your local machine.
  2. Make sure you have a directory named $HOME/.ssh on your local machine
  3. Run the command ssh-keygen -t rsa or ssh-keygen -t dsa. By default, this will create files in $HOME/.ssh named id_rsa or id_dsa and id_rsa.pub or id_dsa.pub. The file id_rsa or id_dsa contains your private key; id_rsa.pub or id_dsa.pub is the corresponding public key. You will be prompted to enter a "passphrase." This is a text string, similar to a password, that you will use for passphrase authentication. Do not make it the same as your password.

Do the following on each remote machine that you want to access.

  1. Make a directory $HOME/.ssh on the remote machine.
  2. Copy the contents of the file on your local machine named $HOME/.ssh/id_rsa.pub or id_dsa.pub into a file on the remote machine named $HOME/.ssh/authorized_keys2. Make sure that you have not introduced any spurious line breaks into the file when you copy it. This single file can hold multiple public keys on separate lines.
  3. Log out of the remote machine. Now when you connect to the remote machine from your local workstation, SSH will prompt you for the passphrase.

You can eliminate the need to type your passphrase every time you connect. This is done by using the ssh-agent and ssh-add utilities. They are part of the standard SSH distribution.

Before you connect you can run a shell under ssh-agent. Then issue the ssh-add command, enter your passphrase once, then use ssh to connect to remote machines. If you have placed your public key the the remote .ssh directory, you will be connected with no prompt for a password or passphrase.

For example, on the local workstation: 

% ssh-agent csh
% ssh-add ~/.ssh/id_rsa
Need passphrase for /home/user/.ssh/id_rsa
Enter passphrase for /home/usr/.ssh/id_rsa my_passphrase
Identity added: /home/user/.ssh/id_rsa (/home/user/.ssh/id_rsa)

For even more convenience, you can start your X11 window manager to run under ssh-agent. Then all new processes started from within that environment will know about the passphrase stored by ssh-add.

See your system administrator for information on how to accomplish this. The following example is specific to RedHat Linux:

Edit the files in the /etc/X11/gdm/Sessions/ directory. Instead of using exec, make the X session run under ssh-agent. Here's an example /etc/X11/gdm/Sessions/Default file: 

#!/bin/bash 

/usr/bin/ssh-agent /etc/X11/xdm/Xsession

Log out and log back in again. You must do the following once each time you log in and start the X11 windowing system:

Start an xterm or other terminal. Type 

	ssh-add

and type in the passphrase you used when you generated your identity file.

The last step loads your passphrase into memory. Now every time you access a remote machine from your workstation, you will not be prompted for your passphrase nor password.

For example, this command will connect you to franklin (assuming you have a public key stored there) in a new xterm and log you in automatically: 

% xterm -e ssh franklin.nersc.gov

Connecting to NERSC With a Personal Computer

Once you have an internet connection for your personal computer, you will need an SSH-capable application in order to login to NERSC computers.

A number of applications are available, both freeware and commercial products. Your local workplace, school, or organization may have a site license for an SSH software package. If not, check the NERSC list of SSH applications.

The X11 (a.k.a. X-Windows) display software is very commonly used with SSH, and requires special options when used in connecting to NERSC ccomputers. See Using X Applications at NERSC for more details on this matter.

Note that the NERSC consultants will try to help your connect to NERSC, but they are not familiar with the details of many PC and Mac products.

Troubleshooting

If you have trouble connecting to NERSC, please contact the NERSC Consultants at 1-800-66-NERSC, menu option 3.

Some common error messages

NERSC consultants will attempt to help you solve problems concerning access to NERSC machines. However, our consultants have expertise only on software installed by NERSC and running on NERSC computers. This does not include software running locally on users' computers.

The best source of information for configuring your local computer is your local system administrator. Local coworkers can often help. Our consultants are not always able to provide help for the myriad of different programs and platforms that could be used to connect to the Internet.

Secure File Transfers

Securely copying files onto or off NERSC systems can be done with the components of SSH, the Secure Shell, possibly in conjunction with FTP, the standard File Transfer Protocol utility. Unencrypted ftp connections are not allowed into NERSC. The basic difference in how this is handled lies in whether encryption is applied to the file being copied, or only the login and password information.

It may be undesirable to encrypt the transferred files, for instance, if the files are very large and the overhead of encryption and decryption are significant. If this is not a consideration, transfer the file is with scp, the secure copy program or sftp, the secure ftp component of SSH.

In some rare cases, it may be necessary to fall back to ordinary FTP. In such cases, "port forwarding" can be used to encrypt the login and password information for a more traditional ftp transfer.

NOTE: Some ssh implementations for Microsoft Windows and Macintosh systems do not support secure file transfer using scp or sftp. For these cases, FTP Tunnelling is needed.

File Transfers using scp

The scp utility resembles the insecure remote copy program, rcp. The syntaxes and options of the two are similar, but scp encrypts data during the transfer.

Here is an example scp session used to copy a file from Jacquard to a local machine: 

% scp -c des user_name@jacquard.nersc.gov:bigjob.script .
user_name's password: (password is entered here)
% ls -l bigjob*
-rw-------    1 user_name  aaa         2368 Aug 11 17:06 bigjob.script
%

The "-c" option is used to specify the "des" encryption method. Other methods are available, but not all machines support all methods. The syntax "user_name@host:file" can be used for both source and destination; in the above example we wanted to copy the file "bigjob.script" into the current working directory of the local machine, without changing its name, so the destination was specified simply as ".". The transfer took place silently, and the system prompt was presented as evidence of its completion. The file listing confirms its success.

See the man pages for scp on your local computer for more details.

File Transfers using SFTP

Most SSH packages for Unix and some for other systems contain a secure version of the FTP utility, SFTP. This utility differs from the non-secure standard version in that it it allows the specification of an account login name along with the destination machine.

Here is an example sftp session used to copy a file from Jacquard to a local machine: 

% sftp user_name@jacquard.nersc.gov
user_name's password: (password is entered here)
sftp> get bigjob.script 
Fetching /usr/homes/user_name/ bigjob.script to  bigjob.script
sftp> quit
% ls -l bigjob*
-rw-------    1 user_name  aaa         2368 Aug 11 17:06 bigjob.script
%>
"Tunneled" FTP Transfers

Encrypting only the essential login information for use in a standard ftp session is more economical in machine overhead, but requires three separate steps of the user. There must be two terminal windows on the user's computer or terminal to perform these steps. The confusion possible in this step can be avoided if it is realized that the apparent destination of the ftp session, and both terminal windows, are on the same machine, the user's local machine; in the following steps, the local machine is named highline.

1. In the first window on highline, connect by ssh to the destination machine, Jacquard, using the -L option, as follows: 

% ssh -L number:jacquard.nersc.gov:21 jacquard.nersc.gov

Here, number is any number greater than 1024, and the same value must also be used in step 2. The port number "21" is required, and the destination machine is specified twice.

2. Next, in another window on highline, ftp to the user's local machine (highline, again), providing number from step 1 as the second argument, as follows: 

% ftp highline number

Log in as usual, realizing that this information is now secured.

3. Perform the desired file transfers: get and/or put files, as in any other ftp session; then quit the ftp session and log out of the ssh session set up in step 1, in the first terminal window.

File Transfers using GridFTP

NERSC provides a variety of Grid Services for its users. File transfer with GridFTP is one of its service. You would need to have Globus tools installed at your local machine and to obtain a DOEGrids certificate. This method has been used by a few projects and achieved good transfer rate. Notice it may be incompatible with one-time password mechanism at your local site.

File Transfers using HSI/HTAR

An often suggested and simple way of transferring data is to use our NERSC HPSS Mass Storage as a staging area. For example, you could first archive your data from a NERSC machine to HPSS. You could do this via HSI or HTAR. Then use HSI or HTAR to download the data to your local machine from HPSS. We have different HSI and HTAR versions ready to be download and easily installed on different platforms. Although it involves an extra step, there is an added benefit of backing up your data, also HPSS is specifically designed with higher performance.

File Transfers using BBCP/BBFTP

BBCP and BBFTP are secure and multi-streamed file transfer utilities that are easy to use and can achieve very high transfer rates. As of April 2007 BBCP has been installed on Jacquard and Davinci. See File Transfers using bbcp.

Using X Applications at NERSC

The X Window System is a network-transparent standard window system which runs on a wide range of computing and graphics machines. With X-Windows, you can display remote applications on your local computer screen.

UNIX Workstations

If you are using a UNIX workstation with a graphical user interface, it is almost certainly X-Windows compatible and ready.

Use ssh to connect to the NERSC production computers. If you log in using the usual default setting of SSH, the software will perform X authentication forwarding and X applications will connect to your workstation's X display server automatically. The information will be encrypted, however, and you may notice some degradation in performance. If you wish to bypass the SSH encryption when displaying X applications, follow the instructions below.

In order to make X-Windows applications display on your screen, do the following. This will also defeat SSH encryption of the data:

SSH is the only supported method of connecting to NERSC machines. See the Secure Shell (SSH) web page and the brief page on Secure Connections from a Unix System using SSH for more information on this topic.

Displaying X on a Mac or PC

If you want to display X-Windows applications on a Mac (pre-OS X) or PC, you may need to obtain third-party X-display software and install it on your machine.

Some software packages are listed below. NERSC does not necessarily support, endorse, nor recommend any of these packages.

In any of the above cases, the X11 application must be launched before an ssh connection is made to a NERSC computer. SSH connections will work without X11, but X11-based windows will not open on your workstation.

Setting the DISPLAY environment variable

When you connect via SSH, your X11 environment should be automatically configured. If it is not, you may have to connect using the -X (upper-case X) or -Y (upper-case Y) option on the ssh command line.

If your X11 display still does not work, check that the DISPLAY environment variable has been set properly. This variable is used by the X application to determine the internet address of your local screen. You can check by typing this command at the NERSC machine prompt: 

 %  echo $DISPLAY

The system should respond with something like 

localhost:13.0

If the echo $DISPLAY command produces a blank response you can configure it manually. This method will bypass SSH encryption. At the prompt, type 

% setenv DISPLAY hostname:0   (csh)


or


% export DISPLAY=hostname:0   (ksh)

where hostname is the internet name of the machine you are using for your display. If you do not know your machine name, you can probably find it with the command 

% who | grep username

where username is your user name. For example: 

franklin% who | grep aaa 
aaa  ttyp007      Jan  7 08:36  (generic.lbl.gov)

The hostname is in parentheses (it might be a set of numbers formatted like this: 128.55.200.24).

Note: Explicitly setting the DISPLAY environment variable will not work on Franklin; xterms originating on that system MUST use the DISPLAY setting provided by SSH during initial login. Other systems are also likely to be configured to disallow unencrypted connections.

Authorizing Access

If you are bypassing SSH X-forwarding you may have to tell your display that it is OK for the NERSC machine to open a window. If you are using a UNIX workstation, open a shell window on your local machine and type this command 

% xhost +x.nersc.gov

where x is replaced by the name of the machine you are logged into

Once the remote application has opened a window, you may want to remove authorization for more windows. Otherwise, someone else could potentially open a window on your display, or even "steal" your display and view it. You remove authorization with the command 

% xhost -x.nersc.gov

Note: Using the "xhost" command can cause security problems, and should generally be avoided. If you are considering this action, contact the NERSC Consultants first for advice.

If you are using a personal computer, there will probably be a menu selection that says something about authorizing remote hosts. Check the documentation for your software package.

Terminal Types and Characteristics

The NERSC machines support a wide variety of terminal types, such as VT100 and xterm emulation.

When you connect via ssh the NERSC computer will try to communicate with your computer's software to determine the proper terminal type. If this is successful it will be transparent and you should not have problems reading and editing text in your window.

If your software does not communicate with the NERSC computer, check your local documentation for the terminal type. You can specify the terminal type on the NERSC computer by setting the TERM environment variable, as follows:

For a VT-100 emulation, type For an X-Windows "xterm" software terminal, type
setenv TERM vt100     (csh)
        or
export TERM=vt100     (ksh) 		setenv TERM xterm     (csh)
        or
export TERM=xterm     (ksh)
To see what value is set, type echo $TERM.

Dealing with Firewall-Protected Networks

Network firewalls are set up to make sites inside them harder to penetrate without proper authorization. Encryption and PIN-based challenge-response systems usually are part of them. Some firewalls refuse to allow incoming connections that are not encrypted, including X-Windows sessions. Cooperation between an encryption agent, such as SSH, and the X-Windows display server is necessary to accomplish this. Similarly, cooperation is needed between a file transfer mechanism and an encryption agent to effect file transfers through firewalls.

Since the procedures enforced by firewalls are under the control of the owning institutions, NERSC cannot offer much general advice on how to work with them. The most useful source of how-to information for a firewall-protected network is the network security administrator.

Globus services at NERSC

NERSC provides a variety of Globus services for its users. At this point HPSS and Seaborg servers support file transfers only. Names of the GridFTP servers running on those systems are: 

seaborg-g1.nersc.gov
garchive.nersc.gov

PDSF and DaVinci provide the full range of Globus services including GRAM job submission. Names of the gatekeepers/GridFTP servers on these systems are: 

pdsfgrid1.nersc.gov
pdsfgrid2.nersc.gov
pdsfgrid4.nersc.gov
pdsfgrid5.nersc.gov
davinci.nersc.gov

Globus client software is available for users on the following nodes: 

seaborg.nersc.gov
pdsf.nersc.gov
davinci.nersc.gov

To initialize the Globus client environment on any of the above systems, load the globus module: 

% module load globus

Certificates and NIM

In order to use Globus tools, users need to obtain and install user certificates. The DOE Grids web pages provide all the necessary details for the application and installation process. Access to NERSC Globus resources is granted after users enter information about the issuer and the subject of their certificates into the "Certificates" tab of NIM. The formatting of these fields is critical; they must be entered into NIM exactly as they appear as output from the Globus commands grid-cert-info -subject and grid-cert-info -issuer. For example: 
% grid-cert-info -subject
yields: 
/DC=org/DC=doegrids/OU=People/CN=Alfred E. Newman 123456
The above string would then be entered into the Subject_Certif box of NIM. Similarly, 
% grid-cert-info -issuer
shows: 
/DC=org/DC=DOEGrids/OU=Certificate Authorities/CN=DOEGrids CA 1
The above string would be entered into the Issuer_Certif box of NIM. It may take up to one hour before your certificate information propagates to all NERSC systems.

Example:

Here is an example of a simple session with some file transfers:

Notes:

Client hosts accessing NERSC gatekeepers and GridFTP servers need to have certificates of Certification Authorities accepted by NERSC installed. All the NERSC hosts offering Globus clients have already been configured to meet this requirement.

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?

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 franklin.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 franklin.nersc.gov
The authenticity of host 'franklin.nersc.gov ()' can't be established.
RSA1 key fingerprint is (they key for Franklin 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 franklin.nersc.gov
No RSA1 host key is known for franklin.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 franklin.nersc.gov
Warning: Permanently added 'franklin.nersc.gov' (RSA1) 
	to the list of known hosts.

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

Computing Sciences | Computational Research Division | ESnet
LBNL Home
Page last modified: Mon, 11 Jan 2010 21:29:12 GMT
Page URL: http://www.nersc.gov/nusers/help/access/print.php
Web contact: webmaster@nersc.gov
Computing questions: consult@nersc.gov

Privacy and Security Notice 		DOE Office of Science