This is a documentation "bug report" (I think… if I'm right) for this page:
I'm connecting to Lish London.
1 - One of my Linux systems logs
Server host key: rsa and then an SHA256 fingerprint, base64 encoded, which matches the
ECDSA SHA256 (a different key type) for London at the page above. This is Fedora 29, OpenSSH 7.9p1
2 - Another system (SUSE Tumbleweed) logs this, same OpenSSH version 7.9p1 but it gets a different kind of server key:
Server host key: ecdsa-sha2-nistp256 SHA256:A+FgYsMXEsn67JJDAGbXqN7moquTxpoSohx5eGfaz2U
It seems caused by a different default (for acceptable server host key types) on this system, but…
There is no fingerprint for this key type on the help page, and so it can't be verified (but lish does send it, so it makes sense to verify, as recommended in the guides).
3 - I edited ssh config on SUSE to prefer ed25519, and got this:
Server host key: ssh-ed25519 SHA256:HXHM8/wCx7NrGsnfGpaexiBfOLKN9g0hoaL9wRaSeWg
This fingerprint ( for ed25519 host key ) is not listed either, and again it's one of the key types that can be sent by lish.
4 - And finally when preferring rsa:
Server host key: ssh-rsa SHA256:L7sQgnpnoBwRoyIYXAFBs8SdSnwtyYmhXs1p/mQDKQM
which is same key as Fedora gets by default, and it is the key fingerprint identified as "ECDSA SHA256" on the help page (not as rsa key).
So two issues really:
1 - The lish server (at least for London) can send some host keys / key types whose fingerprints are not listed - those unlisted keys / key types may come up depending on client configuration - and then they can't be verified:
… maybe others.
2 - There seems to be a bit of a mixup with RSA vs. ECDSA key fingerprints:
The fingerprint for the RSA key is listed as "ECDSA SHA256".
Thanks for bringing this up. I know it's been some time since you asked this question, so I wanted to provide some information about why you were seeing a discrepancy and provide more valuable steps for reporting issues like this.
The LISH Gateway fingerprints are updated from time to time. While we endeavor to keep the documentation on their fingerprints up to date, you caught us at a time where they were not. This is why the ones posted were not the same as the actual ones in our guide.
All of our Docs are available via our public GitHub repo. One of the reasons we set it up this way is to invite readers to report issues or even to create a PR for updating outdated information. That goes for anything you see in our documentation. There are links for opening an issue at the top of each page, under the title where it reads: Contribute on GitHub. We also publish the date the documentation was last updated.
We're always open to hearing from our customers. If you find anything else on our platform that you'd like us to know about, send us an email at [email protected]