| |
|
|
|
|
Intel 64 Linux Cluster Access FAQ |
If you have your NCSA account paper work, send email to
help@ncsa.illinois.edu,
requesting that your NCSA password be reset to the default.
If you no longer have the sheet with the default password,
send email to
allocations@ncsa.illinois.edu
and ask that the password be mailed
or faxed to you. (We cannot send passwords via email due to security reasons.)
TeraGrid provides an online
Portal Password Reset utilitiy to reset your TeraGrid User Portal password.
You will receive a security code via email that will allow you to set a password of
your choosing along with instructions on how to do so.
Note: Email will be sent
to the email address that you registered with TeraGrid when you applied for an account.
Your TeraGrid login information(LoginID & Password) is used for accessing
TeraGrid Resources via the TeraGrid User Portal
(TGUP) or gsi enabled clients like
GSI-SSHTerm or
Globus GridFTP GUI.
Users can setup
ssh keys
or request a
site password (NCSA Kerberos password) by following the instructions on the
TeraGrid user support pages.
Common problems that can prevent ssh keys from working are, incorrectly copying the
public key to the target resource, incorrect directory/file permissions, and
incompatible file format of the public ssh key.
- When copying your public key to a target resource, use a file transfer client
like scp/sftp, to avoid accidently modifying the copy of the file, which can
occur when cutting and pasting.
- Directory and file permissions need to be set as follows.
711 (drwx--x--x) on $HOME
711 (drwx--x--x) on $HOME/.ssh
600 (-rw-------) on $HOME/.ssh/authorized_keys
- The ssh public key needs to be in OpenSSH format once it has been put in place
on the NCSA resource, in order for the ssh key access to work correctly.
After copying your public key to $HOME/.ssh/, if you are unsure whether
your ssh public key is OpenSSH format run the following command...
ssh-keygen -i -f ssh_public_key_filename >> authorized_keys
If the prompt returns without error then you have succesfully converted a copy of
your ssh public key to OpenSSH format.
If you get the error "uudecode failed.", then your ssh public key file
is already in OpenSSH format. Use the cat command to add public key to the
authorized_keys file.
cat ssh_public_key_filename >> authorized_keys.
This error is usually caused by commands in a shell run-control
file (.cshrc, .profile, .bashrc, etc.) that produce output to the
terminal. This output interferes with the communication between the
SSH daemon and the SFTP-server subsystem. Examples of such commands
might be date or echo. If you use the mail command to check for mail,
it can also cause the error.
You can check to see if this is likely the problem. If you are unable
to SFTP to a machine, try to connect via SSH. If you are able to SSH,
and you receive output to your terminal other than the standard login
banner (for example, "You have mail"), then you need to check your
run-control files for commands that might be producing the output.
To solve this problem, you should place any commands that will produce
output in a conditional statement that is executed only if the shell
is interactive.
This error is usually caused by commands in a shell run-control
file (.cshrc, .profile, .bashrc, etc.) that produce output to the
terminal. This output interferes with the communication between the
SSH daemon and the SFTP-server subsystem. Examples of such commands
might be date or echo. If you use the mail command to check for mail,
it can also cause the error.
You can check to see if this is likely the problem. If you are unable
to SFTP to a machine, try to connect via SSH. If you are able to SSH,
and you receive output to your terminal other than the standard login
banner (for example, "You have mail"), then you need to check your
run-control files for commands that might be producing the output.
To solve this problem, you should place any commands that will produce
output in a conditional statement that is executed only if the shell
is interactive.
This error is usually caused by the presences of old(expired) *.r0 files(dot R zero)
in "$HOME/.globus/certificates/" directory. The full error message would look
something like...
Failed to init security context
GSS Major Status: Authentication Failed
GSS Minor Status Error Chain:
globus_gsi_gssapi: SSLv3 handshake problems
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Could not verify credential
globus_gsi_callback_module: Invalid CRL: The available CRL has expired
To fix the issue, move or delete your "certificates" directory in
"$HOME/.globus/" and then try your mssftp or uberftp command again.
If you are running these commands on NCSA production resources and
if the error message remains after you have moved/deleted your "certificates"
directory, please notify the
Consulting Group.
|
|
|
|
|