proposal: please make SSH public keys fingerprints via trusted way visible

[edmundlaugasson]

Hereby I propose to make uptermd.upterm.dev SSH key fingerprints publicly available. Then we can verify it BEFORE we connect first time. Currnetly we have to just trust blindly and cannot avoid MITM. Looks like https://uptermd.upterm.dev/ works, one option is to show fingerprints there as index page.

Also noticed, that following command gave empty output:
ssh-keyscan uptermd.upterm.dev | ssh-keygen -lf -
... although this is not reliable as it wouldn't avoid MITM. The only trusted way is get fingerprints directly from upterm server admin via reliable public way. To not depend on 3rd party service, then it would not be good to share these keys via GitHub. Certainly this is also one option, if sharing fingerprints directly via web is not suitable for you. The most important is, that you will share these fingerprints so, that we can use them.
I use it e.g. so - create a script

#!/bin/sh
user=<token>
server=uptermd.upterm.dev
serversshport=22
key=ED25519
trustedhash=<fingerprint>
serverhash=<fingerprint>
# Connecting
if [ $serverhash = $trustedhash ]; then clear; printf "\nOffered $(echo $key) key fingerprint\n\n$(echo $serverhash)\n\n...CAN be trusted.\n\nLogging in...\n\n"; ssh $user@$server -p $serversshport; else clear; printf "\nOffered $(echo $key) key fingerprint\n\n$(echo $serverhash)\n\n...CAN NOT be trusted.\n\nThe $(echo $key) key trusted fingerprint is:\n\n$(echo $trustedhash)\n\nDO NOT log in\n\n"; fi

... and then run it. For easier run, I will create bash alias (~/.bash_aliases) to run it:
alias upterm-connect='sh upterm.connect.sh'
Certainly I will edit that script and fulfill with appropriate data. trustedhash would be the fingerprint got from you via reliable way. The serverhash is the fingerprint offered on first connection. I just will answer no on first time, then copy that hash to script and then connect already via script.

So my proposal - please adopt to your needs (fix the real web server root location) and run that command on your server
for i in /etc/ssh/*.pub; do ssh-keygen -lf $i; done | uniq > uptermd.upterm.dev/index.html

This means, that server key fingerprints (key pair has same fingerprint) will be redirected as front page of uptermd.upterm.dev server. This is just hack, we all know, that there will be plain text file without any HTML syntax and this syntax is not needed - we just need fingerprints and that purpose will be done.

The output of that proposed command could look like (depending on what keys are available):

1024 SHA256:pm5g8a021dZsqZzyajgvrdI8YgeBOFTtzoYVS/+m8+s root@server (DSA)
256 SHA256:OWMdutEQ7xpgUnOIxYFcQsZJhW+soeGqok9nzY root@server (ECDSA)
256 SHA256:9ajV8JqMe6jJE/s3TYjb/9xw7T0pfJ2+gADiBIJWDPE root@server (ED25519)
3072 SHA256:uFiKe97+ooizk3/pF1IaUCnbqmnd4ablQpHd40 root@server (RSA)

Then we can ensure about the fingerprint BEFORE first connection and verify it and THEN connect.

On first connection there is such a message:

The authenticity of host 'uptermd.upterm.dev (157.230.199.75)' can't be established.
ED25519 key fingerprint is SHA256:9ajV8JqMe6jJE/s3TYjb/9xw7T0pfJ2+gADiBIJWDPE.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

After accepting it, we can check the accepted fingerprint from ~/.ssh/authorized_keys file:

ssh-keygen -F uptermd.upterm.dev | ssh-keygen -lf -
256 SHA256:9ajV8JqMe6jJE/s3TYjb/9xw7T0pfJ2+gADiBIJWDPE |1|DAZ5Gxn3yPCHGMM6QtJRyyfRjrk=|cV9vcPY7UrC+koTzNJsgAscPEzw= (ED25519)

... and we can see, that 9ajV8JqMe6jJE/s3TYjb/9xw7T0pfJ2+gADiBIJWDPE is the fingerprint of Ed25519 key, which was offered also on first SSH-connection.

The point is: this will avoid MITM on first connection, next connections will be checked anyway via ~/.ssh/authorized_keys file and in case of mismatch connection will not be established. Current idea of fingerprints availability will avoid MITM on first connection. This is actually regular practice, what sysadmins are using in order to be sure about the server they connecting and avoid MITM.