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 is an alias for domain name pointer domain name pointer
greta:~: host -t ptr domain name pointer
greta:~: host -t ptr domain name pointer
greta:~: host -t ptr has no PTR record
greta:~: host -t ptr has no PTR record

shows that to connect to the slogin service, try or

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

  echo `date` `hostname` `who am i`
 ssh -vKX

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="*" 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.
  • 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:

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


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="*" 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

Comment: "test key [2048-bit dsa]"

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="*"' >> ~/.ssh/authorized_keys
echo $(ssh-keygen -i -f public-key-file) >> ~/.ssh/authorized_keys

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