A secure SSH public keys directory
A public data object is build from the official sources, compiled from public data.
These data are processed with an open source script and checked against the live read server public keys. Then all the SSH servers informations are stored and the public keys are listed in a SSHd formatted file ready to use format.
This final known_hosts file can be downloaded securely using HTTPS. All others data can be audited publicly.
Why? What's the pain? What's the issue?
The first time you connect with SSH to a remote server, the SSH client asks you to authenticate the server with a cryptic string provided. You usually accept this blindly without any formal check. You don't know the actual fingerprint, you don't have anything to compare to.
And even sometimes you disable the security check to prevent any halt or disturbance during the connection flow. In any way finally, a man in the middle spying is allowed, so SSH is not really helpful.
That's a real issue, see here, someone opened a Stackoverflow issue.
and there, an issue on Github.
Astonishingly, the answer is the user has to "just accept as it is". And that's the basis of the Trust On First Use scheme of SSH.
Because many times, when setup a new Linux/BSD server, we are pulling software using git through SSH, eventually with agent relaying. The SSH client then asks to authenticate the remote server.
With SSH, the server public key requires an out of band transfer.
One alternative solution is to pull the code using HTTPS with an access token, but this token has to be transferred securely in the server, and it must be protected in all servers where it is used.
This project also came from some serious questions :
How do you know the correct key fingerprint when connecting to a public server? Why should we assume the first connection is a clean and good one?
Do you really think that manually checking a fingerprint or a random-art is secure?
For example, ssh-keyscan only shows you the fingerprint of the remote server the client server is seeing, how can you be sure it is right one?
There are some existing techniques to assess the fingerprints, or to securely verify the host key. But there are painful or not reliable.
What if there is a kind of root of trust already setup in your system? And with this trusted system, we could remotely get a list of SSH public services keys?
That's the purpose of SSHTA : leveraging the HTTPS CA store, to securely get the SSH public keys of common servers. Using the certificates store of the package manager is investigated.
No more TOFU : full trust from day one.
More efficient. No more confirmation, no more manual review, no more CICD pipeline halting, SDK hassle-free...
A simple public electronic directory, providing the right public keys for some common SSH services.
Run or add in your scripts :
wget https://sshta.conserity.org/known_hosts -nc -P ~/.ssh
We're considering acquiring a short domain name, to have a shorter alias domain.
A bash script is in development, ease the download and append into known hosts.
You always trust someone, like a trusted authority.
Thanks to TLS/PKI (also in the future it could use the package distributions embedded PKI), you can safely get a list of known SSH services public keys.
One can also fetch the public keys or build your own list, then distributing with your own server. It's just we did the hard job for you and secured everything : SSL, DNS, the web server, public key check, formatting output in the right format...
It solves a problem for us, and we think we aren't the only company facing this issue, so we are sharing this. Since it is only about public information, a public directory of public keys, there's barely no difference between making this project private or public. Obviously, we trust our systems, but some other companies might trust the BitLogiK infosec company to use this system.