The client has "eudemo.thinlinc.com" as the default server name. That server no longer exists as we've removed our demo system. We should change to something else.
We also include the host keys for eudemo and usdemo in the client, which are no longer useful.
Since there is no longer a natural value for the default server we have decided to leave it empty. On a new installed client the server field is now empty by default. I also removed all the old keys from ssh_known_hosts, added a informative comment instead. When upgrading a client the server field is not changed, the value before the upgrade should still be there. What happens to ssh_known_hosts when upgrading? - On Linux, if ssh_known_hosts has been changed, we ask the user to choose if the old ssh_known_hosts should be used or the new one. - On Windows nothing happens to the system wide known hosts registry, the old keys are left unchanged. - On macOS we don't ship the ssh_known_hosts. (See bug 3046) Tested the Linux client on Ubuntu20.04, Windows client on Windows 10 and Mac client on macOS Big Sur.
I tested the client on Fedora 32 and Windows 10, and could reproduce both the demo server name and the demo keys in ssh_known_hosts. Can confirm that the fix changes the default server to the empty string for new installations, and that the demo keys are removed on Fedora but not on Windows. For upgrades, the server name is whatever the user used for the last login attempt. However, note that for upgrades on Fedora 32, the user is not asked if they want to use the old or the new ssh_known_hosts. Instead, the user gets the warning below, and the existing ssh_known_hosts is kept as is: > warning: /opt/thinlinc/etc/ssh_known_hosts created as /opt/thinlinc/etc/ssh_known_hosts.rpmnew All references to the demo server seems to have been removed, and the rewriting looks good.
