NCSA Home
Contact Us Intranet

Intel 64 Linux Cluster Access FAQ

User Information Home
Data
Security
Allocations
Consulting
Training

NCSA's Help Desk is available 24 hours a day, seven days a week, 365 days a year:
help.ncsa.illinois.edu
217-244-0710
help@ncsa.illinois.edu

 

I forgot my NCSA site(kerberos)password. What do I do?

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

I forgot my TeraGrid User Portal password(Also known as TeraGrid-wide password). What do I do?

    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.

My TeraGrid User Portal LoginID and Password does not allow me to login to NCSA resources directly using my local ssh client. Why?

    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.

I have a TeraGrid Account at NCSA, how can I access NCSA resources directly using using my local ssh client?

    Users can setup ssh keys or request a site password (NCSA Kerberos password) by following the instructions on the TeraGrid user support pages.

I have created ssh keys with my local ssh client and installed the public ssh key on my target NCSA resource, but I am unable access the NCSA resource using my ssh keys. What could be the problem?

    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.

When using SSH Secure Shell, why does my SFTP connection attempt
fail with a "File transfer server could not be started or it exited unexpectedly.
Exit value 0 was returned. Most likely the sftp-server is not in the path of the user on the server-side."
error message?

    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.

Why does my SFTP connection attempt fail with a "Received message too long 1416979744" error message?

    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.

What does it mean when the command uberftp or mssftp fails with a "Invalid CRL: The available CRL has expired" error message?

    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.