Shell: Unterschied zwischen den Versionen

Aus Doc-Wiki
Zur Navigation springen Zur Suche springen
imported>Burghardt
 
(229 dazwischenliegende Versionen von 9 Benutzern werden nicht angezeigt)
Zeile 1: Zeile 1:
  +
* '''Alternative''': There is a new installation script. Just run: <tt>setup-cip-2fa</tt> on shellinit.
  +
* '''Alternative (Teil-) Anleitung''' von C. Damm [https://univz.uni-goettingen.de/qisserver/rds?state=verpublish&status=init&vmfile=no&moduleCall=webInfo&publishConfFile=webInfoPerson&publishSubDir=personal&keep=y&purge=y&personal.pid=8786] in deutscher Sprache: https://user.informatik.uni-goettingen.de/~damm/info1/aktuell/2FA.html
  +
* Please '''do log out when you have finished your work!'''
  +
  +
<!--
 
{| style="border: 1pt black dashed"
 
{| style="border: 1pt black dashed"
 
|-
  
|-
−
| [[Image:Diamond-caution.png]] || Beta Test. Please give feedback. || [[Image:Diamond-caution.png]]
 +
| [[Image:Diamond-caution.png]] || '''Beta Test!''' Please give feedback via '''<tt>feedback(ät)informatik.uni-goettingen.de</tt>'''<br /><small>For problem reports: please include ''always'' information about your system - ''at least'' the exact date+time, your IP address, your user id, what you ''wanted'' to accomplish, what you ''did'' and what happened ''instead''.<br />To remove this warning I need some ''positive'' feedback first...</small>|| [[Image:Diamond-caution.png]]
 
|-
  
|-
 
|}
  
|}
  +
-->
−  
   
   
 
== Usage ==
  
== Usage ==
−
Simply use SSH to login to this machine:
 +
''Please read [[#2FA]] for initial setup.'' Then simply use SSH to login to this machine:
  +
 
<big>
  
<big>
−
'''ssh user@shell.stud.informatik.uni-goettingen.de'''
 +
~$ '''ssh userid@shell.stud.informatik.uni-goettingen.de'''
  +
...
  +
####### shell.stud.informatik.uni-goettingen.de - login vm: shell3.cip.loc
  +
...
  +
'''Verification code:'''
  +
'''Password:'''
  +
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-72-generic x86_64)
  +
...
  +
userid@shell3:~$
 
</big>
  
</big>
−
Note that the intially presented banner contains something like
  
   
  +
If you get a intentionally non-descriptive error message like
−
####### shell.stud.informatik.uni-goettingen.de - login vm: '''shell5.cip.loc'''
  
  +
~$ ssh userid@shell
−
...telling you the actual local name of the automatically chosen destination machine.
 
  +
##
  +
/usr/local/sbin/fetch-secrets failed: exit code 12
  +
...you did not prepare the file <tt>.google_authenticator</tt> as required. Please check your setup.
   
   
  +
=== Verify Key Fingerprint ===
−
For '''Windows''': use [[PuTTY]] (simple) or [[Cygwin]] (more complex and powerful) or any other SSH-implementation.
  
  +
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
  +
  +
* [[Shell/Fingerprints]] -- more details and an example on how it actually looks in a shell and on PuTTY on Windows
   
 
=== Target audience ===
  
=== Target audience ===
−
These machines are meant to be used by students. But ''of course'' they can be used by any staff members! (For first time users: the only requirement 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.)
 +
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]]. (Alternatively: "ssh shellinit.informatik", see below.)
−
=== Load Balancing ===
  
−
This term is misleading on this specific installation: the default algorithm being used is simply "round-robin" - you'll get connected to the "next" machine one after another. If you landed on an overcrowded system simply disconnect/reconnect to use another machine.
  
   
  +
=== Windows ===
  +
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.
  +
<!--
 
=== Legacy <tt>login.stud</tt> ===
  
=== Legacy <tt>login.stud</tt> ===
 
Both <tt>login.stud.informatik.uni-goettingen.de</tt> and <tt>login.informatik.uni-goettingen.de</tt> (for staff only) are not affected by this new approach. These "old" machines will continue to work unmodified.
  
