There are a number of problems that can cause failures when connecting to the SDCC. Here are some things to look for and try in order to resolve your problem.
Private and Public Key Issues
- Have you uploaded your public key to the SDCC via the key file upload form (requires your Kerberos user name and password)? If your browser dialog does not display your .ssh directory or files because they are hidden, see these instructions.
- Most problems with a public key missing from a connection can be mitigated by using SSH agent.
- Are you connecting to our SSH gateway from the same system on which you generated your key pair? If not, you will have to copy the private key to this additional system. If this system is using a different SSH client, you may need to convert or import the private key. See:
and click on "Using SSH keys." Do not generate and upload another public key from this additional system; uploading another public key will overwrite your existing public key and create more problems. Even using different SSH clients on the same system may require this conversion/import of the private key.
- Are you asked for a passphrase when you activate your SSH agent, or when you connect? If not, then your client is not using the private key for some reason. It could be the private key doesn't exist, is not in the default filename, access rights of the file are incorrect, the file is not in a directory the client is searching, or some other reason.
- If you have uploaded another public key, then that key pair is the only usable pair that will work, and all other pairs are now obsolete. Also, the private key from this pair must be copied and possibly converted or imported to any other SSH clients you are using.
If your username on your local system is different from your username at the SDCC, then you must specify your SDCC username when you connect to the SDCC, using the -l option to the ssh command:
ssh -l [username] [SDCC-hostname]
or prepending username@ to the SSH gateway system name (no space between the @ and the SSH gateway system name):
In Windows SSH clients, there is typically a text box in which you type in your username.
Ownership/Access Rights Issues
If you are using a Linux/UNIX based SSH client, please check the ownership and access rights of your ~/.ssh/ directory and
the private key file in that directory. Both must be owned by your local user account (not necessarily the same as your
SDCC user account). The rights on your ~/.ssh/ directory should be 700, and the rights on the private key file (possibly,
but not definitely, named ~/.ssh/id_rsa), should be 600. The important thing here is that "group" and "other" access rights
must be 00.
If you are using PuTTY in Windows, then you have to either import your private key or somehow tell PuTTY where the key file is.
In the main PuTTY Configuration, click on SSH and then Auth. The window will have a text box where you can put the path
of the key or browse for it. See Windows SSH Key Generation for more information on generating SSH keys for use with PuTTY.
You may also need to forward your private key through a remote gateway machine to another server. See SSH Agent for more information on storing and forwarding your private key.
Viewing Your Public Key
You can view the contents of the public key you uploaded to the SDCC here SSH Public Key File Viewing Utility. You can check this against the public key that may be on your local system (the public key is not required to be on your local system; the private key is required to be there). If they
are not the same, then the private key on your local system may not be paired with the public key you uploaded to the SDCC.
If you have both private and public keys on your local system, check the date/time stamps on them, as they should be the same. If they are not the same, then the private key on your local system may not be paired with the public key that you uploaded to the SDCC. If you are using the openssh client, then you can also check to see if your local private key is paired to the public key that you uploaded to the SDCC. Run the command:
on your local system. It will ask for the filename of your private key and its passphrase and will display the public
key (without the trailing comment field) that is paired with it. Check this against the results of viewing the public key
you uploaded to the SDCC as described above.
Frozen Sessions and Terminals
If your connection or session intermittently freezes, try adding a server keep-alive option to your usual SSH command:
ssh ... -o ServerAliveInterval=120
This ensures that a set of request and acknowledgment packets will be sent between the connection every two minutes, even when no other data has been requested. You can also add this option to your SSH configuration file (
~/.ssh/config) instead of specifying it with each SSH command:
Host Key Issues
Sometimes host key problems can close the ssh connection before login completes. If you see an error like this:
ssh_exchange_identification: Connection closed by remote host
Then you might try removing the offending host key from your
~/.ssh/known_hosts file and try again.
Error: Agent admitted failure to sign using the key
This error might occur if you accidentally load the wrong SSH identity for a specific key, if you've uploaded a new public key that hasn't yet been synced with your account (or uploaded multiple or invalid keys), or if you're trying to load too many SSH identities at one time. Your best recourse is usually to:
- Log out of all current sessions
- Log back in
- Add your identity with the ssh-add command.
IPv6 and Disconnections
If you're connecting to our SSH gateways via IP version 6 and notice problems with frequent disconnections, try forcing connections with IPv4 instead with the '-4' option, i.e.:
ssh -4 ....
Passwords vs. Passphrases
Your SSH key passphrase and your SDCC user account password are two distinct entities. Your personal SSH key passphrase, not your SDCC user account password, protects your private key and is required in order to connect to the SSH gateway with your public key. Account password changes do not affect your SSH key passphrase, which is private to you and known to you alone.
If you forget and can not determine your SSH passphrase, you can:
- Generate a new passphrase for your existing key, via:
ssh-keygen -p [existing-key-file]
- Or generate an entirely new key with another passphrase, and upload its fingerprint.
To help eliminate many common issues with SSH keys and passphrases, see the next section.
We highly recommend using an SSH agent to forward your public key and passphrase ahead to remote sessions, which will help avoid most problems with the key and obviate the need to enter your passphrase at a remote prompt. See our SSH Agent page for details.
X Session Forwarding
You may have an issue with X11 session forwarding or corrupt session files. See our X11 troubleshooting page for help.
The use of SSH key pairs generated via the DSA encryption algorithm, also known as DSS keys, is prohibited by the facility, as the algorithm is known to be weak in comparison to stronger, more modern encryption algorithms. Please do not attempt to generate and use DSA/DSS keys; instead, generate key pairs using the RSA algorithm, as described in our SSH key generation documentation.
Newer OSes and versions of OpenSSH may reject the older, stable version of OpenSSH running on the SSH gateways, returning errors such as "signing failed for RSA ... agent refused operation" and restricting connections with keys signed with an RSA-based algorithm. You can override this by adding `ssh-rsa` to the list of accepted public key types and host key signing algorithms accepted by your SSH client, either in your remote host configuration, or adding it as an option to your SSH commands when connecting to the SDCC, e.g.:
ssh -o PubkeyAcceptedKeyTypes=+ssh-rsa -o HostkeyAlgorithms=+ssh-rsa email@example.com
All options on the command line
ssh -i /path/to/your/private/key -o PubkeyAcceptedKeyTypes=+ssh-rsa -o HostkeyAlgorithms=+ssh-rsa -A firstname.lastname@example.org
Some additional SSH-related sites and resources:
If all else fails, try running this command, substituting your account user name for [username]:
ssh -vvv [username]@ssh.sdcc.bnl.gov