IMADA / SDU Specific

Linux, SSH, Kerberos etc.

In August 2018 the computer lab was reinstalled with a new authencation system and a new file server.

Authentication and External Login Server

Generally, your credentials are you central SDU credentials. Every user has a domain, e.g., “sdu” for students and “nat-sdu” for NAT employees.

Those in “nat-sdu” should use just there username without domain. Otherwise, prepend your domain with a backslach, e.g., “sdu\jla42”.


The “\” character is special on the command line, so it must be escaped with another “\”. E.g., “ssh sdu\\”.

For connecting via SSH from external computers the new jump server is:

The old one is:

Kerberos Tickets and Passwordless Login


On Ubuntu the package “krb5-user” is needed.

The system uses Kerberos for authentication. To access files you must have a valid ticket. You can see your current tickets with:


This also shows when the ticket will expire. Currently it will expire after 10 hours.


You do not loose your ticket when you log out.

Renewing a Ticket

As a general rule, whenever you type your password, you will also renew your tickets. To explicit renew a ticket (while having one), simply use:


If you want to run stuff during the night, be aware that your ticket may expire. In that case you can use a cron job (or maybe just a script using “sleep”), to automatically run the “kinit” command while you are away.

Obtaining a Ticket

If you just log in using your password, you will get a ticket. To obtain a ticket, whlie on the SDU network (e.g., on eduroam), also use “kinit”. For NAT accounts:

kinit user@NAT.C.SDU.DK

and for non-NAT accounts:


Basically the same, but with a different domain.


The capitilisation of the part after “@” matters!


Currently it is not possible to get a ticket outside the SDU network, and therefore not possible to do passwordless login without typing your password once at some point.

Passwordless SSH

On the jump hosts and the computer lab machines, simply do ordinary SSH. From other machines, where you have a valid ticket, use the “-K” flag to forward your ticket. E.g.:

ssh -K


it seems that this actually doesn’t work at the moment.

If you use SSH-aliases in “.ssh/config” you can add ticket forwarding as default:


write it once it works, it should basically be adding “GSSAPIDelegateCredentials yes

Once you have a ticket on the target machine, then you have access to the ordinary “.ssh/authorized_keys” file, public/private key authentication will then work. That is, from outisde the SDU network, you must type your password once, and subsequent logins can be passwordless (through public/private keys).


Logging in with public/private key authentication will not renew your ticket.

Passwordless kinit

You can create a keytab file to locally store credentials for use with “kinit”. The file is completely location independent, but must be recreated when your Kerberos credentials change.


A keytab file should be regarded as a secret in the same way a private key should. That is, don’t give it away, and avoid transfering it out of a machine.

A keytab file is viewed and created using “ktutil”, and we here assume you are using the MIT Kerberos implementation (see also this). ktutil works by starting it and then typing commands inside it. For example:

addent -password -p user@NAT.C.SDU.DK -k 1 -e rc4-hmac
wkt mySecrets.keytab

which adds an entry for “user@NAT.C.SDU.DK” and then writes the actual keytab file to “mySecrets.keytab”. The keytab file can now be used to get a ticket without typing your password:

kinit username@NAT.C.SDU.DK -k -t mySecrets.keytab

If you have a class 3 office machine on the SDU network, you can now put this command in a cron job to make sure you always have a ticket.



If you do not have a personal IMADA website, just ignore this part.

The new home folders do not have your website mounted in “WWWpublic”. Instead you must log into the old system, e.g., on the machine where the files are physically stored:

Your website is then in “/home/www/Employees/username” (or “/home/www/Students/username” for TAs).


The old home folder will exist for some time, but if you have references from your website to your home folder you should rearrange stuff.

Note also that the old absolute path to files through your home folder will no longer work. If you have .htaccess and .htpasswd files, you may need to change paths in them.


Your website does not have access to your new home folder in any way.

Moving Files From the Old System

The old home folders will be available for some time, but you should copy/move files to the new system. You can copy files, e.g., by rsync from the old file server For example:

rsync --progress -avzi -e ssh old

to transfer your old home dir to a nested folder old.

IMADA Scripts

The following scripts are interdependent and meant to be in the same folder. Click here to get an archive with them.

  • layout: not a stand-alone script, but contains the names of all terminal room machines (updated October 13 2016, by Marco).
  • foreach: general script for executing commands for each machine. You probably want to use one of the other scripts.
  • getCores: make a file with computer names and number of cores in the CPUs. The file is used by the ping script.
  • ping: show a map of the terminal room with information about each machine.
  • doForeach: execute the given command sequentially on all machines.
  • doParallelForeach: execute the given command in parallel on all machines.