Both <tt>login.stud.informatik.uni-goettingen.de</tt> and <tt>login.informatik.uni-goettingen.de</tt> (for staff only) are not affected by this new approach. These "old" machines will continue to work unmodified.
  +
-->
   
 
=== Timeout ===
  
=== Timeout ===
−
* The session Timeout is set to '''36 hours''' -- this is the HAproxy related Timeout regarding the TCP connection
 +
* The session Timeout is set to '''3 hours''' -- this is the HAproxy related Timeout regarding an ''inactive'' connection
−
* [[Kerberos]]/[[OpenAFS]] have separate/shorter timeouts. You need to <tt>kinit && aklog</tt> when you're approaching timeout
 +
* [[Kerberos]]/[[OpenAFS]] has separate timeouts, usually 10 hours. Please check with <tt>klist</tt>. You may run <tt>kinit && aklog</tt> if you're approaching timeout
   
 
<!--
  
<!--
 
=== Availability ===
  
=== Availability ===
 
The goal - ''of course'' - is 24/7. Take a look at: http://shell.stud.informatik.uni-goettingen.de/ -- use <tt>ifi</tt>/<tt>ifi</tt> to login <small>("bots not welcome")</small>
  
The goal - ''of course'' - is 24/7. Take a look at: http://shell.stud.informatik.uni-goettingen.de/ -- use <tt>ifi</tt>/<tt>ifi</tt> to login <small>("bots not welcome")</small>
−
--!
 +
-->
   
  +
== Self defense of these servers ==
  +
Only relevant if your system fails to connect with errors like <tt>Server not reachable</tt>: [[Shell/Self Defense]]
   
  +
== 2FA ==
−
== Self defense of the servers ==
  
  +
''Two Factor Authentication'' -- '''required, not optional!'''
−
Usually we do utilize "<tt>fail2ban</tt>" to chase brute force attacks by bad guys trying to hack login credentials. For technical reasons this is not possible for this "<tt>haproxy</tt>" approach. The workaround is:
  
   
  +
=== Concept ===
  +
We use the well known <tt>google-authenticator</tt> 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 = '''T'''ime-based '''O'''ne '''T'''ime '''P'''assword.
  +
  +
<small>(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.) </small>
  +
  +
