SL:Virtual Machines 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 />
== Current state ==
 
  +
<code>shell.stud.informatik.uni-goettingen.de</code><br/>
09.2012:
 
  +
via ssh, it tells me that the fingerprint is<br />
* tmgsim1 - dead
 
  +
<code>SHA256:L+FCMj2bm8x/BfR8AdaaLnqTmFD35D0EYNlFG7a2dt8</code>,<br/>
* tmgsim2 - dead
 
  +
which is documented here to be the old fingerprint, so it should only have been in use till april 2017.
* tmgsim3 - dead
 
  +
So, is the documentation incorrect or is the shell server still using the older fingerprint (at least sometimes)?
* tmgsim4 - Available, Windows/Gwdg
 
  +
--[[Benutzer:Matthias.neumann|Matthias.neumann]] 17:29, 27. Sep. 2017 (CEST)
* tmgsim5 - Available, Roman Seibel
 
* tmgsim6 - Available, Udo Burghardt - useable by everyone
 
* tmgsim7 - Available, Ansgar Kellner
 
* tmgsim8 - Available, Youssef Shehadeh
 
* tmgsim9 - Available, Saleh Al-Shadly
 
* tmgsima - Available, Udo Burghardt
 
   
== Virtual Machines ==
+
== shell server fingerprints ==
=== tmgsim1.sl.tmg.loc - Windows 7 ===
 
Quad Core, 6 GiB Ram. 32 GB Disk, transparent access to AFS Storage.
 
   
  +
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.
==== Installation ====
 
  +
I get the following fingerprint: <tt>SHA256:H4FLNG2aNYRZ3jxepIx5E0s0a2ZvtZbbmVLt56b+nK0</tt>.
Example walkthrough with a windows machine:
 
  +
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...
Windows 7 Professional 64 bit, english
 
Internal name: win7sim1
 
Manually set IP Address to 172.29.22.201 / 16 on the first run. '''Update 07.2011: DHCP delivers 192.168.22.61'''
 
Because this would NOT work with Qualnet (only 172.22./16 as client address range has been bought) switch to bridged mode and to DHCP with DNS tmgsim1.tmg.loc
 
 
Disable IPv6
 
Enable ICMP in Firewall
 
<reboot>
 
Enable Remote Desktop with "any version"
 
 
Install Firefox
 
 
Microsoft: 2 Important Updates
 
<reboot>
 
Microsoft: 62 (!) Important Updates in several steps
 
<reboot>
 
Install Notepad++ 5.8.7
 
Install Updatechecker 1.038
 
Firefox: Prefbar
 
 
Activate Windows. Licenses are available from MSDNAA
 
 
Install KfW 3.2.2 32bit + 64bit
 
Install Network Identity Manager 2.0.102 32bit + 64bit
 
Install [[OpenAFS]] 1.5.78 64bit
 
 
Change Computer Name --> UG-UMINTMGSIM1 to join Active Directoy
 
(The DNS Name stays tmgsim1.tmg.loc though!) '''Update 07.2011: tmgsim1.sl.tmg.loc'''
 
Join Active Directory (one needs to be a ''Domain Admin'' to do so)
 
 
Granted Remote Desktop manually (no groups mechanism available in AD for this task) access to:
 
* akellne
 
* oalfand
 
* shartung
 
* staheri
 
* yelhajj
 
* geyu -- ''local'' user account, no Admin. (Local due to problems with <code>UG-STUDENT</code>.)
 
* uburgha
 
* gtest2 -- user only, no Admin
 
* c.wehrberger
 
* pmemarm
 
 
I've put these five user accounts into group <code>ADMINISTRATORS</code>! This way it is possible to log in with <code>gwdg\username</code> also for administrative tasks.
 
 
Please note that ''only one single user'' can run a Remote Desktop session at any given time. If you want to share a single virtual machine you need to create yourself a schedule...
 
 
Installed [[Qualnet]] 5.0.1 connected to license server. Tested usage from a remote site as described below.
 
 
==== Multiple-User access ====
 
* it ''is'' possible to run applications in the background without being logged in: you may close the Remote Desktop window and leave everything running!
 
* ONLY ONE user can have an ''established'' Remote Desktop connection at any given point in time.
 
** when a second user tries to connect the first one will get a message box.
 
** the ''first'' user has the priority. He may simply deny lo loose his connection.
 
** if that first user is not watching his terminal then an automatically implied answer is "yes, loosing the connection is ok for me"!
 
* there are ONLY TWO Qualnet licenses. You need to talk with each other to schedule usage of these.
 
 
==== Remote Access from outside ====
 
