Computer Laboratory

Troubleshooting SSH connections

Connecting via Kerberos — connection refused

Kerberos authentication requires you to request a connection to the canonical name of the machine, rather than to an alias for the service it is providing, so you have to make sure you are using the right name. If a connection is refused and the host name has a PTR record in the DNS pointing at the canonical name, use that. e.g.

greta:~: host -t ptr slogin.cl.cam.ac.uk
login.cl.cam.ac.uk is an alias for slogin-serv.cl.cam.ac.uk.
slogin-serv.cl.cam.ac.uk domain name pointer ssh-remote-1.cl.cam.ac.uk.
slogin-serv.cl.cam.ac.uk domain name pointer ssh-remote-2.cl.cam.ac.uk.
greta:~: host -t ptr ssh-remote-1.cl.cam.ac.uk.
ssh-remote-1.cl.cam.ac.uk domain name pointer svr-ssh-1.cl.cam.ac.uk.
greta:~: host -t ptr ssh-remote-2.cl.cam.ac.uk.
ssh-remote-2.cl.cam.ac.uk domain name pointer sandy.cl.cam.ac.uk.
greta:~: host -t ptr svr-ssh-1.cl.cam.ac.uk
svr-ssh-1.cl.cam.ac.uk has no PTR record
greta:~: host -t ptr sandy.cl.cam.ac.uk
sandy.cl.cam.ac.uk has no PTR record
greta:~: 

shows that to connect to the slogin service, try svr-ssh-1.cl.cam.ac.uk or sandy.cl.cam.ac.uk.

If you experience difficulties, please try to connect adding a debug key (-v) to the command

  echo `date` `hostname` `who am i`
 ssh -vKX crsid@host.cl.cam.ac.uk

and email the commands typed and all output to [Javascript required].

Connecting using Putty

Login problems

If you are experiencing trouble logging into PuTTY, you may want to change the PuTTY settings so the Unix shell window doesn't close automatically, but logs the results of what happens.

  • Load your session.
  • In the PuTTY Configuration window, under 'Close window on exit', select the button 'Never'.
  • Save your session.
  • Under 'Category', select 'Session > Logging'.
  • Under 'Session logging', select the option 'All session output'.
  • Under 'Log file name', browse to a suitable location to save the logfile and give the logfile a name.
  • Under 'What to do if the log file already exists', select the option 'Always append to the end of it'.
  • Save your session again.

On your next login attempt, the results will be logged into the file you created. You can then send the file to Windows administrator for further assistance with the problem.

No supported authentication methods

When setting up PuTTY you may experience the above error message. One possible cause is that the domain you have specified in the authorized_keys file and the domain your computer believes it resides in are not the same.

To resolve this issue, see whether you can login after removing the from="*.cl.cam.ac.uk" prefix from your authorized_keys file temporarily.

If so, then look up your computer’s domain name:

  • Navigate to 'Control Panel > System and Security > System'
  • Under 'Computer Name' section, you can see your domain, i.e. cl.cam.ac.uk.
  • The domain written as part of the from= command in the authorized_keys file should match the domain listed here under the 'Computer Name' tab.
  • Edit authorized_keys accordingly, save it, and try another PuTTY session.

If this still does not resolve your issue, it could be an absence of a reverse mapping of your IP address. You will need to contact a Windows administrator for further help.

Cannot access Lab machines remotely

Whatever operating system you are using on the machine you are connecting from, you must check the following on your Lab unix account (i.e. the machine you are connecting to.)

Is your home directory or your .ssh/ directory group or world-writable?

It shouldn't be. Type

$ ls -ld ~ ~/.ssh

You should see something like the above output. Note the absence of w in the 6th and 9th columns of the mode string at the start of each line. This indicates that 'group' and 'others' do not have write access the directories.

drwx------ 218 ig206 ig206 77824 2006-10-06 13:17 /home/ig206
drwx------   2 ig206 ig206  4096 2006-09-29 13:34 /home/ig206/.ssh

If you have the group or other write bits set, clear them with the command

$ chmod go-w ~ ~/.ssh

Are you connecting using IPv6?

You can test this on the machine you are connecting from by connecting with the option 4:

$ ssh -4 [Javascript required]

If that works but the connection fails without the -4 option, then you need to modify your authorized_keys file to permit access from the appropriate IPv6 subnet. Suitable examples are:

PatternExplanation
from="*:*"Maches any IPv6 address
from="2001:0630:0210::/44"Matches any IPv6 within the Computer Laboratory
from="2001:0630:0212:0200::/56"Matches any IPv6 within the Computer Laboratory
from="2001:0630:0212:02ab::/64"Matches any IPv6 from the Internal-CL wireless network

The IPv6 pattern can be combined with IPv4 patterns and name patterns in a single from clause such as