The order of both inputs is relevant: if an attacker manages to crack the first element (being the TOTP) they 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 [[#Generators|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.
  +
  +
=== Initialization ===
  +
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 &mdash; this is the classic chicken-and-egg problem.
  +
  +
You have two options to setup your account for 2FA:
  +
* using one of the physical pool computers
  +
* login using SSH to the server '''shellinit.informatik.uni-goettingen.de'''
  +
** You need to be in the network of the University e.g. Eduroam. From outside first establish a connection using VPN https://info.gwdg.de/docs/doku.php?id=en:services:network_services:vpn:start )
  +
** shellinit has a ''very'' limited instruction set. Only absolutely required commands are available
  +
  +
(Your personal/private computer is probably ''not'' an option as you need access to your OpenAFS <tt>$HOME</tt>. If you ''do'' have access you might need to install the software by <tt>apt-get install libpam-google-authenticator</tt> which contains the required binary.)
  +
  +
As an alternative to the following process you can also run this command:
  +
  +
setup-cip-2fa
  +
  +
''The following instructions are copy-n-pastable as the commands are relative to anyones <tt>$HOME</tt>-folder. ''
  +
  +
~$ '''google-authenticator'''
  +
Do you want authentication tokens to be time-based (y/n) '''y'''
  +
... <small># For full output see [[Shell/2fa-example]]</small>
  +
  +
=== Create dedicated sub-directory ===
  +
  +
For '''new''' accounts the folder <tt>.ifi-login</tt> 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 <tt>mv .google_authenticator</tt>-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 (<small>they work ''only'' on directories, not on files</small>) 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 <tt>ifi-login</tt> needs to have read access to the files in the directory <tt>.ifi-login</tt> inside of your <tt>$HOME</tt>. To be able to reach into that directory they needs to "walk through" your home folder. The third line is required to make this possible by granting "l"="list" access rights to your <tt>$HOME</tt>:
  +
~$ 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 <tt>.ifi-login</tt> & <tt>.google_authenticator</tt> begin with a "." and are usually ''hidden'' from users eye. To see them use '''<tt>ls -a</tt>'''.
  +
  +
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!
  +
  +
=== Generators ===
 
{| style="border: 1pt black dashed"
 
{| style="border: 1pt black dashed"
 
|-
  
|-
−
| [[Image:Diamond-caution.png]] || We do limit the rate of ''new'' <tt>ssh</tt>- (<tt>tcp</tt>-) connections from any given source IP address to 1 per minute.|| [[Image:Diamond-caution.png]]
 +
| [[Image: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 <tt>.ifi-login/.google_authenticator</tt>. A one-liner which outputs ''only'' the "secret" is this:
−
When you're going to login via ssh you usually have three tries to enter your password. Technically this is just ''one'' single connection! The next three tries come with the next connection, which is only possible after one minute. Trying to to log in too early gives just a generic error message:
  
  +
~$ head -n1 .ifi-login/.google_authenticator
  +
P2ZOMKQLEIC6SKCL
   
  +
[[Image:winauth+putty.png|399px|right]]
−
~# ssh username@shell.stud.informatik.uni-goettingen.de
  
−
ssh_exchange_identification: read: Connection reset by peer
  
   
  +
* Android
−
This behavior should be fine for most users where each one has a different IP address than other people.
 
  +
** Play Store: "<tt>Google Authenticator</tt>".
  +
** [[F-Droid]]: https://f-droid.org/app/com.google.android.apps.authenticator2
   
  +
* Linux
−
If you are a group of students behind NAT this could be a problem. We need yet to find out if this might be a problem for students residential establishment in Göttingen.
  
  +
** install <tt>oathtool</tt> to get some compatible command line utilities. Then this works:
  +
~$ oathtool --totp -b $(head -n1 .ifi-login/.google_authenticator)
  +
123456
   
  +
* Ubuntu Touch
−
== Tips 'n' Tricks ==
  
  +
** Authenticator
   
  +
* Windows:
−
=== Connect to a specific machine ===
  
  +
** WinAuth: https://github.com/winauth/winauth -- This is an installation-free application, no setup and no administrative access needed.
−
Circumventing the Round-Robin mechanism is possible: connect to a specific port <tt>42000+''n''</tt> with <tt>''n''={1..6}</tt> :-)
  
   
  +
* Windows Phone:
−
For machine number 4:
  
  +
** Token2: free application from Microsoft Store. The QR-Code seems to be incompatible, so you need to type in your secret manually. Nevertheless: ''it works''.
  +
  +
  +
* OS agnostic
  +
** [[Chromium]] Browser: GAuth application
  +
** https://5apps.com/gbraad/gauth -- direct use web-application (think twice!) & application for Chrome and Firefox
  +
  +
== Tips 'n' Tricks ==
  +
  +
=== Connecting to a specific machine ===
  +
<!--
  +
If you are trying to connect to the ''same machine as last time'' (for example to execute [[Long Running Processes]]) you need to connect from a ''semi-local source address'' which includes:
  +
* <tt>134.76.0.0/16</tt> - official Gönet address space
  +
* <tt>10.0.0.0/8</tt> - official gönet-wide routed RFC1918 address space
  +
* <tt>172.16.0.0/12</tt> - the Institute's local address space
  +
In this case -->Circumventing the Round-Robin mechanism is possible by connecting to a specific port <tt>42000+''n''</tt> with <tt>''n''={1..6}</tt>. The example connects to machine number 4:
 
 
 
~$ ssh -p 42004 username@shell.stud.informatik.uni-goettingen.de
  
~$ ssh -p 42004 username@shell.stud.informatik.uni-goettingen.de
 
#######
  
#######
 
####### shell.stud.informatik.uni-goettingen.de - login vm: shell4.cip.loc
  
####### shell.stud.informatik.uni-goettingen.de - 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
  +
#######
  +
####### shell.stud.informatik.uni-goettingen.de - login vm: shell4.cip.loc
  +
  +
<!--
  +
=== "knocking" not required from ''inside'' the Institute ===
  +
If your are ''inside'' the Institute's LAN then there is no need to take the main entrance. You can circumvent the need to knock at the front door by connecting to the <tt>shellX</tt>-machines directly:
  +
~$ ssh 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 this whole shebang after all.
  +
  +
=== Write down your Emergency codes ===
  +
Remember the console output during creation of the secret? "<tt>Your emergency scratch codes are:...</tt>". Write them down (or print them) and put that piece of paper into your pocket...
  +
  +
=== Credential problems ===
  +
* the actual password is '''not stored anywhere''' in Institute's systems
  +
** students: [[StudIT]] - https://wiki.student.uni-goettingen.de/support/account/passwort
  +
** staff: [[Gwdg]] - https://info.gwdg.de/faq/index.php?action=artikel&cat=52&id=215&artlang=de - Institute's Admins will help as we have some administrative access. While we can not tell you your password we can ''reset'' it
  +
  +
* problems with the Verification Code: simply start again with [[#Initialization]] and overwrite <tt>~/.ifi-login/.google_authenticator</tt>. You need to re-configure ''all'' of your [[#Generators]] of course
  +
  +
=== Feedback ===
  +
Please give feedback via '''<tt>feedback(ät)informatik.uni-goettingen.de</tt>'''. '''For problem reports:''' please include ''always'' information about your system:
  +
* the exact date+time, your IP address and your user id
  +
* the local Operating System and the used software you are using. (PuTTY? Which code generator?)
  +
* what you ''wanted'' to accomplish, what you actually ''did'' and what happened ''instead'' of the expected result. Try to supply a transscript of your session - this means input ''and'' output
  +
  +
=== Reset / fresh restart ===
  +
To ''delete'' old configuration is ''required'' only if those secrets are compromised, if a third person had access to it.
  +
  +
This is ''not'' necessary if you've lost your one and only generator. (Prepare more than one to avoid this scenario!)
  +
  +
To get access to the existing configuration you may use
  +
  +
ssh userid@shellinit.informatik.uni-goettingen.de
  +
  +
for this purpose. Note that this specific machine is reachable only from inside GÖNET.
  +
  +
* RESET
  +
If you actually want to ''reset'' your configuration simply execute the steps under [[Shell#Initialization]] again.
  +
  +
* ERASE your configuration
  +
You might delete the files <tt>~/.google_authenticator</tt> and all files in the folder <tt>~/.ifi-login/*</tt> to do so. Please note that instances of our Shell-machines might cache your old configuration files until they get rebootet.
   
 
== Todo ==
  
== Todo ==
  +
* <small>Nothing</small>
−
* Testing! -- current state considered "BETA"
  
  +
<!-- * make Status Information publicly available? -- ''probably not'' -->
  +
<!-- * possibly require 2FA only from outside the Institute? -- ''Not decided yet'' -->
   
 
== See also ==
  
== See also ==
  +
* [[Shell/Fingerprints]] -- more details and an example on how it actually looks in a shell and on PuTTY on Windows
  +
* [[Shell/2fa-example]] -- initialization sequence
  +
* [[Shell/Self Defense]]
  +
* [[2FA/Multiple]] -- use multiple identities
 
* [[Remote Access]]
  
* [[Remote Access]]
−
* [[Long Running Processes]]
 +
* [[Long Running Processes]] -- leave processes running
  +
* [[SSH Key]] -- usage ''not'' possible
−  
   
 
== Links ==
  
== Links ==
  +
* https://user.informatik.uni-goettingen.de/~damm/info1/aktuell/2FA.html -- '''Alternative (Teil-) Anleitung''' von C. Damm[https://univz.uni-goettingen.de/qisserver/rds?state=verpublish&status=init&vmfile=no&moduleCall=webInfo&publishConfFile=webInfoPerson&publishSubDir=personal&keep=y&purge=y&personal.pid=8786] in deutscher Sprache
−
* ...
  
  +
* https://tools.ietf.org/html/rfc6238
  +
* https://github.com/google/google-authenticator
  +
 
<!--
  
<!--
  +
* https://en.wikipedia.org/wiki/Port_knocking
 
* https://help.ubuntu.com/ -- common help regarding Ubuntu
  
* https://help.ubuntu.com/ -- common help regarding Ubuntu
 
* http://shell.stud.informatik.uni-goettingen.de/ -- current state of the load balancer. Use <tt>ifi</tt>/<tt>ifi</tt> to login <small>''("bots not welcome")''</small>
  
* http://shell.stud.informatik.uni-goettingen.de/ -- current state of the load balancer. Use <tt>ifi</tt>/<tt>ifi</tt> to login <small>''("bots not welcome")''</small>

Aktuelle Version vom 11. Oktober 2023, 22:29 Uhr


Usage

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

~$ ssh userid@shell.stud.informatik.uni-goettingen.de
...
#######  shell.stud.informatik.uni-goettingen.de - login vm: shell3.cip.loc
...
Verification code:  
Password: 
Welcome to Ubuntu 16.04.2 LTS (GNU/Linux 4.4.0-72-generic x86_64)
...
userid@shell3:~$

If you get a intentionally non-descriptive error message like 

~$ ssh  userid@shell
##
/usr/local/sbin/fetch-secrets failed: exit code 12

...you did not prepare the file .google_authenticator as required. Please check your setup.


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
  • Shell/Fingerprints -- more details and an example on how it actually looks in a shell and on PuTTY on Windows

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. (Alternatively: "ssh shellinit.informatik", see below.)

Windows

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.

Timeout

  • The session Timeout is set to 3 hours -- this is the HAproxy related Timeout regarding an inactive connection
  • Kerberos/OpenAFS has separate timeouts, usually 10 hours. Please check with klist. You may run kinit && aklog if you're approaching timeout


Self defense of these servers

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

2FA

Two Factor Authentication -- required, not optional!

Concept

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) they 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.

Initialization

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.

You have two options to setup your account for 2FA:

  • using one of the physical pool computers
  • login using SSH to the server shellinit.informatik.uni-goettingen.de

(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.)

As an alternative to the following process you can also run this command: 

setup-cip-2fa

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 they 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!

Generators

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 
P2ZOMKQLEIC6SKCL
Winauth+putty.png
  • Linux
    • install oathtool to get some compatible command line utilities. Then this works:
~$ oathtool --totp -b $(head -n1 .ifi-login/.google_authenticator)
123456
  • Ubuntu Touch
    • Authenticator
  • Windows Phone:
    • Token2: free application from Microsoft Store. The QR-Code seems to be incompatible, so you need to type in your secret manually. Nevertheless: it works.


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 username@shell.stud.informatik.uni-goettingen.de
#######
#######  shell.stud.informatik.uni-goettingen.de - 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 
#######
#######  shell.stud.informatik.uni-goettingen.de - 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 this 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

  • problems with the Verification Code: simply start again with #Initialization and overwrite ~/.ifi-login/.google_authenticator. You need to re-configure all of your #Generators of course

Feedback

Please give feedback via feedback(ät)informatik.uni-goettingen.de. For problem reports: please include always information about your system:

  • the exact date+time, your IP address and your user id
  • the local Operating System and the used software you are using. (PuTTY? Which code generator?)
  • what you wanted to accomplish, what you actually did and what happened instead of the expected result. Try to supply a transscript of your session - this means input and output

Reset / fresh restart

To delete old configuration is required only if those secrets are compromised, if a third person had access to it.

This is not necessary if you've lost your one and only generator. (Prepare more than one to avoid this scenario!)

To get access to the existing configuration you may use 

	ssh  userid@shellinit.informatik.uni-goettingen.de

for this purpose. Note that this specific machine is reachable only from inside GÖNET.

  • RESET

If you actually want to reset your configuration simply execute the steps under Shell#Initialization again.

  • ERASE your configuration

You might delete the files ~/.google_authenticator and all files in the folder ~/.ifi-login/* to do so. Please note that instances of our Shell-machines might cache your old configuration files until they get rebootet.

Todo

  • Nothing

See also

Links

Abgerufen von „https://doc.informatik.uni-goettingen.de/wiki/index.php?title=Shell&oldid=1339“