Aus Doc-Wiki

Wechseln zu: Navigation, Suche



Please read #2FA for initial setup. Then simply use SSH to login to this machine:

~$ ssh
####### - login vm: shell3.cip.loc
Verification code:  
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-72-generic x86_64)

Verify Key Fingerprint

The first time you connect to any ssh-reachable resource via network you need to verify the fingerprint of the actually used key and only then accept it.

SHA256 Fingerprints:

ECDSA   L+FCMj2bm8x/BfR8AdaaLnqTmFD35D0EYNlFG7a2dt8
ED25519 H4FLNG2aNYRZ3jxepIx5E0s0a2ZvtZbbmVLt56b+nK0
RSA     DpP5/EfbApVUwseVeQOVpAFvGiZIJmYmjUyC4Cnuatk 

In notation for older clients which are using the no longer recommended hash function MD5:

ECDSA   07:84:c9:e1:59:4f:03:75:69:b1:e4:d0:b4:1f:9a:cd
ED25519 93:11:29:c4:a2:03:e1:2d:b1:82:05:74:dd:a5:3b:9a 
RSA     de:db:6e:72:52:de:30:73:db:bb:6e:79:df:f9:2c:0d

Target audience

These machines are meant to be used by students. But of course they can be used by all staff members!

First time users: the only pre-condition is to logon one single time using one of the (physical) pool computers in our building - this will make you a "known user" to our systems. Only then you can (and must) walk through #2FA.


For Windows: use PuTTY (simple) or Cygwin (more complex and powerful) or any other SSH-implementation. Bash on Ubuntu on Windows works great too.

Load Balancing

In fact this term is misleading on this specific installation as it simply does "round-robin", at least for now. The important point is that you'll get connected to any currently available login machine. This will be the "next" machine one after another and probably not the same one as one session before. If you landed on an overcrowded system simply disconnect/reconnect to use another machine.


Self defense of these servers

Only relevant if your system fails to connect with errors like Server not reachable: Shell/Self Defense


Two Factor Authentication -- required, not optional!


We use the well known google-authenticator to add a second factor as a requirement for (ssh-) logins. First you will get prompted for a "Verification code:". Then you'll get a second prompt asking for your normal password.

The "Verification Code" changes every minute. This approach is called TOTP = Time-based One Time Password.

(Do not try to use "Counter based OTP". It might work first, but it will do so only for a short while! We are using copies of the secret file. State updates required by the incremental counter strategy are not written back. Authentication will fail after reaching the windows size.)

The order of both inputs is relevant: if an attacker manages to crack the first element (being the TOTP) he has a benefit for some minutes only. If we would ask for the Password first then the benefit of cracking the first element gives advantages probably for a very long time.

You need to have a compatible generator - usually implemented as a small application.

Please note that often this approach is associated with a specific implementation: the Google Authenticator. This is misleading as there are other 100% compatible implementations. See also RFC 6238.


Before you can use this technology the first time you need to prepare your personal secret credentials. You do this by using a simple command line tool and answering some questions.

Of course you can not do this on these shellX-machines as you can not login successfully yet — this is the classic chicken-and-egg problem. Use one of the physical pool computers for this!

(Your personal/private computer is probably not an option as you need access to your OpenAFS $HOME. If you do have access you might need to install the software by apt-get install libpam-google-authenticator which contains the required binary.)

The following instructions are copy-n-pastable as the commands are relative to anyones $HOME-folder.

~$ google-authenticator      
Do you want authentication tokens to be time-based (y/n) y
... # For full output see Shell/2fa-example

Create dedicated sub-directory

For new accounts the folder .ifi-login is created automatically on first login. If it actually exists already you can skip nearly this complete block and jump to the next section #Move_credential_file with the mv .google_authenticator-command.

A successful check:

~$ file .ifi-login
.ifi-login: directory

A missing folder gives:

~$ file .ifi-login
.ifi-loginx: cannot open `.ifi-login' (No such file or directory)

Due to some unusual behavior of OpenAFS regarding access rights (they work only on directories, not on files) we need to move that file into another, dedicated subdirectory. This man page explains the access rights mechanism and how to manipulate access-control-lists:

~$ man fs_setacl

First you need to create that directory. A special user with the name ifi-login needs to have read access to the files in the directory .ifi-login inside of your $HOME. To be able to reach into that directory he needs to "walk through" your home folder. The third line is required to make this possible by granting "l"="list" access rights to your $HOME:

~$ mkdir .ifi-login     
~$ fs sa -dir .ifi-login -acl ifi-login read 
~$ fs sa -dir . -acl ifi-login l

Be aware that we are working with "dotfiles": both .ifi-login & .google_authenticator begin with a "." and are usually hidden from users eye. To see them use ls -a.

As usual access rights are inherited. For this reason there are more rights granted than required. You might remove them now by commands like

~$ fs sa -dir .ifi-login -acl mta none
~$ fs sa -dir .ifi-login -acl spamassassin none
~$ fs sa -dir .ifi-login -acl web-home none

You can always check the current settings. At the end it may look like this:

~$ fs la .ifi-login
Access list for .ifi-login is
Normal rights:
 system:administrators rlidwka
 username rlidwka
 username.system rl
 ifi-login rl    # this is the important one (in this context) 

WARNING: do not remove rights if you are not absolutely sure they are not needed. It is very easy to remove too many rights, leaving you with a directory that is not usable anymore!

Move credential file

Now move the created credential file into that new destination:

~$ mv .google_authenticator .ifi-login/

Please remember to repeat this step if you modify/recreate your configuration!


Diamond-caution.png The system time is used equivalent to a shared secret! Make sure your clock is set correctly or all generated codes will fail.

For all generators you need the secret created above. You can use any tool you want to look into the file .ifi-login/.google_authenticator. A one-liner which outputs only the "secret" is this:

~$ head -n1 .ifi-login/.google_authenticator 
~$ oathtool --totp -b $(head -n1 .ifi-login/.google_authenticator)

Tips 'n' Tricks

Connecting to a specific machine

Circumventing the Round-Robin mechanism is possible by connecting to a specific port 42000+n with n={1..6}. The example connects to machine number 4:

~$ ssh -p 42004
####### - login vm: shell4.cip.loc

If you already have a shell inside the Institute this is much easier to achieve. This just works:

~$ ssh user@shell4.cip.loc 
####### - login vm: shell4.cip.loc

Duplicate your Generators

It is absolutely fine to have a well configured generator on every single device you own. Remember: without the second factor you can not login. That's the goal of the whole shebang after all.

Write down your Emergency codes

Remember the console output during creation of the secret? "Your emergency scratch codes are:...". Write them down (or print them) and put that piece of paper into your pocket...

Credential problems


Please give feedback via feedback(ät) For problem reports: please include always information about your system:


See also


Meine Werkzeuge