from="2001:0630:0212:0200::/56,128.232.0.0/9,*.cl.cam.ac.uk"

Have you set up the ~/.ssh/authorized_keys file correctly?

Note that the spelling is the American form authorized_keys with a z.

Make sure the file is not group or world writable:

$ ls -l ~/.ssh/authorized_keys
-rw------- 1 ig206 ig206 6924 2006-08-11 15:33 /home/ig206/.ssh/authorized_keys

If you have the group or other write bits set, clear them with the command

$ chmod go-w ~ ~/.ssh/authorized_keys

Have you set up the public key line(s) in the ~/.ssh/authorized_keys file correctly?

The from option on each line should be a comma-separated list of fully qualified domain names in double quotes. The names are the names of hosts which can log in using that key. The names can include the * character as a wildcard.

The OpenSSH public key is a single string of ASCII letters and numbers (with no linefeeds or carriage-returns) followed by a key identifier, perhaps of the form login@host but it is not important exactly what this is.)

To check, type this

grep '^from' ~/.ssh/authorized_keys

This should produce one or more lines, each looking something like this:

from="*.cl.cam.ac.uk" ssh-rsa KKKKKKKK XXXXX

Here KKKKKKKK is the public key string and XXXXX is the key identifier.

Is the public key in the ~/.ssh/authorized_keys file in the correct format?

The public key listed in ~/.ssh/authorized_keys must be in the OpenSSH format. If the key is an SSH2 key then it will look like this

---- BEGIN SSH2 PUBLIC KEY ----
Comment: "test key [2048-bit dsa]"
AAAAB3NzaC1kc3MAAAEBAJLL7cNNAwOXcOWqUBlr6fEw7opLOgL8XNfmxLll1zkmH85Erm
X2podpuSJUyipom36iYdBJqk8/QvjhFmbAqcnwdh5aQj7tYTs0bqrqHDUiqti9yUmoICYF
NdqEOiwUHNZvRtxqVmLEMUD+8tH/PCRIMHlrKip+DMr1gAkwp4atEUb3fXp+CuA6+sH3x9
sMMcwdyDsZJ4irWUbtR6Hyopmlx+T5+quUTlU+jPYx7MQctnpmsOVGjORIGfl0j+xfFget
zS/9eDOjlNOFO+yL4nPYvG0eoxIyHBsY0eTC1iLWtYp+8EBcPZC1MoH4YfhHHkxVt2wLKz
YXccMPSBW5sJ0AAAAVAIzBCkkOo5iPng85ubIvfF1CT6f1AAABAFH6Emp1VcGeD5PEknYW
aFSHeT+ppVLfK40PukCzTsvEmwDIgh7SyYd1eELjCh1cBOu9+Y+HQzRnR9nGND2mRpNckO
UQEbSDQLU+VWqHbDUqRmu42XqszY5heZLZP1aNxNEVgtBYsk5ZDIGM/06QisPe2kxhFCQh
ivHXBqBtHMOYWILQXgvKji8mDd5Lw5g5iF2Ds9EAIoWq/5RWxaSwdS2zsfe1r2e1nr7MZ6
YcY3ofIvle7CLGUQIqcExC87sg/MxnFX3F3USni/YdjOxnRSeYVs5jRUt5KfdsJi3HMuFA
jmbxhsPm9IjvYxh07CzTlAJBOEmDmOpR7wNY713zIK0AAAEAQ/ciBjHmEjkyOUYzFYuJEn
GgfUP4Qalnm5p6GF5P5Dnb0vOiC6gQo9IwmkHPQlWcZTZgh9k4ZkmzPY62B6BHm5iuaw31
RV0OGWhDQCVoEm9pTIeP1SYzuNO78WJgnwA1afjX9szS97JpblCPZlXutnGYkpfOgrNWMM
4ChtAOS/EamXs/MviHSnV1J5S+POrFXpBb2muc7a0GnUWX/0sVaWV9hvOXGveA9rH+nniR
jSyNJx9Ln6/uQOWjlKqaH8hu+O+DQ6fJ+eqF0I+mRw9fDt+3V8UJvn7PVrMjjtPCI0q9LK
mQSBSA6rPLrFpVSZmIio6HcebCXoSMLA0ZYKE98Q==
---- END SSH2 PUBLIC KEY ----

This is wrong. You need convert such a key using the command

ssh-keygen -i -f public-key-file

Where public-key-file is the name of the file containing the SSH2 format public key. This will output the OpenSSH format key on stdout. You can pipe the key directly into your authorized_keys file using some commands like this

echo -n 'from="*.some.network.or.other"' >> ~/.ssh/authorized_keys
echo $(ssh-keygen -i -f public-key-file) >> ~/.ssh/authorized_keys

Where *.some.network.or.other and public-key-file are your host address(es) and public key file-name.