Shell: Unterschied zwischen den Versionen
imported>Burghardt (→2FA) |
imported>Burghardt |
||
| Zeile 146: | Zeile 146: | ||
Befor you can use this technology the first time you need to prepare your personal secret credentials. You do this by using a tool with a surprising name and answering the questiuons: |
Befor you can use this technology the first time you need to prepare your personal secret credentials. You do this by using a tool with a surprising name and answering the questiuons: |
||
| − | ~$ google-authenticator |
+ | ~$ '''google-authenticator''' |
Do you want authentication tokens to be time-based (y/n) y |
Do you want authentication tokens to be time-based (y/n) y |
||
... |
... |
||
# For full output see [[Shell/2fa-example]] |
# For full output see [[Shell/2fa-example]] |
||
| + | Due to some unusual behaviour of OpenAFS regarding access rights we need to move that file into a different, dedicated subdirectory. The 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 that directory. 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: |
||
| + | ~$ mkdir .ifi-login |
||
| + | ~$ fs sa -dir .ifi-login -acl ifi-login read |
||
| + | ~$ fs sa -dir . -acl ifi-login l |
||
| + | 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 |
||
| + | 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! |
||
| + | |||
| + | Now move the created credential file into that new destination: |
||
| + | ~$ mv .google_authenticator .ifi-login/ |
||
| + | |||
| + | Please remember to repeat this step if you modify your configuration! |
||
| + | |||
| + | When everything went fine you can now login with your two factors: |
||
| + | |||
| + | |||
| + | ==== Error Messages ==== |
||
| + | If the above preparation did not result in a valid setup ''and you've entered the '''correct''' password'' - you will get an error message like: |
||
| + | |||
| + | ... |
||
| + | ## |
||
| + | Password: |
||
| + | /usr/local/sbin/fetch-secrets failed: exit code 12 |
||
==== Problems ==== |
==== Problems ==== |
||
Version vom 13. Juni 2016, 14:58 Uhr
 |
Beta Test. 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, your user id, what you wanted to accomplish, what you did and what happened instead. Currently most important topic: #Port_knocking Second most topic: moving away from knocking - going #2FA |
|
Usage
Please read #Port_knocking if you can not connect.
Simply use SSH to login to this machine:
ssh user@shell.stud.informatik.uni-goettingen.de
Note that the intially presented banner contains something like
####### shell.stud.informatik.uni-goettingen.de - login vm: shell5.cip.loc
...telling you the actual local name of the automatically chosen destination machine.
For Windows: use PuTTY (simple) or Cygwin (more complex and powerful) or any other SSH-implementation.
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.)
Load Balancing
While this term is misleading on this specific installation (as it does simple "round-robin") the important point is that you'll get connected to any 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 36 hours -- this is the HAproxy related Timeout regarding the TCP connection
- Kerberos/OpenAFS have separate/shorter timeouts, usually 10 hours. Please check with klist. You need to run kinit && aklog when you're approaching timeout
Self defense of these servers
There used to be some other mechanisms. The only one left currently is "Port knocking"
Port knocking
For security reasons a "port knocking daemon" got installed. It works like a secret knocking sequence at the door of a conspiracy meeting: only after you have successfully performed that secret sequence the door is opened for a moment. In our technical context this means that the listening sshd is reachable for 300 seconds after knocking...
|
Secret: 33778 • 22999 • 44333 |
|
|
This approach will get removed during the next days... |
|
Successfully triggering is possible using a variety of software tools:
Linux
If you are using Linux and the package knockd is actually installed (which is not a requirement!) you can use this one-liner to log in:
~$ knock shell.stud.informatik.uni-goettingen.de 33778 22999 44333 && sleep 1; ssh username@shell.stud.informatik.uni-goettingen.de
If this fails try a slower version:
~$ knock shell.stud.informatik.uni-goettingen.de 33778; knock shell.stud.informatik.uni-goettingen.de 22999; knock shell.stud.informatik.uni-goettingen.de 44333 && sleep 1; ssh username@shell.stud.informatik.uni-goettingen.de
Without having the package knockd installed: telnet to the rescue!
~$ telnet shell.stud.informatik.uni-goettingen.de 33778 ~$ telnet shell.stud.informatik.uni-goettingen.de 22999 ~$ telnet shell.stud.informatik.uni-goettingen.de 44333 ~$ ssh username@shell.stud.informatik.uni-goettingen.de
Windows
- There are dedicated tools available for this purpose. This one is tested and found to work as expected: https://sourceforge.net/projects/knockknock/
The zip-file contains a (surprisingly small) executable. It is usable without installation, so you do not need Admin privileges - Use a web browser to tickle those ports
- telnet is included in Windows also, but unfortunately it seems not to work reliably. During reproducible tests the third knock did not reach the server while the first two were handled correctly
Android
"Port Knocker" via F-Droid: It is recommended to integrate that repository by installing https://f-droid.org/FDroid.apk. A direct link to the relevant package is: https://f-droid.org/repo/com.xargsgrep.portknocker_8.apk
This tool allows an arbitrary application to launch automatically after knocking. Tested successfully with ConnectBot.
OS agnostic Web Browser
Create a new folder for these bookmarks. Prepare three Bookmarks:
Of course you will end up running into a timeout as there is no webserver listening. You do not have to wait for timeout; simply cancel loading...
You can "click" them one after another. Browsers like Firefox offer a context menu entry "Alle in Tabs öffnen"/"Open all bookmarks" which tries to do what it says. You need to close all three of them one by one though.
2FA
Two Factor Authentication -- Not activated yet (except on shell4)
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 your regular password. Then you'll get a second prompt asking for a "Verification Code". This code changes every minute.
This approach is called TOTP = Time-based One Time Passoword. (Just for reference: the usual alternative is "HOTP", Hash-base OTP. For this one you need a YubiKey or an RSA-Token.)
You need to have a corresponding generator - usually implemented as a small application...
Prior usage
Befor you can use this technology the first time you need to prepare your personal secret credentials. You do this by using a tool with a surprising name and answering the questiuons:
~$ google-authenticator Do you want authentication tokens to be time-based (y/n) y ... # For full output see Shell/2fa-example
Due to some unusual behaviour of OpenAFS regarding access rights we need to move that file into a different, dedicated subdirectory. The 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 that directory. 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:
~$ mkdir .ifi-login ~$ fs sa -dir .ifi-login -acl ifi-login read ~$ fs sa -dir . -acl ifi-login l
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
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!
Now move the created credential file into that new destination:
~$ mv .google_authenticator .ifi-login/
Please remember to repeat this step if you modify your configuration!
When everything went fine you can now login with your two factors:
Error Messages
If the above preparation did not result in a valid setup and you've entered the correct password - you will get an error message like:
... ## Password: /usr/local/sbin/fetch-secrets failed: exit code 12
Problems
- how do scripts handle this?
Additionally...
If you have problems to login take a look at this page. These security aspects are definitely a work in progress and probably the final state is not reached yet...
Tips 'n' Tricks
Connect to a specific machine
Circumventing the Round-Robin mechanism is possible: connect to a specific port 42000+n with n={1..6} :-)
For 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 shellX-machines directly:
~$ ssh shell4.cip.loc
Todo
- Testing! -- the current state is considered "BETA"
- make Status Information publicly available
See also