Shell und GuestOnCampus: Unterschied zwischen den Seiten
(Unterschied zwischen Seiten)
Zur Navigation springen
Zur Suche springen
imported>Burghardt |
imported>Burghardt |
||
Zeile 1: | Zeile 1: | ||
+ | Seit Anfang 2017 existiert das WLAN "<tt>GuestOnCampus</tt>". |
||
− | * '''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!''' Currently more than 30% of all users leave their idle session running for days and weeks :-( |
||
+ | == Nutzung == |
||
− | <!-- |
||
+ | Zur Authentifizierung genügt |
||
− | {| style="border: 1pt black dashed" |
||
+ | * ein "echter" Gwdg-Account |
||
− | |- |
||
+ | * ein Studierenden-Account |
||
− | | [[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]] |
||
+ | * ein Gäste-Account |
||
− | |- |
||
+ | ** zentral ausgestellt von einem Administrator |
||
− | |} |
||
+ | ** dezentral ausgestellt von ''irgendjemandem'' - Stichwort: "WLAN-Bürgschaft". Diese Person übernimmt dann auch die Verantwortung! |
||
− | --> |
||
+ | ;Achtung:das Netz ist '''nicht verschlüsselt''' - mit allen problematischen Konsequenzen. Verwenden Sie daher möglichst ein VPN. |
||
− | == Usage == |
||
− | ''Please read [[#2FA]] for initial setup.'' Then simply use SSH to login to this machine: |
||
+ | == Probleme == |
||
− | <big> |
||
+ | * manchmal scheint ein Browser-Restart notwendig zu sein. (Cacheprobleme?) |
||
− | ~# '''ssh username@shell.stud.informatik.uni-goettingen.de ''' |
||
+ | * beim Sponsoring scheint <tt>user@gwdg.de</tt> (für den Gast) nicht immer zu funktionieren. (Wozu auch? Der Nutzer soll <tt>Eduroam</tt> verwenden!) |
||
− | ####### shell.stud.informatik.uni-goettingen.de - login vm: shell5.cip.loc |
||
− | ... |
||
− | '''Verification code: ''' |
||
− | '''Password: ''' |
||
− | Welcome to Ubuntu 14.04.4 LTS (GNU/Linux 3.13.0-87-generic x86_64) |
||
− | username@shell5:~$ |
||
− | </big> |
||
− | === 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''. |
||
− | 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]] -- details and information regarding old/new (Trusty/Xenial) servers. |
||
− | + | == Links == |
|
+ | * https://voucher.gwdg.de/login/ -- freigeben von "gesponsorten" Zugängen |
||
− | These machines are meant to be used by students. But ''of course'' they can be used by all staff members! |
||
+ | * https://www.sub.uni-goettingen.de/neu-hier/internetzugang/ -- allgemeine Informationen |
||
− | 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]]. |
||
+ | * https://wiki.student.uni-goettingen.de/support/wlan/sub_gaeste -- zielt zwar auf die SUB, passt aber dennoch |
||
+ | * https://wlan.gwdg.de - leitet weiter an das captive-portal |
||
+ | * https://captive-portal.gwdg.de:8003/index.php?zone=wlan_gast # ohne Parameter klappt das nicht! # nur erreichbar solange ''nicht'' authentifiziert |
||
+ | * gwdg.de Dokumentation fehlt anscheinend noch... |
||
− | === 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> === |
||
− | 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 === |
||
− | * The session Timeout is set to '''36 hours''' -- this is the HAproxy related Timeout regarding the TCP connection |
||
− | * [[Kerberos]]/[[OpenAFS]] have separate/shorter timeouts, usually 10 hours. Please check with <tt>klist</tt>. You need to run <tt>kinit && aklog</tt> when you're approaching timeout |
||
− | |||
− | <!-- |
||
− | === 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> |
||
− | --> |
||
− | |||
− | == 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 == |
||
− | ''Two Factor Authentication'' -- '''required, not optional!''' |
||
− | |||
− | === 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) 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 [[#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 — 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 <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.) |
||
− | |||
− | ''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 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 <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" |
||
− | |- |
||
− | | [[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: |
||
− | ~$ head -n1 .ifi-login/.google_authenticator |
||
− | P2ZOMKQLEIC6SKCL |
||
− | |||
− | [[Image:winauth+putty.png|399px|right]] |
||
− | |||
− | * Android |
||
− | ** Play Store: "<tt>Google Authenticator</tt>". |
||
− | ** [[F-Droid]]: https://f-droid.org/app/com.google.android.apps.authenticator2 |
||
− | |||
− | * Linux |
||
− | ** 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 |
||
− | ** Authenticator |
||
− | |||
− | * Windows: |
||
− | ** WinAuth: https://github.com/winauth/winauth -- <small>direct download as of 06.2016: https://winauth.com/downloads/3.x/WinAuth-3.5.1.zip</small><br />This is an installation-free application, no setup and no administrative access needed. |
||
− | |||
− | * 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''. |
||
− | |||
− | |||
− | * 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> - Institute 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 |
||
− | ####### |
||
− | ####### 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 the 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 |
||
− | |||
− | == Todo == |
||
− | * <small>Nothing - everybody is happy!</small> |
||
− | <!-- |
||
− | * Testing! -- the current state is considered "BETA" |
||
− | * ssh-ed25519 |
||
− | --> |
||
− | <!-- * make Status Information publicly available? -- ''probably not'' --> |
||
− | <!-- * possibly require 2FA only from outside the Institute? -- ''Not decided yet'' --> |
||
− | |||
− | == See also == |
||
− | * [[Shell/Fingerprints]] -- details and information regarding old/new (Trusty/Xenial) servers. |
||
− | * [[Shell/2fa-example]] -- initialization sequence |
||
− | * [[Shell/Self Defense]] |
||
− | * [[2FA/Multiple]] -- use multiple identities |
||
− | * [[Remote Access]] |
||
− | * [[Long Running Processes]] -- leave processes running |
||
− | |||
− | == 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 |
||
− | * 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> |
||
− | --> |
||
+ | [[Kategorie:Netzwerk]] |
||
− | [[Category:Pool]][[Category:Remote]] |
Version vom 27. Februar 2017, 15:10 Uhr
Seit Anfang 2017 existiert das WLAN "GuestOnCampus".
Nutzung
Zur Authentifizierung genügt
- ein "echter" Gwdg-Account
- ein Studierenden-Account
- ein Gäste-Account
- zentral ausgestellt von einem Administrator
- dezentral ausgestellt von irgendjemandem - Stichwort: "WLAN-Bürgschaft". Diese Person übernimmt dann auch die Verantwortung!
- Achtung
- das Netz ist nicht verschlüsselt - mit allen problematischen Konsequenzen. Verwenden Sie daher möglichst ein VPN.
Probleme
- manchmal scheint ein Browser-Restart notwendig zu sein. (Cacheprobleme?)
- beim Sponsoring scheint user@gwdg.de (für den Gast) nicht immer zu funktionieren. (Wozu auch? Der Nutzer soll Eduroam verwenden!)
Links
- https://voucher.gwdg.de/login/ -- freigeben von "gesponsorten" Zugängen
- https://www.sub.uni-goettingen.de/neu-hier/internetzugang/ -- allgemeine Informationen
- https://wiki.student.uni-goettingen.de/support/wlan/sub_gaeste -- zielt zwar auf die SUB, passt aber dennoch
- https://wlan.gwdg.de - leitet weiter an das captive-portal
- https://captive-portal.gwdg.de:8003/index.php?zone=wlan_gast # ohne Parameter klappt das nicht! # nur erreichbar solange nicht authentifiziert
- gwdg.de Dokumentation fehlt anscheinend noch...