The system is reachable ''only from inside the Institute's LAN.''
 
 
The Remote Desktop inside the guest is configured in the default manner, listening on standard port 3389.
 
 
You may login to <code>login.informatik.uni-goettingen.de</code> (Staff only. Students ''and'' staff may use <code>login.stud.informatik.uni-goettingen.de</code>) and forward any unused local port (e.g. 12345) to
 
 
tmgsim1.sl.tmg.loc:3389 '''(Updated 07.2011)'''
 
 
* on unixoid OS' use <code>ssh -L 12345:tmgsim1.sl.tmg.loc:3389 user@login.informatik.uni-goettingen.de</code>
 
* on Windows you may use [[PuTTY]], see https://intra.informatik.uni-goettingen.de/wiki/index.php/SshTunnel for a screenshot showing forwarding a port.
 
 
The result is the same: with this tunnel established it is possible to use the standard Remote Desktop application to connect to <code>localhost:12345</code>.
 
 
For Linux run something like this:
 
~$ rdesktop -u gwdg\\username -g1200x1000 -a16 localhost:12345
 
 
==== Updates ====
 
Someone should be responsible for keeping the system up-to-date!
 
 
* Udo, 26.04.2011
 
Several Windows Updates
 
Firefox 3.6.13 --> 3.6.16 --> 4.0
 
IE 9
 
Notepad++ 5.8.7 --> 5.9
 
Java 1.6.0.24 --> 1.6.0.25
 
 
* Udo 07.2011 Network jumping 172.xxx --> 192.168.22.x
 
 
 
=== tmgsim2.sl.tmg.loc ===
 
Deleted...
 
 
=== tmgsim3.sl.tmg.loc ===
 
Deleted...
 
 
=== tmgsim4.sl.tmg.loc ===
 
ESXi: once again Windows 7 Prof, english, 64bit, new installation because the Migration from the old Virtualbox-Containers is not as simple as expected...
 
 
Fresh Installation
 
(was temporary 172.22.98.204, now 192.168.22.64)
 
 
<strike>Qualnet 5.0.2</strike>
 
Integration in Gwdg / Active Directory
 
Enable Remote Access for individually picked accounts
 
Enable All ICMPv4 (for ping-Tests)
 
 
Remote Access is granted only for a few users:
 
<pre>
 
C:\Users\lu>net localgroup "Remote Desktop Users"
 
Alias name Remote Desktop Users
 
Comment Members in this group are granted the right to logon remotely
 
 
Members
 
 
-----------------------------------------------------------------------------
 
GWDG\akellne
 
GWDG\gtest2
 
GWDG\oalfand
 
GWDG\pmemarm
 
GWDG\shartun
 
GWDG\staheri
 
GWDG\uburgha
 
GWDG\yelhajj
 
UG-STUDENT\c.wehrberger
 
UG-STUDENT\hang.zhang1
 
The command completed successfully.</pre>
 
 
Administrator rights may be granted on demand ---> [[User:Burghardt]]
 
 
=== tmgsim5.sl.tmg.loc ===
 
Roman Seibel:
 
Ubuntu 11.04 Natty Server, 64bit, 4GiB Ram, Dual Core, 16GB Disk
 
 
=== tmgsim6.sl.tmg.loc ===
 
Udo:
 
<strike>Ubuntu 11.04 Natty Server</strike> [[debian]] [[Squeeze]], 32bit, 1GiB Ram, Dual Core, 8 GB Disk
 
* useable by everyone, including [[OpenAFS]] $HOME
 
 
<pre>~$ ssh -p 22222 ub@tmgsim6.sl.tmg.loc
 
ub@tmgsim6.sl.tmg.loc's password:
 
Linux tmgsim6 2.6.32-5-686 #1 SMP Sun Sep 23 09:49:36 UTC 2012 i686
 
//
 
// tmgsim6.sl.tmg.loc
 
//
 
ub@tmgsim6:~$ pwd
 
/afs/informatik.uni-goettingen.de/user/u/ub
 
</pre>
 
 
=== tmgsim7.sl.tmg.loc ===
 
Ansgar Kellner:
 
Ubuntu 11.04 Natty Server, 32bit, 4GiB Ram, Dual Core, 12 GB Disk
 
 
=== tmgsim8.sl.tmg.loc ===
 
Youssef El Hajj Shehadeh:
 
Ubuntu 11.10 Oneiric Server, 32bit, 2GiB Ram, Dual Core, 32 GB Disk
 
 
# host tmgsim8.sl.tmg.loc
 
tmgsim8.sl.tmg.loc has address 192.168.22.68
 
 
Local accounts only (no ldap/kerberos/...)
 
 
 
=== tmgsim9.sl.tmg.loc ===
 
Saleh Al-Shadley:
 
Ubuntu 11.10 Oneiric Server, 32bit, 1GiB Ram, 8 GB Disk
 
 
=== tmgsima ===
 
Udo Burghardt
 
 
=== slgw ===
 
Udo Burghardt: the Gateway / Router / Firewall
 
 
 
 
 
== See also ==
 
* [[SL:tmg94]] -- the host
 
* [[SL:Remote Access]]
 
* [[SL:Topology]]
 
 
== Links ==
 
 
[[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...