Remote Access und Shell: Unterschied zwischen den Seiten

Aus Doc-Wiki
(Unterschied zwischen Seiten)
Zur Navigation springen Zur Suche springen
imported>Burghardt
 
imported>Burghardt
 
Zeile 1: Zeile 1:
  +
{| style="border: 1pt black dashed"
⚫
== Goal ==
 
  +
|-
−
You might want to use our pool infrastructure - which means any pool client <tt>c001</tt> to <tt>c048</tt> - from a remote location, for example from home. This is totally fine!
  
  +
| [[Image:Diamond-caution.png]] || Beta Test. Please give feedback. || [[Image:Diamond-caution.png]]
  +
|-
  +
|}
   
⚫
== Strategy ==
  
−
Currently (end of 2015) there are exactly two systems reachable from the outside world:
  
   
−
;login.stud.informatik.uni-goettingen.de: usable by every student. The only precondition is that you need to login ''one time'' physically on a client ''before'' attempting remote access
  
−
;login.informatik.uni-goettingen.de: usable ''only'' by staff members with [[Gwdg]]-Account
  
   
  ⚫
== Usage ==
−
The login server <tt>login.stud.informatik.uni-goettingen.de</tt> is meant to be used as a gateway from the outside world to the pool - basically to any computer <tt>c001</tt> to <tt>c048</tt>.
 
  +
Simply use SSH to login to this machine:
  +
<big>
  +
'''ssh user@shell.stud.informatik.uni-goettingen.de'''
  +
</big>
  +
Note that the intially presented banner contains something like
   
  +
####### shell.stud.informatik.uni-goettingen.de - login vm: '''shell5.cip.loc'''
−
This gateway approach is necessary as the pool computers have local, non-routeable IP-addresses like 172.27.x.y.
  
  +
...telling you the actual local name of the automatically chosen destination machine.
   
−
For accomplishing access to a pool machine you need to "hop" forward one time. On login you'll see a list of currently running computers. E.g.:
  
   
  +
For '''Windows''': use [[PuTTY]] (simple) or [[Cygwin]] (more complex and powerful) or any other SSH-implementation.
−
System load of less used clients:
  
−
c011 up 16:01, 0 users, load 0.00, 0.01, 0.05
  
−
c018 up 15:46, 0 users, load 0.00, 0.01, 0.05
  
   
−
Simply jump to any of them. "<tt>ssh c011</tt>" would work in this example.
  
   
  +
=== Target audience ===
−
'''Hint:''' ''If you know the target machine'' you might combine these two separate into a single one --> [[Remote Access/Single Command]]
 
  +
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 - this will make them "known" to our systems.)
   
  +
=== Load Balancing ===
−
Usually the computers in the pool shutdown itself when nobody is logged in. To supply some computers to the above user several pool computers are running continuously to be reachable for this specific use case. This is: '''c031..c036''' which can be found in the first row in room [[-1.101]]. These computers are usable locally also without limitation. If they are in use in the very moment when you login remotely they may not be listed as available because of this very fact.
  
  +
This term is misleading on this specific installation: the default algorithm being used is simply "round-robin" - you'll get connected the "next" machine one after another. If you landed on an overcrowded system simply disconnect/reconnect to use another machine.
   
  +
=== Legacy <tt>login.stud</tt> ===
−
Please note that these clients reboot automatically early in the morning to clean up things - but only if nobody is logged in...
  
  +
Both <tt>login.stud.informatik.uni-goettingen.de</tt> and <tt>login.informatik.uni-goettingen.de</tt> are not affected by this new approach. They "old" machines will continue to work unmodified.
   
  +
=== Timeout ===
−
== Problems with shared resources ==
  
  +
* 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 <tt>kinit && aklog</tt> when you're approaching timeout.
   
  +
=== Availability ===
−
System resources are limited: <tt>login.stud.informatik.uni-goettingen.de</tt> is a shared source in more intense way than those pool computers are. There is only ''one single'' login.stud.
  
  +
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 the servers ==
−
It is considered unfriendly behavior to stress a shared resource in such a manner that other users can not work anymore.
  
  +
