Shell und Diskussion:Shell/Fingerprints: Unterschied zwischen den Seiten

Aus Doc-Wiki
(Unterschied zwischen Seiten)
Zur Navigation springen Zur Suche springen
imported>Burghardt
 
imported>Matthias.neumann
 
Zeile 1: Zeile 1:
  +
When trying to connect to<br />
{| style="border: 1pt black dashed"
 
  +
<code>shell.stud.informatik.uni-goettingen.de</code><br/>
|-
 
  +
via ssh, it tells me that the fingerprint is<br />
| [[Image:Diamond-caution.png]] || Beta Test. Please give feedback. || [[Image:Diamond-caution.png]]
 
  +
<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 ==
   
  +
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.
 
  +
I get the following fingerprint: <tt>SHA256:H4FLNG2aNYRZ3jxepIx5E0s0a2ZvtZbbmVLt56b+nK0</tt>.
== Usage ==
 
  +
What is the correct fingerprint?
Simply use SSH to login to this machine:
 
  +
If the documentation is correct, it looks like I'm getting the old fingerprints while the server should be using the new ones...
<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'''
 
...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 <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. You need to <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 the servers ==
 
 
=== Rate Limiting ===
 
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"
 
|-
 
| [[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 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 each one has a different IP address than other people.
 
 
If you are a group of students behind NAT this could be a problem. We need yet to find out if this might be a problem for students residential establishment in Göttingen.
 
 
=== Additionally... ===
 
 
If you have problems to login take a look at this page. Probably we will limit access by further means soon...
 
 
== Tips 'n' Tricks ==
 
 
=== Connect to a specific machine ===
 
Circumventing the Round-Robin mechanism is possible: connect to a specific port <tt>42000+''n''</tt> with <tt>''n''={1..6}</tt> :-)
 
 
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 ==
 
* Testing! -- current state considered "BETA"
 
* make Status Information publicly available
 
 
== See also ==
 
* [[Remote Access]]
 
* [[Long Running Processes]]
 
 
 
== 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>
 
-->
 
 
[[Category:Pool]][[Category:Remote]]
 

Version vom 27. September 2017, 20: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...