SL:Topology und Diskussion:Shell/Fingerprints: Unterschied zwischen den Seiten
(Unterschied zwischen Seiten)
Zur Navigation springen
Zur Suche springen
imported>Burghardt (Die Seite wurde neu angelegt: „The Sensor Lab gets its own separate network. The idea is to have an isolated network with only a small chance to affect the "normal" LAN workstations while allo…“) |
imported>Matthias.neumann (Neuer Abschnitt →shell server fingerprints) |
||
| Zeile 1: | Zeile 1: | ||
| + | When trying to connect to<br /> |
||
| − | The Sensor Lab gets its own separate network. |
||
| + | <code>shell.stud.informatik.uni-goettingen.de</code><br/> |
||
| + | 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 == |
||
| − | The idea is to have an isolated network with only a small chance to affect the "normal" LAN workstations while allowing all necessary connections (in and out) to work in a comfortable way. |
||
| + | 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. |
||
| − | == Topology == |
||
| + | I get the following fingerprint: <tt>SHA256:H4FLNG2aNYRZ3jxepIx5E0s0a2ZvtZbbmVLt56b+nK0</tt>. |
||
| − | A <strike>small computer</strike> Virtual Machine works as a router. The allowed traffic is limited in some ways. The rules are managed by [[User:Burghardt|Udo Burghardt]]. |
||
| + | What is the correct fingerprint? |
||
| − | <pre>root@slgw:~# lsb_release -a; ip a | grep global |
||
| + | If the documentation is correct, it looks like I'm getting the old fingerprints while the server should be using the new ones... |
||
| − | No LSB modules are available. |
||
| − | Distributor ID: Ubuntu |
||
| − | Description: Ubuntu 11.10 |
||
| − | Release: 11.10 |
||
| − | Codename: oneiric |
||
| − | inet 172.22.255.253/16 brd 172.22.255.255 scope global eth0 |
||
| − | inet 192.168.22.254/24 brd 192.168.22.255 scope global eth1 |
||
| − | </pre> |
||
| − | |||
| − | |||
| − | === IP Ranges === |
||
| − | We use a simple private address block of: |
||
| − | <pre> |
||
| − | ~# ipcalc 192.168.22.0/24 |
||
| − | Address: 192.168.22.0 11000000.10101000.00010110. 00000000 |
||
| − | Netmask: 255.255.255.0 = 24 11111111.11111111.11111111. 00000000 |
||
| − | Wildcard: 0.0.0.255 00000000.00000000.00000000. 11111111 |
||
| − | => |
||
| − | Network: 192.168.22.0/24 11000000.10101000.00010110. 00000000 |
||
| − | HostMin: 192.168.22.1 11000000.10101000.00010110. 00000001 |
||
| − | HostMax: 192.168.22.254 11000000.10101000.00010110. 11111110 |
||
| − | Broadcast: 192.168.22.255 11000000.10101000.00010110. 11111111 |
||
| − | Hosts/Net: 254 Class C, Private Internet |
||
| − | </pre> |
||
| − | |||
| − | === DNS === |
||
| − | Dedicated ranges/naming convention: |
||
| − | ;1... : former pool computers "wsxy" |
||
| − | ;31... : "normal" computers "pcxy" |
||
| − | ;60 : the server |
||
| − | ;61... : virtual guests on the server |
||
| − | ;240...: infrastructure |
||
| − | |||
| − | ==== Zone file ==== |
||
| − | This is an actual (static) excerpt from the bind zone file: |
||
| − | <pre> |
||
| − | $ORIGIN tmg.loc. |
||
| − | </pre> |
||
| − | <pre> |
||
| − | ; |
||
| − | ; ws - ehemalige Pool Computer |
||
| − | ; |
||
| − | ws1.sl IN A 192.168.22.1 |
||
| − | ws2.sl IN A 192.168.22.2 |
||
| − | ws3.sl IN A 192.168.22.3 |
||
| − | ws4.sl IN A 192.168.22.4 |
||
| − | ws5.sl IN A 192.168.22.5 |
||
| − | ws6.sl IN A 192.168.22.6 |
||
| − | ws7.sl IN A 192.168.22.7 |
||
| − | ws8.sl IN A 192.168.22.8 |
||
| − | ws9.sl IN A 192.168.22.9 |
||
| − | ws10.sl IN A 192.168.22.10 |
||
| − | ws11.sl IN A 192.168.22.11 |
||
| − | ws12.sl IN A 192.168.22.12 |
||
| − | |||
| − | |||
| − | ; |
||
| − | ; pc - Desktop PC |
||
| − | ; |
||
| − | pc01.sl IN A 192.168.22.31 |
||
| − | pc02.sl IN A 192.168.22.32 |
||
| − | pc03.sl IN A 192.168.22.33 |
||
| − | pc04.sl IN A 192.168.22.34 |
||
| − | |||
| − | |||
| − | ; |
||
| − | ; tmg94 Host plus Virtual machines |
||
| − | ; |
||
| − | tmg94.sl IN A 192.168.22.60 |
||
| − | IN TXT "VM Host" |
||
| − | server.sl IN CNAME tmg94.sl |
||
| − | |||
| − | tmgsim1.sl IN A 192.168.22.61 |
||
| − | IN TXT "Windows 7" |
||
| − | |||
| − | tmgsim2.sl IN A 192.168.22.62 |
||
| − | IN TXT "Debian Squeeze" |
||
| − | |||
| − | tmgsim3.sl IN A 192.168.22.63 |
||
| − | |||
| − | |||
| − | ; |
||
| − | ; ps - power switch |
||
| − | ; |
||
| − | ps1.sl IN A 192.168.22.241 |
||
| − | ps2.sl IN A 192.168.22.242 |
||
| − | |||
| − | ; |
||
| − | ; sw - Switch |
||
| − | ; |
||
| − | sw.sl IN A 192.168.22.244 |
||
| − | |||
| − | |||
| − | gw.sl IN A 192.168.22.254 |
||
| − | </pre> |
||
| − | |||
| − | ;Example: the gateway is known as: |
||
| − | ~# host gw.sl.tmg.loc |
||
| − | gw.sl.tmg.loc has address 192.168.22.254 |
||
| − | |||
| − | ;Reverse Zone:...is ''not'' prepared as it is not required. |
||
| − | |||
| − | <small> |
||
| − | ---- |
||
| − | ''Hint:'' This is the view from ''inside'' that network. From outside it looks this way: |
||
| − | ~$ host slgw.tmg.loc |
||
| − | slgw.tmg.loc has address 172.22.255.253 |
||
| − | </small> |
||
| − | |||
| − | == Service Availability == |
||
| − | === [[DHCP]] === |
||
| − | The router offers dhcp services using <code>ISC dhcpd</code>. It will deliver the usual information to the clients: address, netmask, gateway, nameservers. Event though the protocol is "dynamic" the configuration is ''static'' to be able to know exactly "who is who". Each computer will always get the same address. |
||
| − | |||
| − | The system wide configuration includes: |
||
| − | <pre> |
||
| − | subnet 192.168.22.0 netmask 255.255.255.0 { |
||
| − | # range 192.168.22.201 192.168.22.211; |
||
| − | option domain-name-servers 134.76.81.212, 134.76.81.104; |
||
| − | option domain-name "sl.tmg.loc"; |
||
| − | option routers 192.168.22.254; |
||
| − | option broadcast-address 192.168.22.255; |
||
| − | }</pre> |
||
| − | |||
| − | Additionally for ''every single'' system which should benefit from dhcp we need an entries like this: |
||
| − | |||
| − | <pre> |
||
| − | host ws1 { |
||
| − | hardware ethernet 00:13:72:8a:bc:41; |
||
| − | fixed-address ws1.sl.tmg.loc; |
||
| − | } |
||
| − | </pre> |
||
| − | |||
| − | |||
| − | You might verify the actual host definitions via |
||
| − | |||
| − | * http://gw.sl.tmg.loc/sensorlab.conf |
||
| − | |||
| − | === [[OpenAFS]] / [[Kerberos]] / [[LDAP]] === |
||
| − | Should work as expected. |
||
| − | |||
| − | === [[SSH]] === |
||
| − | * enabled in all directions (read: especially also from outside into the lab) |
||
| − | |||
| − | === [[ICMP]] === |
||
| − | * all Types enabled |
||
| − | |||
| − | === Web === |
||
| − | * Port 80 and 443 allowed |
||
| − | |||
| − | == See also == |
||
| − | * [[SL:Introduction]] |
||
| − | * Schematic: <br /><code>/afs/informatik.uni-goettingen.de/user/s/sensorlab/documents/Documentation/sensorlab-network.dia</code> <br />bzw. "falschrum:" <br /><code>\\afs\informatik.uni-goettingen.de\user\s\sensorlab\documents\Documentation\sensorlab-network.dia</code> <br />... which is accessible only for project members |
||
| − | |||
| − | == Links == |
||
| − | * http://gw.sl.tmg.loc/sensorlab.conf -- configuration of the Hosts |
||
| − | |||
| − | [[Category:Sensorlab]] |
||
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...