Usually we do utilize "<tt>fail2ban</tt>" to chase brute force attempts 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"
−
One usual trigger element for this kind or problems is [[Java]].
 
  +
|-
−
* Sometimes it crashes and does not clean up the allocated memory nor CPU resources. Just a very few Java processes hanging in the background can render login.stud unusable - it has to get restarted with a hard reset. (Of course other languages allow generating the same problem, but we see Java most of the time...)
  
  +
| [[Image:Diamond-caution.png]] || We do limit the rate of new (<tt>tcp-</tt>) connections from any given source IP address to 1 per minute.|| [[Image:Diamond-caution.png]]
−
* when you use [[Eclipse]] you might start background processes. Make sure to stop all of them...
  
  +
|-
  +
|}
   
  +
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. Going to to log in too early gives just a generic error message:
−
=== Killing a problematic process ===
  
−
If you have the suspicion that you have produced such bad background processes do the following:
  
   
  +
~# ssh username@shell.stud.informatik.uni-goettingen.de
−
First get a terminal with <tt>top</tt> running
  
  +
ssh_exchange_identification: read: Connection reset by peer
−
* inside the working Desktop Environment: use a normal GUI-Terminal window to start <tt>top</tt>. How to do this depends on the Desktop Environment used. Usually there is a way to enter a command. Simply run <tt>top</tt>
  
   
  +
This behavior should be fine for "normal" users where one person has a different IP address than other people.
−
Alternatively go to a "classic" physical console. This does also work very often if the GUI is not usable for some reason.
  
−
* log off (if possible)
  
−
* go to a normal console - press <tt>CTRL-ALT-F2</tt> (or F1/F3/F4/F5/F6)
  
−
* login
  
−
* run <tt>[[top]]</tt>
  
   
  +
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.
−
In that Terminal:
  
−
* use <tt>[[top]]</tt> to examine the running processes. For example look for "java" in the "command" column
  
−
* note that the first column shows the process number
  
−
* the single letter "k" (for "kill") will ask you for a process number to be killed. The second prompt will ask for the specific signal to send. The default offered is "15/sigterm", try this first (by simple pressing <tt>Enter</tt>. If this is not sufficient do the same again and enter "9" which stands for "sigkill".
  
   
  +
== Tips 'n' Tricks ==
−
Help for <tt>top</tt>:
  
−
* press question mark '''?''' ''while running'' <tt>top</tt>
  
−
* read the man page (<tt>man top</tt>) for detailed description
  
   
  +
=== Connect to the same machine again ===
−
* If <tt>top</tt> top fails: kill ''everything''
  
  +
Circumventing the Round-Robin mechanism is possible: connect to a specific port <tt>42000+''n''</tt> withh <tt>''n''={1..6}</tt> :-)
−
''Only if you are sure that you are the only user on this physical machine:'' simple turn it off. This is acceptable because the Operating System is not stored locally but the machine performs remote boot. No files on disk can be damaged by a forced power cycle.
  
   
  +
For maschine number 4:
−
== Problems with X forwarding ==
  
  +
−
tbw
  
  +
~$ 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 ==
  
== See also ==
−
* [[PuTTY]]
 +
* [[Remote Access]]
−
* [[FAQ]]
 +
* [[Long Running Processes]]
−
* [[Xming]]
  
   
   
 
== Links ==
  
== Links ==
  +
* 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:Remote]]
 +
[[Category:Pool]][[Category:Remote]]

Version vom 31. Mai 2016, 08:50 Uhr

Diamond-caution.png Beta Test. Please give feedback. Diamond-caution.png


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 - this will make them "known" 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 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 attempts to hack login credentials. For technical reasons this is not possible for this "haproxy" approach. The workaround is:

Diamond-caution.png We do limit the rate of new (tcp-) connections from any given source IP address to 1 per minute. 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. Going 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 "normal" 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 the same machine again

Circumventing the Round-Robin mechanism is possible: connect to a specific port 42000+n withh n={1..6} :-)

For maschine 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

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