Shell: Unterschied zwischen den Versionen
imported>Burghardt |
imported>Burghardt |
||
| Zeile 38: | Zeile 38: | ||
== Self defense of the servers == |
== Self defense of the servers == |
||
| − | Usually we do utilize "<tt>fail2ban</tt>" to chase brute force |
+ | 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: |
{| style="border: 1pt black dashed" |
{| style="border: 1pt black dashed" |
||
|- |
|- |
||
| − | | [[Image:Diamond-caution.png]] || We do limit the rate of new (<tt>tcp |
+ | | [[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]] |
|- |
|- |
||
|} |
|} |
||
| − | When you're going to login via ssh you usually have three tries to enter your password. Technically this is ''one'' single connection! The next three tries come with the next connection, which is only possible after one minute. |
+ | 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: |
~# ssh username@shell.stud.informatik.uni-goettingen.de |
~# ssh username@shell.stud.informatik.uni-goettingen.de |
||
ssh_exchange_identification: read: Connection reset by peer |
ssh_exchange_identification: read: Connection reset by peer |
||
| − | This behavior should be fine for |
+ | This behavior should be fine for most users where one person has a different IP address than other people. |
If you are a group of students behind NAT this would be a problem. We need yet to find out if this might be a problem for students residential establishment in Göttingen. |
If you are a group of students behind NAT this would be a problem. We need yet to find out if this might be a problem for students residential establishment in Göttingen. |
||
Version vom 31. Mai 2016, 08:15 Uhr
 |
Beta Test. Please give feedback. |
|
Usage
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
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.
Legacy login.stud
Both login.stud.informatik.uni-goettingen.de and login.informatik.uni-goettingen.de are not affected by this new approach. They "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. You need to kinit && aklog when you're approaching timeout.
Availability
Take a look at: http://shell.stud.informatik.uni-goettingen.de/ -- use ifi/ifi to login ("bots not welcome")
Self defense of the servers
Usually we do utilize "fail2ban" to chase brute force attacks by bad guys trying to hack login credentials. For technical reasons this is not possible for this "haproxy" approach. The workaround is:
|
We do limit the rate of new ssh- (tcp-) connections from any given source IP address to 1 per minute. |
|
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:
~# ssh username@shell.stud.informatik.uni-goettingen.de ssh_exchange_identification: read: Connection reset by peer
This behavior should be fine for most users where one person has a different IP address than other people.
If you are a group of students behind NAT this would be a problem. We need yet to find out if this might be a problem for students residential establishment in Göttingen.
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
Todo
- Documentation
- Testing! -- currently in BETA
See also
Links
- https://help.ubuntu.com/ -- common help regarding Ubuntu
- http://shell.stud.informatik.uni-goettingen.de/ -- current state of the load balancer. Use ifi/ifi to login ("bots not welcome")