Remote Access und Diskussion:Shell/Fingerprints: Unterschied zwischen den Seiten
imported>Burghardt |
imported>Matthias.neumann (Neuer Abschnitt →shell server fingerprints) |
||
Zeile 1: | Zeile 1: | ||
+ | When trying to connect to<br /> |
||
− | == Goal == |
||
+ | <code>shell.stud.informatik.uni-goettingen.de</code><br/> |
||
− | 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! |
||
+ | via ssh, it tells me that the fingerprint is<br /> |
||
+ | <code>SHA256:L+FCMj2bm8x/BfR8AdaaLnqTmFD35D0EYNlFG7a2dt8</code>,<br/> |
||
+ | which is documented here to be the old fingerprint, so it should only have been in use till april 2017. |
||
+ | So, is the documentation incorrect or is the shell server still using the older fingerprint (at least sometimes)? |
||
+ | --[[Benutzer:Matthias.neumann|Matthias.neumann]] 17:29, 27. Sep. 2017 (CEST) |
||
+ | == shell server fingerprints == |
||
− | == Strategy == |
||
− | Currently (end of 2015) there are exactly two systems reachable from the outside world: |
||
+ | Also, the fingerprints for <tt>ssh-ed25519</tt> is the same on <tt>shell.informatik.uni-goettingen.de</tt> and <tt>shell.stud.informatik.uni-goettingen.de</tt>, but does not match any of the fingerprints documented. |
||
− | ;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 |
||
+ | I get the following fingerprint: <tt>SHA256:H4FLNG2aNYRZ3jxepIx5E0s0a2ZvtZbbmVLt56b+nK0</tt>. |
||
− | ;login.informatik.uni-goettingen.de: usable ''only'' by staff members with [[Gwdg]]-Account |
||
+ | What is the correct fingerprint? |
||
− | |||
+ | If the documentation is correct, it looks like I'm getting the old fingerprints while the server should be using the new ones... |
||
− | 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>. |
||
− | |||
− | This gateway approach is necessary as the pool computers have local, non-routeable IP-addresses like 172.27.x.y. |
||
− | |||
− | 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.: |
||
− | |||
− | 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. |
||
− | |||
− | '''Hint:''' ''If you know the target machine'' you might combine these two separate into a single one --> [[Remote Access/Single Command]] |
||
− | |||
− | 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. |
||
− | |||
− | Please note that these clients reboot automatically early in the morning to clean up things - but only if nobody is logged in... |
||
− | |||
− | == Problems with shared resources == |
||
− | |||
− | 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. |
||
− | |||
− | It is considered unfriendly behavior to stress a shared resource in such a manner that other users can not work anymore. |
||
− | |||
− | 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...) |
||
− | * when you use [[Eclipse]] you might start background processes. Make sure to stop all of them... |
||
− | |||
− | === Killing a problematic process === |
||
− | If you have the suspicion that you have produced such bad background processes do the following: |
||
− | |||
− | First get a terminal with <tt>top</tt> running |
||
− | * 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> |
||
− | |||
− | 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> |
||
− | |||
− | 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". |
||
− | |||
− | Help for <tt>top</tt>: |
||
− | * press question mark '''?''' ''while running'' <tt>top</tt> |
||
− | * read the man page (<tt>man top</tt>) for detailed description |
||
− | |||
− | * If <tt>top</tt> top fails: kill ''everything'' |
||
− | ''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. |
||
− | |||
− | == Problems with X forwarding == |
||
− | tbw |
||
− | |||
− | == See also == |
||
− | * [[PuTTY]] |
||
− | * [[FAQ]] |
||
− | * [[Xming]] |
||
− | |||
− | |||
− | == Links == |
||
− | |||
− | [[Kategorie:Remote]] |
Version vom 27. September 2017, 19:20 Uhr
When trying to connect to
shell.stud.informatik.uni-goettingen.de
via ssh, it tells me that the fingerprint is
SHA256:L+FCMj2bm8x/BfR8AdaaLnqTmFD35D0EYNlFG7a2dt8
,
which is documented here to be the old fingerprint, so it should only have been in use till april 2017.
So, is the documentation incorrect or is the shell server still using the older fingerprint (at least sometimes)?
--Matthias.neumann 17:29, 27. Sep. 2017 (CEST)
shell server fingerprints
Also, the fingerprints for ssh-ed25519 is the same on shell.informatik.uni-goettingen.de and shell.stud.informatik.uni-goettingen.de, but does not match any of the fingerprints documented. I get the following fingerprint: SHA256:H4FLNG2aNYRZ3jxepIx5E0s0a2ZvtZbbmVLt56b+nK0. What is the correct fingerprint? If the documentation is correct, it looks like I'm getting the old fingerprints while the server should be using the new ones...